Legal AI Vendor Due Diligence Checklist: 40 Questions Law Firms Should Ask

An impressive demo does not show what happens to a client document after upload. It also does not reveal who can access the data, which model receives it, or what happens when the contract ends. A legal AI vendor due diligence checklist turns those hidden issues into questions your firm can answer before it buys or approves a tool.

This guide provides 40 questions for a structured review. It covers the proposed use, data flows, security, professional duties, output testing, contract terms, operations, monitoring, and exit planning. It offers a business and risk-management framework, not legal advice. Your firm should apply the rules, client terms, and privacy laws that govern each matter and jurisdiction.

What a Legal AI Vendor Due Diligence Checklist Should Accomplish

A legal AI vendor due diligence checklist should help the firm decide whether a specific product is safe enough for a specific use. Approval should never rest on the tool’s brand, popularity, or a general claim that it was “built for legal.”

The review should produce a written record of five things:

• what the firm plans to do with the tool;
• what data the tool will receive or reach;
• what evidence the vendor supplied;
• which risks remain after controls are applied; and
• who approved the decision, with what limits and review date.

This use-based approach matches the NIST Generative AI Profile, which calls for risk assessment throughout acquisition, deployment, monitoring, incident response, and decommissioning. NIST also recommends contracts that address ownership, security, service levels, and third-party AI processes.

Start With the Use Case, Not the Product Name

The same tool may present very different risks across tasks. Drafting an internal meeting agenda with no client data is not the same as summarizing medical records. A system that only suggests text is not the same as an agent that can email clients or update matter records.

Before using the legal AI vendor due diligence checklist, write a one-sentence use case. Name the users, the information involved, the output, and the action that follows. For example: “Paralegals will use the tool to summarize client-provided medical records, and a lawyer will verify every summary before it enters the matter file.”

Use the Legal AI Vendor Due Diligence Checklist as an Evidence Log

“We take security seriously” is not evidence. A current audit report, system diagram, written retention schedule, test result, contract clause, or live configuration review is evidence. Record the document’s date and scope because a certificate may exclude the product, model, or infrastructure your firm will use.

Use the legal AI vendor due diligence checklist as an evidence log. If a vendor cannot answer a material question in writing, mark the answer as unknown. An unknown answer should not quietly become a pass.

Classify the Risk Before You Review the Vendor

The depth of review should match the proposed use. A small firm does not need enterprise paperwork for every low-risk experiment. It does need stronger controls when the system reaches sensitive data or can take action without a person.

Use four practical risk levels:

1. Low risk: public or synthetic data; internal brainstorming; no legal conclusion; no external action.
2. Moderate risk: internal administrative work using limited firm data; a person checks the result before use.
3. High risk: confidential client data, legal research, drafting, document review, billing, or client communication.
4. Very high risk: agentic access to email, document stores, calendars, payment systems, filings, or other tools that can act without a fresh prompt.

The State Bar of California’s 2026 practical guidance says greater system autonomy calls for greater supervision and verification. It also warns that agentic systems may have persistent access to email, document systems, client files, and calendars. Firms should therefore narrow access and keep meaningful lawyer review at decision points.

The 40-Question Legal AI Vendor Due Diligence Checklist

Assign an owner to each section. Firm leadership should oversee the decision. Lawyers should assess professional duties and work quality. Privacy, security, and IT advisers should review the parts that need their expertise. The Canadian Bar Association’s AI ethics toolkit likewise stresses that the selection and use of AI must align with professional obligations.

1. Purpose, Scope, and Product Architecture

The first five questions test whether the product matches the task. They also reveal what sits behind the vendor’s interface. Many products depend on outside model providers, data services, plug-ins, or hosting companies.

1. What exact use cases does the vendor support, and which uses does it prohibit? Ask for written limits, not only demo examples.
2. Is the product a model, an application built on another model, or an agent connected to other systems? Your team needs to know where responsibility and data access sit.
3. Which model providers, hosting services, plug-ins, and subprocessors support the product? Request a current list and a change-notice process.
4. What tools or firm systems can the product read from, write to, or act within? Include email, calendars, document stores, billing, client portals, and practice management platforms.
5. Can the firm disable unneeded features, connectors, memory, external actions, or autonomous steps? Safer configuration often starts with less access.

The legal AI vendor due diligence checklist should record the approved configuration, not merely the product name. A future feature update may change the risk even if the vendor remains the same.

2. Data Collection, Training, and Retention

Data terms deserve their own review because “not used to train” may not answer every question. A provider may still retain prompts for support, use information for evaluation, or send content to a subprocessor.

