ABA Model Rules–Mapped AI Vendor Due Diligence Checklist for Law Firms

A legal AI vendor due diligence checklist should not begin with the vendor’s feature list. It should begin with the lawyer’s duties. Before a firm deploys an AI tool on a client matter, the practical question is: what evidence has the vendor produced, what contract terms bind that evidence, and which professional responsibility obligation does each item support?

ABA Formal Opinion 512, issued in July 2024, makes that framing hard to avoid. It states that lawyers using generative AI must have a reasonable understanding of the tool’s capabilities and limitations, and must ensure that vendors and other nonlawyer assistants act consistently with the lawyer’s ethical obligations.[1] That moves AI vendor review out of the category of ordinary software preference and into the category of documented professional judgment.

This article is an informational framework, not legal advice for any jurisdiction, court, client, or matter. State rules, client guidelines, court orders, sector-specific privacy duties, and the actual data flow of the tool may require more restrictive controls.

The Model Rules Turn Vendor Review Into Evidence Review

The useful unit of analysis is not “is this AI safe?” It is narrower and more answerable: what must the firm be able to show if a client, court, regulator, insurer, or disciplinary authority asks why this tool was approved for this use?

Four ABA Model Rules do most of the work. Rule 1.1 points to competence: the lawyer must understand enough about the tool to use it responsibly. Rule 1.6 points to confidentiality: client information cannot be fed into a system on the strength of vague data-use promises. Rule 5.3 points to supervision: the vendor is not a lawyer, but its work may affect a lawyer’s compliance. Rule 3.3 points to candor to the tribunal: AI-assisted output still has to be verified before it reaches a court.

State bar materials have been moving in the same direction. Guidance and summaries from Florida, Texas, California, New York, and Pennsylvania reinforce duties around competence, confidentiality, supervision, communication, billing, and court-facing verification, although the details remain jurisdiction-specific.[2][3] A July 2026 ABA Business Law Today article likewise treats AI use as a practical ethics problem for modern legal practice, not a purely technical adoption issue.[4]

Why Ordinary AI Vendor Terms Deserve Close Reading

The risky clause is not always dramatic. It may sit inside a familiar privacy policy, a general product improvement clause, a support access provision, or a unilateral amendment right. That is why the contract review has to be tied to the data path, not just to the vendor’s security overview.

A 2025 Stanford Law / CodeX article discussing TermScout marketplace analysis reported that 92% of AI vendor contracts reviewed claimed broad data usage rights beyond what was necessary for service delivery, compared with a 63% SaaS average. The same analysis reported that only 17% committed to complying with all applicable laws and only 33% provided indemnification for third-party IP claims.[5] Those figures should be read as directional market signals from limited anonymized platform data, not as a comprehensive academic survey. They are still enough to justify a skeptical reading of standard AI terms.

The point is not that every broad clause makes a vendor unusable. The point is that a firm cannot responsibly approve client-facing use until it knows whether client material may be used for training, model improvement, evaluation, support, analytics, subcontracted processing, or future product development.

The Checklist, Mapped to ABA Model Rules

A procurement team can ask hundreds of questions. A law firm does not need hundreds of equally weighted answers. It needs vendor evidence that maps to the duties the firm must satisfy before client data, client strategy, privileged material, or tribunal-facing work enters the tool.

Rule 1.1: Competence Requires More Than a Product Demo

Rule 1.1 does not require every lawyer to become a machine learning engineer. It does require enough understanding to decide whether a tool is appropriate for the intended legal task. A demo showing a polished answer to a friendly prompt is not evidence of that understanding.

• Request model or system documentation describing the tool’s intended use cases, prohibited use cases, known limitations, and dependency on third-party models.
• Request evaluation materials or benchmark summaries where available, and make sure they measure tasks close to the proposed legal use rather than generic language performance.
• Request model cards, bias audits, or fairness assessments where the use case involves classification, ranking, decision support, employment, consumer, housing, financial, or other sensitive contexts.
• Require written change-control commitments for material model, retrieval, data-source, feature, or prompt-orchestration changes.
• Negotiate rollback, suspension, or disablement rights when a model change creates unacceptable legal, confidentiality, accuracy, or client-commitment risk.

The competence file should record what the firm approved the tool to do. “Contract summarization for internal first-pass review” is different from “draft dispositive motion citations” or “rank employees for investigation priority.” If the vendor’s evidence supports only the first use, the approval should not silently expand to the others.

Rule 1.6: Confidentiality Is Where the Contract Has to Do Real Work

