AI vendor due diligence is the structured pre-procurement process of evaluating an AI tool vendor across multiple dimensions — security, data handling, accuracy, financial stability, regulatory compliance, and contractual terms — before the law firm commits to using the vendor's product with client data. For attorneys, vendor due diligence is not merely a business best practice: it is a component of the professional responsibility obligation to make "reasonable efforts" to protect client information when using cloud or AI services (ABA Model Rule 1.6(c) and its state equivalents).
The legal AI vendor landscape has matured significantly but remains varied in its data practices, security postures, and contractual standards. Some vendors have invested heavily in legal-grade data protection, operating with zero-training commitments, separately managed customer data environments, and enterprise-grade security certifications. Others offer products with less rigorous data handling that may be adequate for non-sensitive use cases but inappropriate for client-confidential legal work. Vendor due diligence is the mechanism by which firms identify and act on these distinctions.
Acquisitions in the legal AI market have added a dimension to due diligence: a vendor whose practices are adequate today may be acquired and operated differently tomorrow. Casetext was acquired by Thomson Reuters. Evisort was acquired by Workday. Kira Systems was acquired by Litera. Each acquisition brought changes to ownership, commercial incentives, and potentially data handling practices. Due diligence must account for acquisition risk and must specify contractual protections against it.
Bar ethics opinions across jurisdictions consistently identify pre-engagement due diligence on cloud and AI providers as a required component of attorney competence and confidentiality compliance. The California State Bar, New York State Bar, and ABA (in Formal Opinion 512, 2023) have all articulated standards requiring attorneys to investigate how service providers handle client data before engaging them.
From a malpractice perspective, inadequate vendor due diligence creates exposure in both directions. If a vendor suffers a breach that exposes client data, and the firm cannot demonstrate that it conducted reasonable due diligence before selecting the vendor, the firm's position in any resulting malpractice or bar complaint is significantly weakened. Conversely, if a vendor is using client data to train its models — creating a permanent record of client confidences in the vendor's model weights — and the firm did not investigate this practice before engaging the vendor, the firm has arguably violated its confidentiality obligations regardless of whether a breach ever occurs.
Practically, vendor due diligence also serves the firm's operational interests. A vendor that does not survive financially, whose tool performs poorly on the firm's actual use cases, or whose contract terms are unreasonably one-sided creates business problems beyond the ethical and legal dimensions. Due diligence on financial stability, performance, and contractual terms protects the firm's investment and operational continuity.
How It Works
Thorough AI vendor due diligence proceeds through seven domains.
Domain 1: Data security. Request and review the vendor's most recent SOC 2 Type II report. This report, produced by an independent CPA firm, evaluates the vendor's security controls across five trust service criteria (security, availability, processing integrity, confidentiality, and privacy). Note the audit period — a SOC 2 report more than 18 months old may not reflect current controls. Also request ISO 27001 certification (if applicable), penetration test result summaries, and information about encryption standards (at rest and in transit) and access control architecture.
Domain 2: Data handling practices. The most critical question is whether the vendor trains or fine-tunes AI models on customer data. Get a clear, written answer in the vendor questionnaire and ensure the answer is reflected in the DPA. Request the vendor's complete subprocessor list, which reveals every third party with access to customer data. Clarify data residency: where is data stored, processed, and backed up, and what legal regime governs that data? What is the data deletion process on contract termination, and on what timeline is deletion completed?
Domain 3: Regulatory compliance. For vendors processing EU client data, review the GDPR data processing agreement terms against Articles 28 and 32 requirements. For vendors processing data of California residents, verify CCPA service provider terms. If the vendor's AI system may qualify as high-risk under the EU AI Act for your intended use case, assess the vendor's Act compliance status. For healthcare-adjacent legal work, verify HIPAA Business Associate Agreement availability.
Domain 4: AI accuracy and reliability. This domain is the most challenging because AI performance data from vendors is self-reported and typically measures performance on vendor-selected benchmark datasets rather than the firm's actual use cases. Request any available independent benchmark data. Ask specifically about hallucination rates for the tool's primary functions (legal research, contract analysis, document drafting). If the vendor cannot provide independent accuracy data, plan to conduct your own testing using representative firm documents before full deployment. Tools like Kira Systems, Luminance, and Ironclad have varying bodies of independent testing data available.
Domain 5: Financial stability. For startup vendors and Series A/B companies, financial stability is a genuine risk. Request funding history, current investor commitments, and any information about revenue base or runway. For established vendors, review public financial information or ask about the vendor's revenue scale. This is not about avoiding all startup vendors — some of the best legal AI tools are from startups — but about understanding continuity risk and planning accordingly (including data portability provisions in the contract).
Domain 6: Contractual terms. The DPA is the primary legal vehicle for data protection commitments. Key provisions: no-training clause, subprocessor notification rights, data deletion on termination with timeline and certification, breach notification timelines (ask for 48-72 hours), audit rights (at minimum, the right to receive current SOC 2 reports; ideally, the right to request additional security assessments), and change-of-control provisions giving the firm termination rights on acquisition.
Domain 7: Support and implementation. How does the vendor onboard new clients? What training resources are available? What is the support response model for production issues? What is the vendor's incident response process, and who is the firm's designated contact for security incidents? These operational factors affect whether the firm can actually use the tool effectively and whether vendor commitments will be honored in practice.
Key Considerations for Law Firms
Create a standardized due diligence questionnaire. Developing a firm-standard AI vendor questionnaire — covering all seven domains — ensures consistent evaluation across all vendor assessments and creates a documentation record of the firm's diligence process. The questionnaire should be updated annually to reflect regulatory developments and lessons from vendor assessments.
Read the DPA before the main agreement. Law firms that review the commercial terms carefully but sign the DPA without reading it are doing backwards due diligence. The DPA is where the data protection commitments (or their absence) live. Every provision in the commercial agreement that says "as described in the Data Processing Agreement" refers to a document that must be independently reviewed.
Test before you commit. Most reputable legal AI vendors offer trial periods or pilot programs. Use them. Testing should include documents from actual use cases — not just the clean, well-formatted examples that vendors use in product demonstrations. Test with the kinds of documents the firm actually processes: unusual drafting conventions, multi-language documents, non-standard formats. Document test results as part of the due diligence record.
Revisit due diligence after acquisitions. When a vendor is acquired, the due diligence conducted at the time of initial engagement may no longer be accurate. The new owner's data handling practices, corporate policies, and commercial incentives may differ materially. Firms should treat vendor acquisitions as triggers for re-evaluation — reviewing the DPA for change-of-control protections and, where necessary, renegotiating terms with the new owner.
Limitations and Risks
Vendor representations may not reflect technical reality. A vendor may represent in their questionnaire that they do not train on customer data, while their technical architecture creates logs or fine-tuning artifacts that effectively incorporate customer data into model behavior. Contractual representations are not the same as technical controls. Firms should request architectural documentation that explains how the no-training commitment is implemented, not just asserted.
SOC 2 coverage gaps. SOC 2 reports cover specific systems and services defined in the audit scope. A vendor's core platform may be SOC 2 certified while new modules, integrations, or acquired products are not. Verify that the firm's specific intended use case falls within the SOC 2 audit scope.
Due diligence is a point-in-time activity without ongoing monitoring. The risk that due diligence is conducted at contract signing but not updated over the relationship is significant. Vendor practices change. Regular re-evaluation — at least annually and upon any material vendor change — is necessary to maintain a current risk picture.