6. What data does the product collect from prompts, uploads, connectors, metadata, logs, and user feedback? Ask for a full data inventory.
7. Where does each data type travel, get processed, and remain stored? Request a data-flow diagram that includes subprocessors and backup locations.
8. Does any customer content support model training, fine-tuning, evaluation, safety review, product improvement, or human labeling? Define these uses separately in the answer.
9. What are the default and configurable retention periods for prompts, files, outputs, logs, embeddings, temporary copies, and backups? Confirm when deletion becomes effective.
10. Can the firm retrieve and delete data by user, client, matter, workspace, and account? Test this during the pilot instead of accepting a policy statement.

The Office of the Privacy Commissioner of Canada advises organizations to map data flows, confirm each use, identify subprocessors, assess cross-border handling, and examine end-of-contract deletion. That guidance is especially useful for Canadian firms subject to PIPEDA, but the questions are sound procurement practice elsewhere too.

In this section, the legal AI vendor due diligence checklist should link every answer to a policy, diagram, setting, or contract term. That makes later review faster and limits disputes about what the vendor promised.

3. Security, Identity, and Access Controls

Security review asks whether the vendor’s controls fit the data and use case. A certification can support the review, but it does not replace reading the report’s scope, exceptions, and customer responsibilities.

11. How is data encrypted in transit and at rest, and who manages the encryption keys? Ask whether any processing stage exposes readable content.
12. Does the product support single sign-on, multi-factor authentication, role-based access, session controls, and prompt user removal? Confirm which controls cost extra.
13. How does the system separate one firm’s data from another firm’s data and one matter from another? Test search, retrieval, history, and connector behavior.
14. What independent security assessments cover the service, and what dates, systems, and exceptions appear in the reports? Examples may include a SOC 2 report or a penetration test.
15. How will the vendor detect, contain, investigate, and notify the firm about a security incident? Put notice timing, contacts, cooperation, and evidence preservation in writing.

The AICPA describes SOC 2 as an examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy. The legal AI vendor due diligence checklist should still confirm that the report covers the AI service and period under review.

4. Confidentiality, Privacy, and Professional Duties

Lawyers remain responsible for professional duties when a vendor handles part of the work. In the United States, the ABA’s Formal Opinion 512 summary connects generative AI use to competence, confidentiality, communication, and reasonable fees. The governing rule in each jurisdiction may differ, so firms must check local authority.

16. How does the proposed use support the lawyer’s duty of competence and independent judgment? Define what users must understand and verify.
17. What safeguards help prevent unauthorized access to or disclosure of client information? ABA Model Rule 1.6(c) calls for reasonable efforts against unauthorized access or disclosure.
18. When would client notice, consultation, consent, or compliance with outside counsel guidelines be needed? Review the use, matter terms, client instructions, and local rules.
19. Can the vendor support data-residency, privacy, health-information, or sector-specific terms that apply to the firm’s work? Confirm availability by plan and location.
20. Will the vendor sign the required data-processing, confidentiality, or business-associate terms? For covered U.S. health-data uses, consult the HHS model business associate agreement and qualified counsel.

A legal AI vendor due diligence checklist cannot decide the law for every practice. It can force the firm to identify the right questions before confidential information enters the system.

For high-risk uses, the legal AI vendor due diligence checklist should also record the rule, client term, or legal requirement behind each condition. A reviewer can then see why the condition exists and when it needs legal review.

5. Output Quality, Testing, and Human Review

Accuracy is a workflow issue as much as a model issue. A benchmark score may not predict performance on your firm’s documents, jurisdictions, writing style, or languages. Test the product with representative, non-sensitive material before any live rollout.

21. What tasks has the vendor tested, and do the test conditions match the firm’s use case? Ask for the method, sample, comparison point, date, and limitations.
22. How does the product show sources, quotations, uncertainty, and the difference between retrieved facts and generated text? Users need a clear path back to original material.
23. What known failure modes affect citations, calculations, summaries, dates, names, privilege, bias, or incomplete records? Ask how the vendor measures and reports them.
24. Can the firm create a mandatory human-review step before an output is sent, filed, billed, or written into another system? The system should support the firm’s approval boundary.
25. Can the firm export enough logs and source context to reconstruct how a material output was produced and reviewed? Decide what the firm will retain in the matter record.

The legal AI vendor due diligence checklist should include an acceptance test. Use a fixed set of tasks, expected answers, prohibited actions, and review criteria. Record failures as well as successful results. For substantive work, lawyers should verify the result against primary sources and the actual matter record.

Repeat the legal AI vendor due diligence checklist when a test exposes a new data flow or automated action. The review must cover the product that users will actually operate, not the simpler version shown in a sales demo.

6. Contract Terms, Ownership, and Liability

Sales material can change. The signed agreement controls the relationship. Compare the contract, privacy notice, data-processing addendum, security schedule, service levels, and product documentation for conflicts.

