AI Supplier Due-Diligence Checklist

Quick answer

AI supplier due diligence is the evidence-based process of checking a supplier's legal identity, the exact AI product, its model and subcontractor dependencies, data handling, security controls, testing, human oversight and contractual change controls. Request documents or demonstrations rather than relying on marketing claims. Match each item to the intended deployment, record gaps, and repeat checks when material risks or dependencies change.

Use this checklist as a starting point for proportionate AI supplier evaluation. Not every question applies to every purchase, and higher-impact uses require deeper evidence.

Supplier and product identity

• What legal entity will contract with us?
• What exact product/service are we buying?
• Who owns and operates it?
• Which critical third parties are involved?
• Is the proposed deployment materially different from the public product?

Intended use and limitations

• What is the product designed to do?
• What uses are unsupported or prohibited?
• What known limitations or failure modes are documented?
• What human oversight does the supplier expect?

Models and architecture

• Which model(s) or model providers are used?
• Can the supplier switch model/provider without notice?
• Are retrieval systems, agents, tools or external APIs involved?
• What material dependencies could affect service or risk?
• How are model and system changes tested?

Data and privacy

• What customer data is processed?
• Where is it stored and processed?
• Who can access it?
• How long is it retained?
• Is customer content used for training, fine-tuning or improvement?
• Which subprocessors are involved?
• How is deletion handled?
• Can the supplier support the buyer's privacy impact assessment where needed?

Security

• What security framework and secure-development controls are used?
• Has the product undergone relevant security testing?
• How are vulnerabilities managed?
• How are AI-specific threats considered?
• What logs and access controls are available?
• How are supplier-chain dependencies secured?
• What incident-response process applies?

The NCSC Guidelines for secure AI system development provide a useful benchmark for secure design, development, deployment and operation.

Testing and performance

• What metrics are used to measure the product?
• What datasets and scenarios were used in evaluation?
• Do published benchmarks match our use case?
• Can we run a buyer-side pilot or evaluation?
• What failure modes have been identified?
• How are regressions detected after model updates?

Governance and accountability

• Who owns AI risk within the supplier?
• How are material incidents escalated?
• How are model/provider changes approved?
• What policies are actually evidenced in operation?
• Which external certifications or independent assessments apply to this exact service?

Human oversight and users

• How are users told AI is involved?
• Can users challenge, correct or escalate outputs?
• What controls reduce automation bias?
• What training or usage guidance is provided?
• Are accessibility impacts considered?

Customer and deployment evidence

• Can customer relationships and use cases be verified?
• Are case studies current and relevant to the same service?
• Is customer evidence independently sourced or purely marketing-selected?
• Are incident and support claims supported by evidence?

Contract and change control

• Are data-use restrictions contractual?
• Are model/provider changes notified?
• Are material subprocessor changes controlled?
• What audit/evidence rights exist?
• What incident-notification commitments apply?
• What happens if performance degrades?
• What termination and exit rights exist?

Post-award monitoring

• What performance data will the supplier provide?
• How are model changes communicated?
• How are incidents and vulnerabilities reported?
• What evidence expires or needs refreshing?
• What events trigger re-evaluation?

Evidence rating

For each answer, classify the support as: 1. Claim only — supplier assertion without supporting evidence. 2. Documented — policy, technical documentation or contract evidence exists. 3. Demonstrated — evidence shows the control operating in practice. 4. Independently verified — a suitable independent party has checked the relevant evidence.

A strong procurement record distinguishes those levels rather than treating every “yes” answer as equivalent.

Frequently asked questions

What evidence should an AI supplier provide before procurement?

Ask for the contracting entity, product scope, architecture and model dependencies, data-flow and subprocessor information, security testing, operational controls, oversight arrangements and incident processes. Check that each document applies to the exact service you intend to use. The AI vendor due diligence guide explains how to structure this review.

Does ISO/IEC 42001 certification prove an AI product is safe?

No. ISO/IEC 42001 concerns an AI management system; a certificate's scope and validity must be checked, and it is not a substitute for product-level security, privacy, performance and suitability evidence. See ISO/IEC 42001 evidence in AI procurement.

What should a buyer do when supplier evidence is missing?

Record the claim as unverified and its significance to the intended use. Request suitable documentation, a demonstration or independent review, then decide whether the remaining risk needs additional controls or prevents purchase. An unclaimed directory listing is not independent verification.

When should AI supplier due diligence be refreshed?

Review evidence after material changes to models, hosting, data uses, subprocessors, intended use, security incidents or other relevant risks. Set a proportionate ongoing review cadence in the contract and monitoring plan. See monitoring AI suppliers after award.

Return to the AI Procurement Knowledge Base.