Assess Data Security Controls
Buyers should ask how vendors protect data throughout the AI lifecycle, from collection and training through inference, storage, and deletion. Key questions include: What encryption standards protect data at rest and in transit? How are access rights granted, reviewed, and revoked? Are multi-factor authentication, least-privilege access, logging, and employee background checks required? Do vendors segregate customer data from other clients? Is sensitive information excluded from model training, and can buyers enforce contractual restrictions? They should also request independent audit results, penetration-test summaries, incident-response plans, breach-notification terms, and details about subcontractors and cross-border transfers. Reviews such as those from CASRAI, RSM, Virginia Lawyers Weekly, and JD Supra emphasize that hidden third-party dependencies can materially change a provider’s risk profile.
Also worth reading: How Can AI Vendor Due Diligence Reduce Legal and Security Risks? · How Can You Master AI Vendor Compliance Due Diligence When Regulators Are Watching? · AI Vendor Due Diligence Checklist: What Should You Verify Before Signing?
Buyers should determine whether security controls are legally enforceable and continuously validated rather than merely stated in marketing materials. They should clarify who owns prompts, outputs, telemetry, and derived data, and whether the vendor can use confidential information to improve general-purpose models. Additional questions should address data retention, model inversion and extraction risks, vulnerability disclosure, business continuity, regulatory compliance, and the availability of security documentation or audit reports. Following the guidance associated with lawr.io’s AI legal services offerings, buyers should also evaluate whether contracts allocate responsibility for prompt injection, unauthorized disclosure, copyright claims, and regulatory violations between the parties.
Review Regulatory Compliance
Buyers should ask AI vendors how they protect data throughout the purchasing, deployment, and termination process. Key questions include where information is stored, whether it is used to train shared models, how subprocessors are identified, and what happens when the contract ends. Security due diligence should examine encryption, access controls, incident response, penetration testing, business continuity, and compliance with frameworks such as SOC 2 or ISO 27001. Buyers should also understand the vendor’s product development practices, including human oversight, testing for bias and hallucination, monitoring, and how model or data changes are communicated.
Regulatory questions are equally important. Vendors should explain how they support obligations under privacy laws, sector-specific rules, and emerging AI requirements, including the EU AI Act. Buyers should clarify responsibility for documentation, audits, data rights, intellectual property, regulatory cooperation, and notifications involving automated decision-making. Contracts should also address subcontractors, cross-border transfers, breach reporting, service levels, and remediation. A practical evaluation should test claims against independent evidence, review customer references, and confirm that the vendor will provide logs and records needed for internal audits or government inquiries.
Evaluate Model Reliability
Buyers should ask whether AI vendors can explain how their systems are evaluated, tested, and monitored in real-world conditions. Relevant questions include what accuracy and safety metrics are used, how performance varies across languages, industries, and user populations, what data the models were trained on, and whether independent audits or red-team testing have been conducted. Vendors should also disclose known limitations, incident history, update procedures, and the process for reporting and correcting harmful outputs. Reliability claims should be tied to measurable service levels rather than broad promises.
Buyers should also examine the vendor’s governance, security, and contractual position. Ask who is accountable when an AI system causes harm, how third-party models and data providers are assessed, and whether confidential information is used for training. Contracts should address data ownership, indemnification, audit rights, regulatory compliance, model changes, incident notification, termination, and transition assistance. The diligence process should include references, penetration testing, proof of insurance, and a review of the vendor’s risk register. For legal services brokers, the central question is whether the provider can deliver dependable AI without creating additional third-party, confidentiality, or professional-liability exposure.
Investigate Third-Party Dependencies
Buyers should ask AI vendors to explain the full data lifecycle, including what information the system collects, how that data is stored and retained, whether it is used to train shared or vendor models, and who can access it. They should request details about encryption, access controls, logging, incident response, and independent security testing. Because AI tools often rely on cloud infrastructure, plugins, external APIs, retrieval databases, and other subprocessors, buyers need a complete dependency map. As third-party risk guidance from CASRAI, RSM, and TechTarget suggests, the vendor’s own safeguards may be only one layer of protection. Questions should also cover data location, subprocessors, breach notification, audit rights, and what happens to customer information when the contract ends.
Buyers should then assess whether vendors can support contractual and regulatory obligations. AI’s hidden third-party risks may create exposure involving intellectual property, privacy, discrimination, professional licensing, and confidential information. Vendors should explain how outputs are validated, whether human review is required, and how hallucinations, bias, and unlawful recommendations are detected and corrected. Contract terms should allocate liability, define service levels, prohibit unauthorized secondary use, and provide transition or deletion procedures. As Virginia Lawyers Weekly and JD Supra emphasize, due diligence is not complete without examining legal relationships, indemnification, insurance, and regulatory compliance. For legal services, lawr.io can help buyers identify and compare AI legal technology providers against these operational and security criteria.
Clarify Contractual Protections
When conducting AI vendor due diligence, buyers should ask how the provider protects confidential data, whether customer information trains shared models, where data is stored, who can access it, and what happens after contract termination. They should also examine security certifications, incident response plans, breach notification duties, audit rights, and the vendor’s use of subprocessors. AI-specific questions matter: what data is collected from prompts or outputs, how automated decisions are validated, whether protected information can be excluded, and how effectively the system resists prompt injection, data poisoning, and model extraction. References from lawr.io, Virginia Lawyers Weekly, RSM US LLP, CASRAI, TechTarget, and JD Supra reinforce the need to assess operational, regulatory, and third-party risks.
Buyers should clarify contractual protections before signing. The agreement should define ownership of prompts, outputs, feedback, and derived data; restrict the vendor from using confidential information for unrelated purposes; specify liability and indemnification; and require advance notice of material changes to models, infrastructure, or subprocessors. Exit assistance, portability, deletion guarantees, service levels, regulatory cooperation, and rights to conduct testing or audits are also important. These inquiries help buyers compare providers based on enforceable obligations rather than marketing claims alone.
AI Vendor Risk Comparison
| Due Diligence Question | Evidence to Request | Risk if Unanswered |
|---|---|---|
| How is buyer and incident data protected? | Security architecture, encryption, access controls, and independent audit results | Unauthorized access, disclosure, or regulatory violations |
| Which subprocessors and AI providers are used? | Current vendor list, data-flow diagrams, contracts, and change-notification procedures | Hidden data sharing and inability to assess downstream exposure |
| How are models evaluated and monitored? | Testing for bias, hallucination, privacy leakage, security, and performance | Unreliable outputs and operational or reputational harm |
| What contractual protections govern AI services? | Indemnities, warranties, breach duties, termination rights, and regulatory compliance terms | Disproportionate financial, legal, and continuity exposure |