26. Who owns prompts, uploaded files, outputs, feedback, derived data, configurations, and custom workflows? Remove vague rights that are broader than service delivery requires.
27. Can the vendor change data-use terms, subprocessors, models, features, or security commitments without meaningful notice? Ask for notice, objection, and termination rights.
28. How does the contract allocate responsibility for confidentiality failures, security incidents, intellectual-property claims, service errors, and lost data? Review exclusions and liability caps.
29. What service levels apply to uptime, support, incident response, recovery, and critical defects? Confirm the remedy and whether it matters in practice.
30. What audit, assessment, information, and cooperation rights does the firm receive? The firm needs a workable way to confirm ongoing compliance.

NIST recommends contracts and service-level agreements that cover ownership, usage rights, quality, security, and content provenance. It also recommends terms that permit evaluation of third-party AI processes. Use the legal AI vendor due diligence checklist to turn each relied-upon promise into a contract term or documented control.

The completed legal AI vendor due diligence checklist should point to the final signed language. A promise in an email or security portal may not control if the agreement says something different.

7. Integration, Administration, and Daily Operations

A safe product can still fail if people cannot administer it. Review how the tool joins the firm’s identity, matter, document, calendar, and communication systems. Define the source of truth for each record.

31. Who will administer accounts, permissions, connectors, approved use cases, and configuration changes? Name a primary owner and backup.
32. Can access be limited by role, office, practice group, client, and matter? Confirm support for ethical walls or restricted matters where needed.
33. What data will move between the AI product and the firm’s existing systems, and how will duplication or conflicts be handled? Map each direction and trigger.
34. What training, usage guidance, support, and escalation does the vendor provide for lawyers and staff? Generic product tours are not enough for high-risk workflows.
35. What will the product cost over the full term, including implementation, connectors, storage, usage, support, training, and exit? Compare total cost with the value of the approved use.

The legal AI vendor due diligence checklist should lead to a rollout plan. Start with a narrow pilot, named users, synthetic or approved test data, and a clear stop condition. Do not connect every repository on the first day.

8. Monitoring, Change Management, and Exit

Approval is a dated decision, not a permanent label. Models, subprocessors, terms, integrations, and risks can change after launch. The firm needs a way to spot changes and withdraw safely.

36. How will the vendor notify the firm about model changes, new features, changed subprocessors, incidents, material performance shifts, and revised terms? Define what counts as material.
37. Which logs, reports, alerts, and audit records can the firm review during use? Confirm retention, access, export, and administrator visibility.
38. How often will the firm retest the product, review permissions, and confirm that the use remains within approval? Set event-based reviews as well as calendar dates.
39. Can the firm export its content and records in a usable, non-proprietary format before termination? Test a sample export during the pilot.
40. What happens to active workflows, stored content, backups, custom settings, and connected systems when the service ends or fails? Require a deletion process, evidence of completion, and a fallback plan.

The legal AI vendor due diligence checklist should name an exit owner before launch. The best time to test export, deletion, and manual fallback is while the vendor still wants the firm’s business.

How to Score the Legal AI Vendor Due Diligence Checklist

Use three simple outcomes for every question:

• Pass: Current written evidence meets the firm’s requirement.
• Conditional: The answer can be accepted only with a stated contract term, configuration, workflow control, or deadline.
• Fail: The answer creates unacceptable risk, conflicts with a requirement, remains unknown, or cannot be supported.

Do not turn the legal AI vendor due diligence checklist into a simple percentage. Some failures matter more than 10 minor passes. Define gating issues before the review so commercial pressure does not change the standard later.

Set Gating Conditions

Common gates include unauthorized secondary data use, missing access controls, no workable confidentiality terms, no human approval before external action, an unacceptable incident process, or no usable exit path. The right gates depend on the use case and governing requirements.

The review team should choose one of four decisions: approve, approve with conditions, pilot only, or reject. Record the approved users, data, workflows, integrations, controls, owner, and review date. Attach the evidence pack to the decision.

Test With Low-Risk Data First

A pilot should test normal work and predictable failure. Include ambiguous instructions, incomplete documents, incorrect citations, conflicting dates, restricted content, and attempts to trigger an unapproved external action. Confirm that users can recognize and report problems.

Use the legal AI vendor due diligence checklist again after the pilot. A strong paper response can still fail in practice. A pilot result may also reveal that a narrower use can be approved even when the broader proposal cannot.

Best Practices for a Defensible Review

Use a Cross-Functional Team

No reviewer sees every risk. A lawyer can assess professional judgment and client duties. IT can review identity and integrations. A privacy or security adviser can test data terms and controls. Operations can judge whether the workflow is usable.

ABA Model Rules 5.1 and 5.3 provide a useful U.S. model for supervisory measures. They do not replace the rules in the firm’s jurisdiction.

Keep a Dated Evidence Pack

