How should supplier due diligence be carried out for AI systems?

What questions should be asked before procurement?

Before procurement, the buyer should ask for the system's intended purpose and use limits, the provider and deployer roles, the classification analysis, the testing and performance evidence, the data governance and bias examination, the human oversight design, the transparency and marking position, the logging and monitoring capability, the incident and update processes, and the documentation that will be supplied. Each question should be tied to a decision the buyer must make: whether the system fits the intended use, whether it is high-risk, what oversight and monitoring it needs, and what evidence the buyer must keep. Questions should be asked in writing, with a named supplier contact, and the answers should be recorded with the date and version, so that a later dispute about what was said can be resolved from the record. A procurement process that asks only about price, features, and delivery date has not carried out AI due diligence.

How should supplier evidence be tested?

Supplier evidence should be tested, not taken at face value. The buyer should check that the documentation matches the system version to be supplied, that test results reflect the buyer's deployment context, that limitations are stated, and that conformity, registration, and declaration records exist where the Act requires them. The buyer should sample the evidence, ask follow-up questions where it is incomplete, and record the gaps as open items with owners and dates. Where a supplier cannot provide evidence for a material question, the buyer should assess whether the system can be deployed without that evidence, whether additional testing or controls are needed, or whether procurement should be paused. A supplier assurance that evidence will be provided later, without a date and a contractual commitment, should be treated as an open gap, not as evidence.

For the broader regulatory framework, see AI governance planning checklist.

What contract terms matter for AI Act work?

Contract terms should cover the information to be supplied and updated, including downstream information for models, instructions for use for systems, and change notification, the timetable for updates and incident reporting, the right to audit or to receive evidence, the allocation of roles and responsibilities, the handling of data protection and confidentiality, and the consequences of a supplier failure to provide information or to take corrective action. Terms should be specific to the system and version, with named contacts and response times, rather than generic statements about cooperation. The contract should also address what happens if the supplier changes the system, withdraws it, or ceases to support it, including data, log, and documentation handover. A contract that labels roles without addressing information flow and change control does not support the buyer's AI Act work, even if it is commercially complete.

How should suppliers be monitored after procurement?

Monitoring should include regular checks that the supplier's information remains current, that updates and incidents are notified as agreed, that performance and oversight remain as assessed, and that any change to the system, its data, or its purpose is communicated. The buyer should set a review cadence, assign an owner, and record each review, with findings and follow-up actions. Monitoring should also include feedback from operational staff, complaints, and log patterns, fed back to the supplier through the agreed channel. A supplier relationship that ends at procurement, with no monitoring, will miss changes that affect the buyer's assessment, and the buyer will discover the change only when an incident or an authority question reveals it. Monitoring records should be linked to the inventory and the change register for the system.

What are the limits of supplier assurances?

Supplier assurances have limits. A supplier cannot assess the buyer's deployment context, affected people, or oversight design, and cannot carry out the buyer's deployer duties, including a FRIA where one is required. A certificate or a conformity record for the supplier's system does not prove that the system is suitable for the buyer's specific use, and a general-purpose model pack does not settle a downstream system assessment. The buyer must carry out its own assessment, using supplier evidence as an input, and must record its own reasoning and decisions. Where a supplier's assurance conflicts with the buyer's own testing or operational experience, the conflict should be recorded, raised with the supplier, and resolved with evidence, rather than resolved by preferring the assurance because it is more convenient.

Continue with AI governance operating model.

What does this guide not decide?

This guide does not decide whether a particular supplier has met its duties, whether a system is suitable for a specific deployment, or whether a contract term is sufficient. It does not assess a supplier, a product, or a procurement decision. Those questions depend on the supplier evidence, the system, the deployment context, the contract, and the consolidated legal text. A buyer should carry out due diligence in writing, test the evidence, record gaps as open items, and confirm the position with a competent authority or legal adviser where the supplier position is material to a high-risk deployment.

Frequently asked questions

Continue through this AI Act cluster

• AI governance planning checklist
• AI governance operating model
• Deployer responsibilities
• Downstream information flow for general-purpose AI models
• Provider responsibilities
• AI literacy in practice