Rule 1.6 is the reason “we take security seriously” is not an answer. The firm needs to know what information enters the system, where it is stored, whether it is used to improve models, who can access it, how long it remains there, and what happens when something goes wrong.

• SOC 2: Ask for a current SOC 2 Type II report, not merely a Type I report or a statement that SOC 2 is “in progress.” Type II matters because it evaluates operating effectiveness over a period, not only control design at a point in time.
• Training data: Require an express contractual prohibition on using client data, prompts, uploads, outputs, metadata, or feedback to train or improve models unless the firm gives explicit written opt-in consent.
• Opt-out traps: Treat any term that permits data use unless the customer disables a setting, files a ticket, or joins a special enterprise tier as unresolved until the contract itself says the vendor may not use client data for training or improvement.
• Encryption: Request confirmation of encryption at rest and in transit, including AES-256 at rest and TLS 1.3 in transit where those standards are represented as available.
• Retention and deletion: Require retention periods, deletion mechanics, backup deletion timing, export rights, and offboarding assistance to be stated in writing.
• Support access: Identify whether vendor personnel may view prompts, documents, outputs, logs, or embeddings during support, debugging, monitoring, abuse review, or product analytics.

Confidentiality review should also separate “customer content” from other data categories. Some agreements protect uploaded documents but reserve broad rights in prompts, outputs, telemetry, usage logs, or derived data. For legal work, those categories can still reveal client identity, matter strategy, legal theories, negotiation posture, or privileged work product.

If the vendor relies on a foundation model provider, the firm should not accept a confidentiality promise that stops at the application layer. The firm needs to know whether prompts, documents, embeddings, outputs, or logs are transmitted to the foundation model provider, whether they are retained there, and whether that provider has its own training or improvement rights.

Rule 5.3: Vendor Supervision Includes the Dependency Chain

Rule 5.3 is often discussed as a staff-supervision rule, but for AI procurement it is also a vendor-supervision rule. The firm cannot supervise what it is not allowed to see. That makes subprocessor disclosure, audit evidence, incident handling, and service-change control central rather than administrative.

• Require a current subprocessor list, including hosting providers, analytics providers, support vendors, security tools, and foundation model providers that may process customer data.
• Require notice of new subprocessors before they begin processing firm or client data, with a meaningful objection, termination, or mitigation procedure.
• Require the vendor to flow down confidentiality, security, deletion, incident notice, and data-use restrictions to subprocessors.
• Require incident notification in a contractual 24–48 hour window for incidents affecting firm or client data, followed by investigation updates and remediation evidence.
• Require cooperation with audits, client inquiries, regulator inquiries, litigation holds, deletion requests, and reasonable evidence preservation needs.
• Require prior notice of material changes to models, hosting regions, data flows, security controls, support access, or terms of service.

This is also where liability language belongs. A low general liability cap may be tolerable for ordinary service interruption. It is harder to justify when the excluded or capped harm is the one the diligence is trying to prevent: confidentiality breach, unauthorized training, hallucinated legal authority, discriminatory output, IP infringement, or regulatory noncooperation.

AI-specific carveouts should be read closely. If the vendor’s terms say the customer alone is responsible for outputs, training consequences, third-party model behavior, data misuse enabled by configuration defaults, and changes to the service, the firm may be left supervising a system without the contractual tools needed to supervise it.

Rule 3.3: Vendor Assurances Do Not Verify Court Filings

Rule 3.3 is narrower than the confidentiality and supervision analysis, but it is unforgiving. A vendor can reduce the likelihood of bad output; it cannot satisfy a lawyer’s duty of candor to a tribunal. If AI output is used in court-facing work, lawyer verification remains the control.

• Ask whether the tool generates citations, retrieves citations from an indexed source, or merely predicts citation-like text.
• Ask whether the system links to primary sources, displays source excerpts, or preserves the retrieval trail used to generate an answer.
• Ask whether the vendor measures hallucination, citation accuracy, or retrieval failure for legal tasks, and whether those materials are available for the firm’s review.
• Require internal policy language stating that no AI-generated legal authority, quotation, factual assertion, or procedural representation may be submitted without human verification against authoritative sources.
• Screen court standing orders, judge-specific rules, and client instructions before using AI in tribunal-facing work.

The sanctions cases explain why this belongs in procurement and governance, not just in individual lawyer caution. Mata v. Avianca produced a $5,000 sanction in 2023 after fabricated cases appeared in a filing. Later matters cited in legal ethics coverage include Lacey v. Couvrette, with an approximately $31,100 sanction, and Couvrette v. Wisnovsky, reported in the $96,000–$110,000 range in 2025; coverage of the latter also notes judicial attention to whether firms had written AI-use policies.[6] The exact figures should be checked against the underlying orders before being used in litigation advice, but the direction is plain enough for procurement: courts are asking about controls.

