AI due diligence is the structured review of an AI system before adoption, purchase or deployment. It examines the model, training data, suppliers, controls, intended use, failure modes and governance so the organisation understands risk, limitations and compliance obligations before granting access or relying on outputs.
What AI due diligence evaluates
AI due diligence is not a single test. It is a structured review of what the system is meant to do, how it was built, what it depends on, and what governance surrounds it before an organisation trusts it in production.
The review usually starts with intended use and decision impact. A system that generates drafts, supports triage, or influences customer decisions creates different expectations for accuracy, explainability, review depth, and human oversight.
What organisations need to examine before adoption
The practical question is whether the vendor and the system can support the organisation’s risk appetite, regulatory duties, and operational needs. That means reviewing model behaviour, training and fine-tuning data, data retention terms, security controls, subprocessor arrangements, and whether the deployment matches the stated use case.
Because procurement decisions often depend on vendor claims, AI due diligence should be evidence-led. Organisations should ask for documentation that explains model provenance, testing coverage, control ownership, and any limits on data use or secondary training. For vendor-facing checklists, see AI Vendor Security Questionnaire Template and Third-Party AI Risk Guide.
AI due diligence also overlaps with third-party risk because many failures are introduced by the supplier relationship rather than the model alone. The buyer needs to understand who can retrain the model, who can access prompts and outputs, how changes are approved, and what happens when the relationship ends.
Failure modes and governance gaps
AI systems can fail in ways that look technically correct but still create business harm: hallucinated outputs, hidden bias, unsafe recommendations, leakage of sensitive data, or behaviour that drifts after deployment. A weak due diligence process misses these issues because it checks marketing claims instead of operational evidence.
Governance gaps are equally important. If no one owns model approval, risk acceptance, logging, review cadence, or exception handling, the organisation can end up using an AI system with unclear accountability and no reliable path to suspension or rollback.
Where AI is sourced from a third party, due diligence should also assess concentration risk and exit risk. A system may be useful today but difficult to replace later because of dependency on a single provider, proprietary prompts, custom integrations, or embedded workflows. The same due diligence logic appears in broader supplier governance resources such as Third-Party Risk Management Guide and Vendor Tiering and Inherent Risk Questionnaire Template.
How due diligence becomes a decision, not just a checklist
Good AI due diligence ends with a decision: approve, approve with conditions, defer, or reject. That decision should reflect the use case, the evidence provided, and the residual risk after controls, not the vendor’s reputation or the novelty of the tool.
The strongest programmes separate model assessment from contract negotiation and deployment readiness. That means aligning security review, legal terms, privacy review, and operational ownership so the organisation knows what it is accepting and who is accountable after go-live. A useful pattern for that kind of structured buyer review is AI Procurement Checklist.
Where the system is especially sensitive, due diligence should be repeated when the model, data source, hosting setup, or intended use changes. AI risk is not static, and a one-time review is rarely enough for a system that learns, updates, or depends on changing supplier controls.
Risk and Threat Considerations
AI due diligence fails when organisations trust a system before they understand its actual failure modes. The main risks are unsafe outputs, data exposure, hidden supplier dependencies, and approving a model for a use case it was never designed to support.
Failure mechanism: Teams rely on vendor assurances instead of evidence about training data, testing, change control, retention, and access paths, so they miss defects that only appear under real workloads or sensitive prompts.
Impact: The organisation can expose confidential data, make flawed decisions, create compliance gaps, or inherit a supplier dependency that is hard to unwind after deployment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST AI RMF, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI Risk Management Framework | Defines AI risk governance and evaluation of AI system risks before use |
| Recommendation — Apply AI RMF Govern and Map practices to document intended use, risks, controls and accountability before approval. | ||
| ISO/IEC 42001:2023 | AI Management System standard | Establishes organisational AI governance, risk management and accountability for AI systems |
| Recommendation — Use ISO/IEC 42001 to formalise AI approval, oversight and continual review across the AI lifecycle. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | AI due diligence evaluates supplier assurance, contract terms and third-party control expectations |
| Recommendation — Use CIS-15 to inventory AI suppliers, assess their controls and monitor contractual obligations. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | AI systems often depend on APIs and due diligence should assess unsafe upstream API consumption |
| Recommendation — Review AI integrations for unsafe API consumption, weak trust boundaries and insufficient validation. | ||
| NIST SP 800-53 Rev 5 | SR-3 — Supply Chain Controls and Processes | AI due diligence depends on supplier assurance, provenance and supply-chain control evaluation |
| Recommendation — Apply SR-3 to assess supplier provenance, control assurance and acquisition risk before adoption. | ||
Practitioner Guidance
Why practitioners should care: AI due diligence is the control point that turns “interesting model” into “acceptable system”. If it is weak, the organisation may buy capability without understanding the operational, legal, or security obligations that come with it.
What to watch for: Treat repeated vague answers, missing testing evidence, unclear data-use terms, and no named owner for model governance as strong warning signs. Those gaps usually mean the organisation has not actually assessed the system, only the sales proposal.
Practitioner takeaway: The best due diligence is specific to the use case, evidence-based, and repeatable when the model or supplier changes.