Why buyers ask for evidence
AI procurement creates questions that ordinary software assurance may not answer: which model is operating; what data shaped it; where can it fail; who reviews its outputs; what happens when the supplier changes it; and how responsibilities are divided across the supply chain.
The UK Government’s AI procurement guidance emphasises multidisciplinary decisions, data assessment, governance, information assurance, transparency, evaluation and lifecycle management. The EU’s updated model contractual clauses provide public buyers with high-risk and lighter versions that can be adapted to the procurement context. Those resources are aimed at public procurement, but the underlying evidence questions are useful to private buyers too.
The clauses are a starting point, not a complete agreement: the Commission resource notes that matters such as intellectual property, acceptance, payment, delivery, applicable law and liability still need to be addressed in the main contract. In July 2026, the Commission also began an expert group on AI contracting to develop horizontal model terms and buyer guidance, reinforcing the need to connect evidence requests to enforceable contractual rights.
The 12 items to request before supplier approval
- System identity and intended purpose. Product, model, version, deployment pattern, users, territories and uses that are excluded.
- EU AI Act role assessment. The supplier's view of provider, deployer, importer or distributor responsibilities, with rationale.
- Risk classification. Prohibited-practice, high-risk and transparency-risk screening, plus the approving owner.
- Data and model provenance. Material data sources, model dependencies, licences, retention and customer-data use.
- Evaluation evidence. Test scenarios, populations, thresholds, results, limitations and unresolved residual risks.
- Human oversight design. Where review occurs, who performs it, what they can override and how competence is evidenced.
- Transparency evidence. User notices, generated-content marking, labels and proof that they work in the supplied service.
- Security and privacy assurance. Access controls, threat testing, incident processes and relevant privacy assessments.
- Monitoring and incident records. Operational metrics, complaints, material failures, corrective actions and notification routes.
- Change-control commitments. Notice of model, data, purpose, subprocessor or control changes before they alter the approved risk position.
- Audit and information rights. Access to evidence, cooperation, independent assurance and remediation tracking.
- Exit and continuity evidence. Data return or deletion, portability, transition support and continuity arrangements.
Apply the list proportionately. A low-impact internal assistant and a system influencing employment or access to essential services should not receive identical depth of review, but both should have a documented decision.
The evidence-pack index
| System and scope | System card; purpose; model and version; deployment; users; geographies; affected people; material suppliers. |
|---|---|
| Role and risk | EU AI Act scope and role assessment; prohibited-practice check; high-risk screening; transparency assessment; rationale and approver. |
| Governance | Accountable owner; approval history; AI policy; exception route; AI-literacy records; review cadence. |
| Data and model | Data sources and governance; intended-use limits; known failure modes; model/provider information; retention and access decisions. |
| Evaluation | Test plan, representative scenarios, results, thresholds, residual risks, human-oversight test and remediation records. |
| Operations | Logging, monitoring, incident response, security, privacy, business continuity, model-change and supplier-change controls. |
| Transparency | User notices, AI interaction disclosures, synthetic-content or output labelling decisions and evidence that disclosures were tested. |
| Contract | Responsibility matrix, audit and information rights, change notice, incident timing, subcontractors, data return and exit support. |
Annotate the evidence—do not just attach it
For each artefact, tell the reviewer:
- What question it answers. A certificate may answer management-system questions but not product-specific performance.
- What it covers. Name the entity, system, version, location and intended use within scope.
- Who owns it. Give the accountable person or function and the approval route.
- When it was reviewed. Include the version, issue date, next review and material-change triggers.
- What remains open. State limitations, exceptions and compensating controls honestly.
What good evidence looks like
Claim: “Human oversight is in place.”
Insufficient evidence: a policy saying staff must review AI output.
Buyer-ready evidence: the named reviewer role; interface or workflow showing where approval occurs; criteria for rejection or escalation; training record; sample review log; test showing that the reviewer can identify representative errors; and an owner for recurring review.
The difference is operational proof. The second package shows how the control works, who operates it and whether it was tested.
A 48-hour questionnaire response workflow
- Receive and triage: separate standard assurance questions from system-specific, legal, security and commercial questions.
- Map: link each question to the evidence index and flag anything outside the current approved scope.
- Verify: confirm versions and review dates; do not recycle stale evidence after material product changes.
- Approve: route legal interpretations, security exceptions and contractual commitments to the named authority.
- Package: provide a concise cover note, evidence index, requested artefacts and a controlled list of caveats.
- Learn: add recurring questions to the standard pack and assign any gap to an owner and due date.
Common mistakes
- Presenting an AI policy as proof that every system follows it.
- Claiming that ISO/IEC 42001 or ISO/IEC 27001 alone proves product or legal compliance.
- Sending evaluation results without the test population, intended use, model version or acceptance threshold.
- Hiding unresolved gaps instead of naming the risk and compensating control.
- Failing to convert supplier promises into contract terms and change notifications.
- Allowing the pack to become a one-off sales folder with no owner or maintenance trigger.
Frequently asked questions
What is an AI compliance evidence pack?
It is a controlled index of current artefacts that helps a buyer verify the system, classification, governance, controls, testing, supply chain and commitments.
Which documents should a vendor provide first?
Start with the system card, role and risk assessment, governance summary, data and model information, evaluation evidence, security and privacy assurance, incident and change processes, and responsibility matrix.
Is an AI policy sufficient?
No. Buyers also need system-level decisions and operating records demonstrating that relevant controls work.
How often should the pack be updated?
On a defined cadence and whenever the model, purpose, data, supplier chain, risk, control design or incident history changes materially.
Build a pack buyers can navigate
Use the free checklist to structure your evidence. If a deal or questionnaire is already live, the Procurement Readiness Scan identifies missing, stale and weak evidence before it delays the sale.
Related guidance
Official sources
- UK Government — Guidelines for AI procurement
- EU Public Buyers Community — updated AI model contractual clauses
- European Commission — innovative technologies and AI contracting
- Regulation (EU) 2024/1689
Last reviewed 24 September 2026. This article provides general information, not legal advice.