Move the review from assurances to evidence
An AI supplier questionnaire can produce polished answers without giving a buyer enough information to assess the real system. Statements such as 'we use responsible AI' or 'we are AI Act compliant' are assertions, not evidence.
A stronger review requests 12 current, usable artefacts. A supplier can protect legitimate confidential information while still showing how the system is intended to work, what has been tested, which controls operate and who is accountable when something changes.
The updated EU AI model contractual clauses provide a useful voluntary starting point: a full version for high-risk systems, a lighter version for other AI systems, and commentary on customisation. They do not remove the need for buyer due diligence or tailored legal review.
1. AI system and intended-purpose statement
Request a concise description of the AI-enabled product or feature, its intended purpose, expected users, operating context, inputs, outputs and known limitations. The document should distinguish current functionality from roadmap claims.
This becomes the anchor for the rest of the review. Risk classification, testing and oversight cannot be evaluated sensibly when the supplier and buyer are describing different uses of the system.
2. Supplier role, supply chain and risk-classification rationale
Ask the supplier to state its anticipated role under the EU AI Act and explain the system's risk position, including why it considers the system prohibited, high-risk, subject to specific transparency duties or outside those categories.
Treat the response as a reasoned position, not a warranty that resolves the buyer's own obligations. The buyer's deployment context can alter the analysis, particularly when a general product is configured for a sensitive decision.
3. Model and training-data information
Request enough information about the model, training and evaluation data, retrieval sources, provenance, quality controls and known limitations to assess the intended use. Where full datasets or proprietary details cannot be disclosed, ask for meaningful summaries, documentation and the reasons for any restriction.
The goal is not to demand trade secrets. It is to understand the evidence behind performance claims, foreseeable limitations and whether the supplier can trace material dependencies.
4. Data-processing and subprocessor map
Request the main personal and non-personal data categories, purposes, retention periods, locations, subprocessors, model providers and transfer arrangements. State whether customer inputs or outputs may be used to train or improve any model.
This map should align with the contract and security review, and make clear where an upstream provider can change the risk or compliance position.
5. Evaluation and testing summary
Ask for results relevant to the intended purpose: accuracy or task performance, robustness, bias or differential performance where appropriate, safety testing, security testing and known failure modes. The summary should explain test conditions and thresholds, not only present a headline score.
Buyers should also ask how often testing is repeated and what triggers reevaluation. A report produced for an earlier model version may say little about the service currently offered.
6. Human oversight and user-control design
Request an explanation of the decisions people are expected to make, the information available to them, and how they can review, override, correct or stop the system. Ask what training or instructions users need for that oversight to be meaningful.
A generic claim that a human remains 'in the loop' is not enough. Effective oversight depends on authority, time, competence, interface design and access to useful information about the output.
7. Monitoring, logging and transparency evidence
Ask for the notices, labels or interface examples used when people interact with AI or encounter AI-generated or manipulated content. Where machine-readable marking is relevant, request a description of the method and test evidence.
Since Article 50 transparency duties began applying on 2 August 2026, this evidence deserves particular attention. The supplier should also explain which transparency responsibilities remain with the buyer as deployer.
8. Incident, complaint and escalation procedure
Request the process for detecting, triaging and communicating AI incidents, harmful outputs, material performance issues and user complaints. It should name escalation routes and explain when customers will be notified.
Contract terms and operational evidence should align. A supplier promising rapid notice should be able to show an internal process capable of meeting that promise.
9. Change notification and release record
Ask how the supplier governs changes to models, prompts, data sources, guardrails, integrations and material product behaviour. The record should show approval, testing, versioning and customer communication for significant changes.
This is especially important for services built on external foundation models, where an upstream change can alter performance or risk without a conventional product release.
10. Governance ownership and competence record
Request a simple accountability map covering product ownership, risk approval, legal or compliance input, security, incident escalation and executive oversight. Relevant AI literacy or role-based training records can support the response.
The purpose is to establish that governance has named owners and that those owners have the authority and competence to act. A committee name without decision rights or operating records adds little assurance.
11. Audit rights and control-to-evidence index
Ask for an index connecting each stated control to current evidence, owners and review dates, plus proportionate rights to obtain evidence, ask follow-up questions and commission or review assurance when risk warrants it. This might reference policies, test reports, approvals, monitoring dashboards and training records without disclosing every underlying document at the first stage.
The index and access rights reveal whether governance claims are part of a maintained operating system or assembled reactively for the questionnaire.
12. Exit, continuity and evidence-return plan
Request the plan for termination, transition assistance, data and output export, retention and deletion, access to logs and evidence, and continuity if an underlying model or subprocessor is withdrawn. Identify formats, timescales, costs and responsibilities before dependency becomes difficult to unwind.
Exit evidence matters because the buyer may still need to explain historical decisions, incidents or affected people after the supplier relationship ends.
How to use the 12 items proportionately
Use the checklist as a tiered gate. Begin with intended purpose, role, data and dependencies. Increase the evidence depth where the system affects people, handles sensitive data, supports consequential decisions, operates at scale or creates significant dependency on the supplier.
Record gaps as actions with an owner and deadline rather than burying them in email. Where evidence cannot be provided, decide whether a contract control, restricted deployment, additional testing, human review or rejection is the appropriate treatment.
AI Act Ready helps suppliers assemble these artefacts once and keep them current, while giving procurement teams a consistent evidence model for comparing AI services. That makes reviews faster without reducing them to a box-ticking exercise.
Frequently asked questions
Is an AI supplier questionnaire enough evidence?
No. A questionnaire records assertions. Buyers should request current artefacts that substantiate purpose, classification, data use, testing, oversight, monitoring, incidents, changes, auditability and exit arrangements.
Should every AI supplier provide all 12 items?
Use the same evidence headings, but scale the depth to the system's impact, data, autonomy, users and dependency. Higher-consequence uses need more detailed and independently verifiable evidence.
Do the EU model contractual clauses replace legal review?
No. They are a useful voluntary template for public buyers and must be selected, tailored and reviewed for the procurement, parties, system and applicable law.
Make supplier approval evidence-led
Use the AI Act readiness check to expose your first procurement gaps, see how the AI Act Ready software keeps supplier evidence current, or talk to us about an AI supplier evidence review.
This article provides practical procurement and governance information, not legal advice. Tailor contract terms and evidence requirements to the specific system and applicable law.