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 starting points, not evidence.
A stronger review asks for a small, consistent set of artefacts. The supplier may redact commercially sensitive detail, but it should still be able to show how the system is intended to work, what risks have been assessed, which controls operate and who is accountable when something changes.
The ten files below create a practical baseline. The depth should remain proportionate to the use case: an internal transcription utility does not need the same scrutiny as AI influencing employment, credit, healthcare or access to essential services.
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. Regulatory role 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. Data and model dependency map
Request a map of the main data categories, model providers, subprocessors, retrieval sources and other material dependencies involved in delivering the service. It should identify where customer data may be retained, used for improvement or transferred.
The aim is not to collect every architecture detail. It is to understand the chain of responsibility and where a supplier change, model update or data-flow change could affect the agreed risk position.
4. 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.
5. 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.
6. Transparency and user-notice 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.
7. 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.
8. Change-management 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.
9. 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.
10. Control-to-evidence index
Finally, ask for an index connecting the supplier's stated controls to current evidence and owners. This might reference policies, test reports, approvals, monitoring dashboards, training records and review dates without disclosing every underlying document at the first procurement stage.
The index is often the most revealing artefact because it shows whether governance claims are part of a maintained operating system or assembled reactively for the questionnaire.
How to use the ten files 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.