AI Vendor Due Diligence Checklist
The vendor file ABA Formal Opinion 512 expects, carriers request at renewal, and disciplinary investigators read first. Eleven items, mapped to recognized security and AI risk frameworks.
On this page
Why a vendor checklist
Under Rule 5.3, ABA Formal Opinion 512 treats AI providers the same way it treats any other non-lawyer assistance. The Opinion calls out reference checks, security policies, confidentiality terms, conflicts screening, and provider rights to submitted content. This checklist turns that guidance into eleven items that produce a defensible vendor file.
Carriers are starting to look at it too. Renewal applications increasingly ask whether the firm maintains a documented vendor diligence record for each AI tool in use. A signed and dated entry against this checklist, per tool, is the artifact that answers the question.
Each item below names the question to ask the provider and what an acceptable answer looks like. It also lists the red flags that signal a provider is not yet a Tier 1 (Approved) fit under Section 3 of our policy template. Tool risk tiers (Tier 1/2/3) are distinct from data classification tiers (Public / Internal / Confidential / Highly Sensitive) in Section 6.
How to use this checklist
- One file per tool. Maintain a single file per approved tool. The file contains one completed pass against this checklist plus the supporting documents (DPA, BAA, SOC 2 letter, subprocessor list, public docs).
- Date and sign. Each completed pass is dated and signed by the partner or designee responsible for that tool. Without a date, an old assessment cannot be distinguished from a current one.
- Map answers to your tier. Items 1-5 and 8-11 are Tier 1 gating. A tool that fails any of those is at most Tier 2 (limited use, no confidential client information).
- Refresh annually and on material change. AI provider posture moves quickly. New subprocessors, changes to default training behavior, and changes to retention defaults all warrant a fresh pass.
The 11-item checklist
For each item: the question to ask the provider, what an acceptable answer looks like, and the red flag that signals inadequacy.
1. No model training on customer data RPC: RPC 1.6
Question to ask: Does the provider, or any integrated application provider, use customer prompts, uploads, or outputs to train, fine-tune, or otherwise improve its models or services?
What good looks like: A written, contractual no-training default with any opt-in clearly disclosed and not bundled with terms of service.
Red flag: Training opt-out only; opt-out applies only to "future" use; opt-out applies only to one tier; opt-out requires support-ticket request.
2. Purpose limitation on customer data RPC: RPC 1.6
Question to ask: For what purposes may the provider use submitted content? Is use limited to providing the contracted service, complying with law, enforcing terms, and preventing abuse?
What good looks like: Explicit, narrow list of permitted purposes. Improvement, marketing, or analytics not on the list without separate consent.
Red flag: "Improving our services" and similar open-ended purposes; rights granted to "affiliates" without naming or limit.
3. Data retention and deletion RPC: RPC 1.6
Question to ask: How long is submitted content retained? When can the firm trigger deletion? What is the maximum lag between deletion request and actual deletion across all systems and backups?
What good looks like: Zero-data-retention option for the relevant API or interface; documented deletion within a reasonable period after user-initiated deletion or account termination.
Red flag: Retention "for the duration of our legitimate business purposes"; no zero-retention option; backups never expire.
4. Data isolation RPC: RPC 1.6
Question to ask: Is firm or client content isolated from other tenants? Are vector embeddings, caches, and intermediate model state isolated as well as primary content?
What good looks like: Tenant isolation at the application layer and at any retrieval-augmented generation (RAG) layer the provider runs.
Red flag: Isolation only at the application layer with shared embeddings or shared caches.
5. Data residency RPC: RPC 1.6, state law
Question to ask: In what jurisdictions is data processed and stored? Is residency contractually committed, or is it a current operational practice that may change?
What good looks like: Contractually committed processing jurisdictions, with a Data Processing Addendum (DPA) where applicable.
Red flag: Residency described in marketing only; "may transfer to subsidiaries worldwide"; no commitment around model-training jurisdictions.
6. User and matter anonymity RPC: RPC 1.6
Question to ask: Where the firm sends API requests, do those requests include identifiable client or firm metadata that the provider could correlate across requests?
What good looks like: Provider supports requests that do not require client-identifying metadata; firm-side practice strips identifying detail before submission where possible.
Red flag: Provider requires user-level or matter-level identifiers as a condition of access. No contractual confidentiality covers those identifiers.
7. Compliance with applicable privacy laws RPC: RPC 1.6, state and federal privacy law
Question to ask: Does the provider commit to the privacy laws that govern the data the firm will submit? Relevant regimes include state consumer-privacy statutes, HIPAA where PHI may be involved, GLBA where financial information may be involved, and applicable cross-border rules.
What good looks like: Documented compliance program; willingness to execute supplementary agreements (DPA, BAA) where applicable; named regulatory regimes in the contract.
Red flag: "We comply with all applicable laws" without specificity. Refusal to sign a BAA before PHI is uploaded.
8. Breach notification RPC: RPC 1.6, RPC 1.4, state breach-notification law
Question to ask: After a security incident affecting firm data, what is the provider's notification timing, content, and channel? Which incidents trigger notification?
What good looks like: Defined notification timing in business hours or days; defined incident scope (not limited to "confirmed unauthorized access"); single named contact channel.
Red flag: Notification "without undue delay" without numeric timing. Notification only for "confirmed" breaches. Notification only via product UI.
9. Risk management framework evidence RPC: RPC 1.1, 1.6
Question to ask: Has the application been developed, deployed, and maintained against a recognized information-security framework? Has the AI component been assessed against an AI-specific risk framework?
What good looks like: Current SOC 2 Type II report or ISO 27001 certification, available under NDA. Documented use of NIST AI RMF or OWASP GenAI Security Project for AI-specific controls. Penetration-test summary available on request.
Red flag: Marketing references to "SOC 2" without "Type II" or without a current report. No AI-specific risk framework named. Refusal to share even a summary letter.
10. Third-party and subprocessor access controls RPC: RPC 1.6, 5.3
Question to ask: Does the provider use subprocessors (cloud providers, model providers, infrastructure partners)? Are those subprocessors named, and are they bound to equivalent confidentiality and security obligations?
What good looks like: Public subprocessor list; contractual flow-down of confidentiality and security obligations; notice requirement before adding new subprocessors.
Red flag: No public subprocessor list; subprocessor changes do not require notice; "we contract with industry-leading providers" without naming any.
11. Supplementary agreements (DPA, BAA, FedRAMP) RPC: RPC 1.6
Question to ask: Does the provider offer a Data Processing Addendum (DPA) for personal data, a Business Associate Agreement (BAA) for protected health information, and any sector-specific instruments the firm's practice may require?
What good looks like: Standard DPA available without negotiation friction; BAA available before PHI is uploaded; willingness to negotiate sector-specific clauses for matter-specific risk.
Red flag: DPA available "for enterprise customers only"; BAA requires custom legal review before any pilot; refusal to entertain matter-specific clauses.
Framework references
Grounded in the AI risk management and information security frameworks most likely to be cited by a malpractice underwriter, a court reviewing AI-related sanctions, or a state-bar disciplinary panel:
- NIST AI Risk Management Framework (AI RMF 1.0): U.S. National Institute of Standards and Technology framework for AI risk identification, measurement, management, and governance. Cited in NIST publications and increasingly referenced in state AI legislation. See the AI RMF 1.0 framework page for a compliance walkthrough, and the NIST GenAI Profile for the generative-AI-specific overlay. Firms pursuing certifiable AI-management-system compliance should review ISO/IEC 42001.
- OWASP GenAI Security Project: industry-led top-risks taxonomy for generative AI applications, including the LLM Top 10 (prompt injection, training data poisoning, sensitive information disclosure, and others). See the OWASP GenAI Security Project.
- SOC 2 Type II: AICPA service-organization control report. The Type II variant evidences operating effectiveness over a period (typically 6 to 12 months), not just point-in-time design. Treat SOC 2 Type II as the floor for any tool that will receive Confidential or Highly Sensitive client data. Section 6 of the Policy Template defines the data classification, which is distinct from the Tier 1/2/3 tool risk tiers in Section 3.
- ISO/IEC 27001: international information security management standard. ISO 27001 certification often substitutes for or supplements SOC 2, especially when a provider serves global customers.
- NSA/CISA Joint Guidance on Secure AI System Deployment: federal cybersecurity agencies\' joint information sheet on secure AI deployment. Useful as a baseline for evaluating provider deployment posture; not a certification regime.
Citing a framework in the policy is not the same as a tool having been assessed against it. Ask for the report or the assessment, not just the logo.
Notes for small and mid-size firms
Most 5 to 50 attorney firms have no dedicated security or compliance function to run a full SOC 2 review of every AI provider. Solo practitioners and 50-100 attorney boutiques without an in-house CISO recognize the same shape. Practical adaptations:
- Lean on the public trust center. Most major AI providers publish a trust center (for example, OpenAI Trust, Anthropic Trust Center, Google Cloud Trust Center, Microsoft Service Trust Portal) that aggregates current SOC 2, ISO 27001, DPA, BAA, and subprocessor information. For high-volume vendors, file the trust-center URL against this checklist as the primary artifact.
- Group-purchase diligence. Where the firm uses a tool through a practice-management vendor (Clio, MyCase, PracticePanther, Centerbase) or a research provider (Westlaw, Lexis, vLex), much of the diligence has been done at the platform layer. Confirm that the AI feature inherits the platform\'s confidentiality posture; do not assume.
- Write down the gap. Where the firm lacks the ability to verify a specific item, document the gap rather than leave it blank. A documented gap is supervisable; a blank box reads as no review at all.
- Talk to your carrier or broker. Some malpractice brokers now circulate a short vendor evaluation form. If your broker has one, complete this checklist and theirs together; the overlap is high but their form may surface carrier-specific questions.
Mapped to Policy Template, ABA Formal Opinion 512 (July 2024), NIST AI RMF 1.0, OWASP GenAI Security Project, SOC 2 Type II, and ISO/IEC 27001. Last verified 2026-04-29.