Store the completed legal AI vendor due diligence checklist with the data-flow diagram, security reports, test plan, test results, contract documents, approved configuration, training material, decision, and review date. Link each condition to an owner.

Keep the legal AI vendor due diligence checklist current.

Review Material Changes

Set a regular review date, but do not wait for it after a major change. Reassess when the vendor changes its model, subprocessors, data uses, retention, contract, integrations, or agentic features. Reassess after an incident or when the firm expands the tool to a new practice area or data type.

Keep the prior legal AI vendor due diligence checklist with each new version. The comparison will show what changed, which conditions remain open, and whether the approval still fits the use.

Common Mistakes to Avoid

Treating a Certificate as the Whole Review

A certification can show that defined controls were examined. It does not prove that every AI feature is accurate, that every subprocessor is covered, or that the contract fits the firm’s duties. Read the period, scope, exceptions, and customer responsibilities.

Accepting “No Training” Without Definitions

Ask about fine-tuning, evaluation, feedback review, support access, embeddings, logs, and product improvement. The legal AI vendor due diligence checklist separates these uses because one broad answer can hide several data paths.

Approving the Tool for Every Possible Use

Approval should attach to a use case and configuration. A writing aid approved for public marketing copy should not become an approved system for confidential discovery without a new review.

Forgetting the Exit Until Renewal

Without a tested export and deletion plan, the firm may discover lock-in when time is short. The newest Canadian privacy guidance on third-party providers specifically tells organizations to assess vendor lock-in, portability, service failure, retention, and end-of-contract procedures.

Put the Decision Into the Firm’s Operating System

The approval record should connect to daily work. Add the product to an approved-tools list. State which users, matters, and data types are allowed. Put review steps inside the workflow. Train users, monitor exceptions, and create a simple way to report errors or unexpected behavior.

This is where legal practice management supports governance. A centralized system can keep matter records, policies, documents, tasks, and communications connected. It does not replace the legal AI vendor due diligence checklist or professional review. It helps the firm apply the decision consistently.

RunSensible’s guide to a practical law firm AI policy can help turn approval conditions into internal rules. Its discussion of ethical controls for automated legal workflows provides related guidance for human review and accountability.

Frequently Asked Questions

Who should complete a legal AI vendor due diligence checklist?

The team should include a decision-maker, a lawyer familiar with the proposed work, and people responsible for privacy, security, IT, and operations. A solo firm may use outside help for technical or contract issues it cannot assess alone.

Is a SOC 2 report enough to approve a legal AI vendor?

No. It can provide useful evidence about defined controls during a stated period. The firm still needs to confirm scope, exceptions, subprocessors, data use, product behavior, contract terms, output testing, and the proposed workflow.

Can a firm enter confidential client information into a legal AI tool?

The answer depends on the tool, use, safeguards, client terms, governing professional rules, and applicable law. Do not assume that a paid or legal-branded product is approved for confidential data. Complete the review and obtain jurisdiction-specific advice where needed.

How often should the firm repeat its review?

Set a regular review based on risk, such as every 6 or 12 months. Also repeat the review after material changes to models, terms, subprocessors, data use, integrations, autonomy, or security. An incident or new use case should trigger another review.

Should the firm ban a vendor that cannot answer every question?

Not every gap has the same weight. A low-risk use may proceed with limits, while a missing confidentiality or deletion commitment may block a high-risk use. Record gaps as conditions or failures instead of treating silence as approval.

What is the difference between vendor due diligence and an AI policy?

Vendor due diligence evaluates whether a product is suitable for an approved use. An AI policy tells lawyers and staff which tools and uses are allowed, what data rules apply, and how outputs must be reviewed. The two controls should refer to each other.

Does the checklist apply to AI built into software the firm already uses?

Yes. Embedded AI can create new data flows, model providers, retention terms, outputs, and actions. Review the feature and proposed use even when the main platform was approved before the AI capability existed.

Conclusion

A law firm should be able to explain why an AI tool was approved, what it may do, what information it may receive, and how people will check its work. It should also know how to respond when the product changes or fails.

The legal AI vendor due diligence checklist makes that decision visible and repeatable. Define the use, ask for evidence, test with low-risk data, set clear gates, document conditions, and plan the exit before launch. A narrow, well-supported approval is more useful than a broad approval built on assumptions.

Resources

1. ABA Formal Opinion 512 summary for U.S. professional-duty issues raised by generative AI.
2. NIST Generative AI Profile for acquisition, third-party risk, monitoring, incident response, and decommissioning controls.
3. State Bar of California practical guidance for generative and agentic AI supervision.
4. Canadian Bar Association AI ethics toolkit for professional obligations in Canadian practice.
5. Office of the Privacy Commissioner of Canada third-party guidance for data flows, subprocessors, monitoring, portability, and exit planning.