The pace of court-level change reinforces the need to preserve the diligence record. The Ropes & Gray AI court order tracker recorded 681 cases and court rules on AI use across federal and state courts as of June 2026, according to GC AI’s ethics coverage.[6] A firm approving AI tools for litigation work should expect the relevant court rule set to keep moving.

Contract Clauses That Should Not Pass as Boilerplate

The vendor questionnaire and the contract have to reconcile. If the questionnaire says client data is not used for training, but the terms reserve broad improvement rights, the contract controls the risk. If the sales team says a subprocessor is never used for legal customers, the subprocessor exhibit should say the same thing or state the condition clearly.

A vendor that will not negotiate every clause is not automatically disqualified. A vendor that will not identify what the clause means for client data is a different problem. Silence, circular references to online terms, or “enterprise-grade” assurances without evidence should be recorded as risk findings, not treated as procurement friction.

Red Flags for Client-Facing Legal AI Use

Some issues can be mitigated by limiting the use case. Others should stop deployment until the vendor produces better evidence or the firm adopts a narrower acceptable-use rule.

• The vendor refuses to provide a SOC 2 Type II report, security overview, or equivalent evidence under NDA.
• The vendor claims rights to use customer content, prompts, outputs, or metadata for training or improvement unless the customer opts out.
• The vendor will not disclose foundation model providers or subprocessors that may process firm or client data.
• The vendor can change terms, models, hosting locations, data flows, or subprocessors without prior notice.
• The vendor disclaims responsibility for hallucination, confidentiality breach, IP infringement, bias, or security failures while marketing the tool for legal work.
• The vendor cannot explain whether prompts, documents, embeddings, logs, and outputs are retained, deleted, reviewed by humans, or transmitted to third parties.

A firm may still decide to use a tool with known limitations for nonconfidential, internal, low-risk tasks. That decision should be explicit. It should not become accidental approval for privileged uploads, client deliverables, or tribunal-facing work.

How to Preserve the Due Diligence Record

The checklist is not the control. The control is the decision record that shows what the firm asked, what the vendor produced, what limits the firm imposed, and who accepted the remaining risk.

1. Create a vendor file containing the questionnaire, security documents, SOC 2 Type II report, data processing terms, subprocessor list, model documentation, correspondence, and final approval memo.
2. Map each unresolved issue to a use restriction, contract fallback, client-consent requirement, technical control, or governance escalation.
3. State the approved uses and prohibited uses in the firm’s AI governance policy or acceptable-use policy.
4. Set a review cadence for contract changes, model changes, new subprocessors, security-report updates, incidents, and court-rule developments.
5. Require matter teams to verify whether client outside counsel guidelines, protective orders, court orders, or sector-specific confidentiality duties impose stricter limits.

For firms building the internal side of this process, the vendor review should feed into AI governance policy, acceptable-use limits, and the broader AI compliance framework for law firms. The vendor file should not sit apart from those controls.

A Practical Approval Posture

A defensible AI vendor approval should be able to answer four questions without reconstructing the decision from inbox fragments.

• For Rule 1.1, what evidence showed that the firm understood the tool’s capabilities, limitations, and approved uses?
• For Rule 1.6, what contractual and technical commitments protected client information from unauthorized access, reuse, retention, training, or disclosure?
• For Rule 5.3, what evidence allowed the firm to supervise the vendor, subprocessors, foundation model providers, incidents, and service changes?
• For Rule 3.3, what policy required lawyers to verify AI-assisted output before using it in tribunal-facing work?

If the vendor cannot answer a concrete question about data use, model dependency, subprocessor access, incident procedure, or unilateral change rights, that silence is itself part of the risk assessment. The firm can approve, restrict, delay, or reject the tool, but the decision should tie each vendor request to a professional responsibility duty and preserve the evidence reviewed.

References

1. ABA Formal Opinion 512, American Bar Association, July 2024.
2. AI Ethics in Law (2026): ABA Guidance & State Requirements, Clio.
3. AI Procurement and Vendor Selection, Texas Bar Practice.
4. Legal Ethics and Practical Considerations for Lawyers Using AI, ABA Business Law Today, July 2026.
5. Navigating AI Vendor Contracts and the Future of Law, Stanford Law School / CodeX, 2025.
6. AI Legal Ethics in 2026, GC AI.