AI vendor due diligence must examine the service you will operate, not the vendor's reputation or a generic security questionnaire. AI services introduce model provenance, evaluation transfer, probabilistic failure, prompt and customer-data handling, safety controls, hidden model changes, tool permissions, human review, and foundation-model dependencies. A pilot can expose real data and people before procurement considers it production, so evidence depth should follow impact and exposure rather than the label pilot.
NIST SP 800-218A adds AI-model development practices to the Secure Software Development Framework and says the profile is useful to model producers, AI-system producers, and acquirers. The NIST Generative AI Profile addresses generative-AI risk across organizations. Together they support diligence that asks for lifecycle and risk evidence, not just an annual penetration-test letter.
Scope diligence to the exact service and use case
Document vendor legal entity, product, tier, region, deployment mode, model and version, subprocessors, foundation-model providers, data flows, integrations, tool permissions, users, affected people, intended purpose, prohibited uses, autonomy, business consequences, and pilot data. Confirm which assurances apply to that configuration. A certification for a corporate platform may exclude a newly acquired model service or customer-managed deployment.
Tier review by inherent impact: data sensitivity, decision consequence, scale, affected populations, reversibility, external actions, legal classification, criticality, and substitutability. Low-risk drafting with public text needs less evidence than a system ranking candidates or initiating payments. Set block criteria early so commercial urgency cannot convert missing evidence into an unexamined exception.
Run AI vendor due diligence through evidence gates
Use six gates: define use and role; map service and supply chain; verify model, data, security, and safety evidence; test the configured system; contract for change, incident, and audit duties; then authorize a bounded pilot or renewal with monitoring and exit. Each gate has an owner and decision. Keep vendor assertions, independent evidence, buyer tests, open gaps, compensating controls, and accepted residual risk separate.
| Evidence domain | Request | Verification | Blocking example |
|---|---|---|---|
| Model and evaluation | Versioned cards, methods, slices, limitations | Reproduce critical scenarios | No model identity or test conditions |
| Data and privacy | Flows, retention, training use, regions, deletion | Contract-to-architecture trace | Inputs used for training by default |
| Security | SDLC, threat model, access, testing, vulnerabilities | Assurance and technical review | No incident route or tenant boundary |
| Safety and oversight | Misuse analysis, filters, human controls, monitoring | Adversarial and usability tests | Unsafe action cannot be stopped |
| Operations | SLOs, change, continuity, support, exit | Failure and export exercise | No notice before model replacement |
Challenge model and evaluation evidence
Request model family, exact production version, hosting, lineage, intended and excluded uses, modalities, languages, context, known failures, evaluation data and provenance, inference settings, metrics, slices, confidence, red-team scope, mitigation state, and dates. Ask which evidence applies to your endpoint and tier. Benchmark summaries without test conditions do not support a release threshold.
Build your own acceptance tests using representative inputs, integrations, retrieval, tools, policies, and users. Include normal, edge, adversarial, accessibility, high-consequence, and refusal cases. Compare with the current process and measure error severity, distribution, human reliance, latency, and cost. Contract for the right to run reasonable evaluation and security testing without violating acceptable-use terms, with coordinated handling of findings.
Trace customer data, training use, and generated outputs
Map prompts, uploads, retrieved records, embeddings, fine-tuning data, logs, feedback, outputs, abuse-monitoring samples, support access, backups, and derived telemetry. For each, record purpose, controller or processor role where relevant, location, retention, access, encryption, deletion, subprocessors, model-training use, and opt controls. Verify that product configuration matches the data-processing agreement and sales promises.
Review rights to inputs and outputs, confidentiality, copyright policy, infringement handling, lawful data sources, and response to rights reservations. The Commission's GPAI Q&A explains model-provider obligations around technical documentation, copyright policy, and public training-content summaries. Those disclosures inform diligence but do not replace customer-specific contract terms or system-level legal review.
Test security and resilience beyond conventional SaaS controls
Assess tenant isolation, identity, privileged access, secrets, encryption, logging, secure development, dependency integrity, vulnerability management, model and data provenance, prompt injection, data exfiltration, training-data poisoning, model theft, unsafe tool use, denial of service, abuse monitoring, and incident response. Ask how controls differ for hosted APIs, downloadable models, fine-tuning, plugins, and agents. Connect findings to a system threat model.
CISA's Secure by Demand guide encourages customers to use purchasing power to demand secure technology. Translate that principle into contract commitments for secure defaults, multifactor authentication for administration, logging, vulnerability disclosure, support, and transparency. Then add AI-specific commitments. Exercise outage, quota exhaustion, provider compromise, unsafe output, and unavailable human-review paths before consequential deployment.
Expose the model supply chain and change policy
Identify base-model providers, hosting clouds, data vendors, safety services, evaluation vendors, human reviewers, and critical libraries. Ask which can access customer data, change behavior, or interrupt service. Require notice and approval rights proportionate to materiality for new subprocessors, model families, hosting regions, safety policies, and data uses. A vendor wrapping another API should not obscure the underlying dependency.
| Contract clause | Minimum protection | Operational proof | Renewal question |
|---|---|---|---|
| Model change | Advance notice, release evidence, migration window | Version log and regression report | Were changes timely and testable? |
| Incident | Defined severity, notice, cooperation, evidence | Incident exercise and contact test | Were incidents transparent? |
| Testing rights | Reasonable evaluation and security research | Completed buyer tests | Did terms block verification? |
| Subprocessors | Current list and material-change notice | Dependency inventory | Did the supply chain expand? |
| Exit | Export, deletion proof, transition, format, timing | Exit rehearsal | Can the buyer leave without unsafe disruption? |
Do not accept 'continuous improvement' as permission for silent behavioral change. Define material change by effects on validated capabilities, limitations, data, safety, security, availability, obligations, or cost architecture. Require version pinning or a test window where feasible. The NIST Manage Playbook explicitly discusses applying risk management to third-party AI and identifying weak documentation or change management as risk indicators.
Authorize a bounded pilot with production-grade controls
Define users, data, duration, purpose, geography, model version, integrations, prohibited actions, success thresholds, safety thresholds, human review, support, monitoring, incident route, and deletion. Use synthetic or minimized data until controls are proven. Block autonomous external effects unless the pilot specifically evaluates them under safe conditions. Inform participants appropriately and provide an alternative workflow.
The pilot decision package should state evidence gaps and what the pilot can resolve. It should not use a small, supervised trial to claim safety at full scale. Record benefit, error distribution, human workload, overrides, incidents, cost, and vendor responsiveness. Use the procurement workflow guide and vendor access management guide to make approvals and access reversible.
Reassess evidence at renewal and rehearse exit
At renewal, compare promised and actual versions, incidents, support, data practices, subprocessors, service levels, evaluations, vulnerabilities, regulatory status, and costs. Review production complaints, overrides, drift, and benefit realization. Require closure or explicit acceptance of aged gaps. A supplier that answered well during selection but did not provide change notices should score poorly on evidence reliability.
Test export of prompts, configurations, evaluation sets, logs, fine-tuning artifacts, and customer data; verify deletion; identify replacement dependencies; and estimate migration effort. Preserve records needed for legal, audit, or incident duties. Connect renewal to compliance-ready delivery so vendor continuation is an evidence-based change decision.
Write a diligence decision that operations can enforce
The final decision should name approved purpose, users, data classes, regions, model and tier, integrations, autonomy, conditions, unresolved gaps, monitoring, renewal date, and stop triggers. Map each condition to a contract clause, configuration, access control, test, or operating procedure. A narrative recommendation such as 'approved with caution' is not enforceable and will be forgotten when the original reviewers move on.
Require dual ownership: a business owner accountable for value and impact, and a technical service owner accountable for configuration, evidence, and response. Security, privacy, legal, procurement, and model-risk teams approve their domains but should not become the de facto service owner. Publish an escalation route that frontline users can invoke without knowing the vendor contract.
Feed production evidence back into the vendor scorecard. Track notice quality, regression frequency, support response, incident transparency, data-deletion performance, documentation accuracy, and migration friction. Weight observed behavior more heavily than refreshed sales answers at renewal. This makes diligence a lifecycle process and creates leverage for remediation before the organization becomes more dependent on the service.
Key takeaways
- Scope diligence to the exact service, configuration, model, supply chain, data, and intended use.
- Demand versioned evidence and verify critical model, security, safety, and data claims through buyer testing.
- Treat pilots as real exposure and bound users, data, actions, duration, and success and safety thresholds.
- Contract for material-change notice, incident cooperation, testing rights, subprocessor transparency, and exit.
- At renewal, judge the vendor's evidence reliability from actual changes, incidents, support, and outcomes.
Frequently asked questions
Is a SOC 2 report enough for an AI vendor?
No. It may support review of scoped controls, but it rarely answers model identity, evaluation validity, AI-specific threats, output safety, training data, behavioral change, or your configured use.
How should buyers assess a startup with limited assurance?
Narrow the use and data, inspect technical evidence directly, require named remediation, strengthen contract and monitoring, and preserve an easy exit. Some missing evidence should block high-impact use regardless of company size.
What if evaluation or security evidence is confidential?
Use nondisclosure terms, controlled review, independent assessor reports, or evidence summaries. Record what remains unknown and make the proceed decision at the appropriate authority; confidentiality is not verification.
Conclusion
AI vendor due diligence is disciplined uncertainty management. Map the exact service and dependencies, request claims that can be tested, validate the configured system, and contract for the changes and incidents that will occur after signature. Bound pilots, reassess renewals, and rehearse exit. A buyer should know not only what the vendor says today, but how it will detect, govern, and recover when the service changes tomorrow.