Short answer
A provider needs a connected, current body of evidence—not simply a policy, a test score or a CE mark. For a high-risk system, Regulation (EU) 2024/1689 (the AI Act) links the intended purpose and risk-management file to data records, technical documentation, human-oversight controls, performance testing, automatically generated logs, a documented quality-management system, conformity assessment and post-market monitoring.
The evidence should show what requirement was tested, which data and system version were tested, which metric and threshold were chosen, why they suit the intended purpose and affected groups, who approved the result, what limitations remain, and how failures trigger investigation and correction. Deployers have their own part: they must appoint competent and authorised overseers, control relevant input data, follow instructions, monitor operation and retain logs under their control.
Regulation (EU) 2026/1744, effective since 27 July 2026, postponed these Chapter III duties. They now apply from 2 December 2027 for Article 6(2)/Annex III systems and 2 August 2028 for Article 6(1)/Annex I systems; amended Article 111 contains transition rules. This article concerns the EU: an “EEA relevance” label does not itself establish EEA application.
Start with an auditable chain, not a folder of disconnected documents
Article 11 defines the function of the technical file. It must exist before market placement or putting into service, remain current, and allow an authority or notified body to assess the system rather than reconstruct it from informal explanations.
“The technical documentation shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in this Section and to provide national competent authorities and notified bodies with the necessary information in a clear and comprehensive form to assess the compliance of the AI system with those requirements.”
—
That calls for traceability between five things: the legal requirement, the design or organisational control, the verification method, the result, and the responsible decision-maker. Annex IV makes the chain concrete. It asks for system architecture, design choices and assumptions, data provenance and preparation, oversight measures, validation procedures, metrics, test logs, signed and dated test reports, cybersecurity measures, known limitations, change history and the post-market monitoring plan.
A useful evidence register therefore identifies the system and model version, intended purpose, affected persons, owner, source records, acceptance criteria, result, residual risk, approval and next review. A vendor assurance may be one input. Amended Article 25 requires written arrangements with third-party suppliers and, on a provider change, can require technical documentation, known limitations and failure modes, and testing access. Outsourcing does not outsource the proof burden.
What proves data quality under Article 10?
For a system trained on data, a generic statement that the data are “high quality” is too thin. Article 10 requires governance over design choices; collection and origin; original collection purpose for personal data; annotation, labelling, cleaning and updating; assumptions; quantity and suitability; bias examination and mitigation; and identified gaps.
“Training, validation and testing data sets shall be relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose.”
—
The words “in view of the intended purpose” matter. Evidence should include data sheets or equivalent records showing provenance, scope, selection, exclusions, labels and cleaning; versioned train-validation-test splits; duplicate and leakage checks; error and missingness analysis; representation across relevant groups and operating settings; bias tests and mitigation results; and a reasoned record of remaining gaps. Article 10(4) also requires the relevant geographical, contextual, behavioural or functional setting to be reflected.
If special-category personal data are strictly necessary to detect and correct bias, new Article 4a requires proof that other data—including synthetic or anonymised data—cannot work, plus reuse limits, privacy and security measures, strict documented access, no third-party access, deletion and necessity records. It is not a general permission to assemble sensitive data. Article 4a also permits providers and deployers of other systems and models to process such data exceptionally under the same safeguards, but creates no duty to do so. For high-risk systems that do not train a model, Article 10(2)–(4) applies only to testing data.
Human oversight must work in the interface and the organisation
Oversight is not proved by naming a person in a policy. The provider must design effective human-machine interface measures, identify what intervention is needed, and give deployers clear instructions. The deployer must then assign natural persons with the necessary competence, training, authority and support.
“Human oversight shall aim to prevent or minimise the risks to health, safety or fundamental rights that may emerge when a high-risk AI system is used in accordance with its intended purpose or under conditions of reasonably foreseeable misuse.”
—
Evidence should cover role descriptions and escalation routes; training and competence records; access rights; the information shown to the overseer; tests of whether outputs can be interpreted; warnings about automation bias; and exercises showing that a person can disregard, override or reverse an output and interrupt the system safely. The record should also show whether staffing, workload and response time make those powers real in the intended operating context.
For remote biometric identification under Annex III point 1(a), Article 14(5) generally requires separate verification and confirmation by at least two qualified people before the deployer acts, subject to the specific law-enforcement, migration, border-control and asylum exception stated there. That enhanced rule should not be generalised to every high-risk system.
How should accuracy and robustness be evidenced?
Article 15 does not prescribe one universal accuracy score. The appropriate level depends on intended purpose, foreseeable misuse, affected people, risks and the state of the art. Providers should define metrics and probabilistic thresholds before testing, explain why they are suitable, and declare relevant accuracy metrics in the instructions for use.
The test pack should include performance by relevant group and operating condition where appropriate, error distributions rather than one average, boundary and stress tests, fault and dependency failures, recovery and fail-safe tests, and regression results after changes. A continuously learning system also needs controls and tests for feedback loops. Cybersecurity evidence should address relevant AI-specific attacks, including data or model poisoning, adversarial examples, model evasion and confidentiality attacks.
This is lifecycle proof. Drift, degrading inputs, incidents and interaction with other systems can invalidate an earlier result. Article 72 therefore requires providers to actively and systematically collect, document and analyse post-market performance data so they can evaluate continuous compliance.
Logs and governance records make the proof reproducible
Article 12 requires high-risk systems to record events automatically over their lifetime. Logging must support risk identification, post-market monitoring and deployer monitoring. The log design should document event definitions, timestamps, identities or roles where required, system and model version, relevant inputs and outputs, interventions, errors, security events, retention controls and access safeguards.
Providers and deployers must keep logs under their control for an appropriate period of at least six months, unless other applicable EU or national law provides otherwise. That minimum does not displace data-protection duties: collection, access and retention still need a lawful, proportionate design.
The Article 17 quality-management system should connect these records to procedures for design, testing, validation, data, risk, monitoring, incidents, document control, resources and accountability. Its implementation may be proportionate to provider size, but the required protection remains. Providers generally keep the technical and quality-system documentation, notified-body materials where applicable, and EU declaration of conformity available for ten years after market placement or putting into service.
The conformity route depends on the system. Many Annex III systems use internal control under Annex VI; some biometric systems may require notified-body involvement under Article 43, and high-risk AI in products listed in Annex I follows the relevant sectoral conformity procedure. A certificate or internal declaration records an assessment—it does not excuse missing underlying evidence or the duty to reassess after a substantial modification.
A practical evidence checklist
- Fix the intended purpose, system boundary, operator roles, affected groups and applicable high-risk route.
- Maintain a requirement-to-control matrix covering Articles 9–15 and the relevant provider and deployer duties.
- Version data sheets, model and system artefacts, test protocols, thresholds, results, limitations and approvals.
- Test the oversight interface and the organisation: competence, authority, workload, escalation and safe intervention.
- Declare meaningful performance metrics and keep subgroup, stress, fault, security and regression evidence where relevant.
- Define log events, access and retention; link them to monitoring, incidents, investigations and corrective actions.
- Keep the technical file and quality system current when data, suppliers, intended purpose or system performance changes.
- Make post-market signals feed back into risk assessment, testing and change control.
EIOPA's 2025 Opinion on AI governance offers a useful sector example for insurance. It recommends records of training and testing data and modelling methods to enable reproducibility and traceability, clear staff responsibilities, and ongoing performance metrics. It is a non-binding supervisory opinion for insurance authorities and undertakings, not a substitute for the AI Act or a general rule for every sector.
The amended Article 72 no longer calls for a binding harmonised post-market-plan template. Instead, the Commission must publish guidance, including a template, by 2 September 2027. Until then, providers still need a tailored plan forming part of Annex IV technical documentation.
Conclusion
The strongest proof is a maintained evidence chain from intended purpose and risk to data, design, testing, human control, logs and post-market action. Each material claim should be reproducible for the exact system version and operating context, owned by an accountable person and updated when evidence changes. Providers build and maintain most of that chain; deployers complete it through competent oversight, controlled inputs, operating monitoring and retained logs. No single policy, benchmark, supplier promise or conformity mark can replace the connected record.
Sources
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.