How to Prove Your AI Is EU AI Act Compliant

Saying your AI system is compliant is easy. Proving it — on short notice, to an auditor, a market-surveillance authority, or an enterprise procurement team — is a different exercise entirely. Under Regulation (EU) 2024/1689, compliance is not a declaration you make once; it is a body of documentation and records you maintain continuously and can produce on demand. The burden sits with you, and the standard is retrievability.

What counts as proof depends on two things: your role in the AI supply chain and the risk tier of the system. A company deploying a third-party AI tool for low-stakes document summarisation faces far lighter evidencing requirements than a provider placing a credit-scoring model on the EU market. Getting the tier and role right is therefore the precondition for knowing what your evidence stack must contain.

What "proof" actually means under the Act

The EU AI Act does not create a certification process for most AI systems. It places positive obligations on providers and deployers to produce specific records and, for high-risk systems, to undergo a conformity assessment before the system reaches the market or enters service. An authority or auditor who asks for evidence of compliance expects to see those records — not a summary slide deck or a policy statement.

For high-risk systems, Article 43 sets out the conformity assessment procedure: either internal control (Annex VI) or, for Annex III point 1 biometric systems, a notified-body assessment (Annex VII). Passing that assessment and issuing the Article 47 Declaration of Conformity is the legal gate for placing a high-risk AI system on the EU market. But the conformity assessment is the output of all the underlying work — the technical documentation, the risk management system, the data governance records, the test results. If those underlying records are missing or thin, the assessment cannot be completed.

Market surveillance authorities operate under Article 79 procedures. When a system is identified as presenting a risk, the authority can require access to documentation, request records, and order corrective measures. The Act gives them broad investigatory powers. In practice, the first thing they will ask for is the technical file.

Proof depends on your risk tier

For minimal-risk systems — the majority of general productivity tools, search functions, spam filters — the Act imposes no mandatory evidencing requirements. Voluntary codes of practice exist, but no documentation is legally required.

For limited-risk systems, proof is narrow but concrete. Article 50 requires disclosure: if your system interacts with users as an AI, generates synthetic content, or applies emotion recognition, you must be able to show that users were informed. The evidence is a record of what disclosure was made, where, and when — log entries, UI screenshots, or product specifications confirming the marking or notice was in place. Article 50 obligations apply from 2 August 2026.

For high-risk systems — those falling within Article 6 and Annex III, or embedded as safety components in regulated products under Annex I — the evidencing requirements are substantive. Providers of stand-alone Annex III systems must be compliant by 2 December 2027 (deferred from the original 2 August 2026 date under the Digital Omnibus agreed in May 2026); providers of high-risk AI embedded in Annex I regulated products must comply by 2 August 2028. That breathing room does not shrink the evidence stack — it gives you time to build it properly.

The high-risk evidence stack

Each obligation maps to a specific artifact. Working through them in order gives you a checklist of what an auditor will expect to find.

Classification record. Before anything else, you need a documented record showing how you determined the system is — or is not — high-risk. That means working through Article 6 and Annex III: does the system fall within one of the eight Annex III use-case areas? If so, did you assess the Article 6(3) filter — i.e., does the system perform only a narrow procedural task, operate as a complement to prior human activity, or otherwise fail to pose a significant risk of harm to health, safety or fundamental rights? A system that profiles natural persons cannot claim that exemption. The classification record must capture the reasoning, the evidence considered, and — if you invoke the Article 6(3) exemption — the documented assessment supporting it. Providers relying on the exemption must also register the system in the EU database under Article 49.

Risk management system (Article 9). An ongoing, iterative process — not a one-time spreadsheet. The Article 9 record must show the risk identification methodology, the residual risks after mitigation, and the cycle of review. Auditors look for version history and evidence that the system was re-evaluated after changes to the model or its operating context.

Technical documentation (Article 11, Annex IV). The Annex IV technical file is the spine of the evidence pack. It must cover nine content areas: a general description of the system and its intended purpose; a detailed description of the system's elements, development process, and training approach; information on the monitoring, functioning and control of the system; data requirements and data governance measures; relevant standards applied; the conformity assessment procedure used; the Declaration of Conformity; post-market monitoring plan; and any other information supporting traceability. This file must be kept up to date and retained for ten years from the point the system is placed on the market (Article 18).

Data governance records (Article 10). Training, validation, and test datasets must be accompanied by records showing their origin, collection methodology, relevance to the intended purpose, and the measures taken to detect and address biases. Undocumented data lineage is one of the most common evidence gaps in practice. If you cannot reconstruct where your training data came from and how it was processed, that gap will surface in any meaningful audit.

Event logs (Article 12). High-risk AI systems must generate logs automatically to the extent technically feasible. Those logs must record events relevant to identifying risks and incidents. Providers must retain logs they control for at least six months; deployers retain theirs for at least six months under Article 26.

Instructions for use (Article 13). Transparency toward deployers — the downstream professional users — requires clear written instructions covering the intended purpose, the performance metrics and limitations, human oversight requirements, and the conditions under which the system should not be used. This document is part of the Annex IV file and is also the basis for the deployer's ability to comply with their own Article 26 obligations.

Human oversight design (Article 14). Evidence that the system was designed to allow natural persons to understand, monitor, and intervene in its operation. This is not a policy statement; it is design documentation showing what oversight measures are built in — pause functions, override mechanisms, interpretability outputs, and the competence requirements for oversight personnel.

Accuracy, robustness, and cybersecurity evidence (Article 15). Test results demonstrating the system meets the relevant accuracy metrics for its intended purpose, plus documentation of measures taken to address adversarial inputs, errors, and cybersecurity threats. Where harmonised standards exist and are applied, a standards-conformity record supports this element.

Quality management system records (Article 17). A documented QMS covering policies, processes, post-market monitoring procedures, and roles. The QMS is the organisational framework within which all the above is maintained. Auditors check not just that the QMS exists on paper, but that it is operational — signed policies, dated reviews, identified owners.

Conformity assessment and Declaration of Conformity (Articles 43 and 47). For most Annex III systems (points 2–8), this is an internal self-assessment under Annex VI. For Annex III point 1 biometric systems where harmonised standards are not applied, a notified body must be involved (Annex VII). The output is the Article 47 Declaration of Conformity, drawn up using the Annex V template and retained for the same ten-year period.

CE marking (Article 48). Once the conformity assessment is complete and the Declaration of Conformity drawn up, the CE mark is affixed to the system (or its documentation, where physical affixing is not possible). Evidence: the marking and the documentation referencing it.

EU database registration (Article 49). Providers must register high-risk systems — and systems for which the Article 6(3) exemption is claimed — in the EU database established under Article 71. The registration record is itself evidence of compliance with this step.

Post-market monitoring (Article 72). A post-market monitoring plan, integrated into the QMS, covering how you collect, analyse, and act on data about the system's real-world performance after deployment. Evidence: the plan itself, and records showing it is being executed — monitoring reports, anomaly flags, version updates triggered by monitoring findings.

Serious incident records (Article 73). If a serious incident occurs, providers must report it to the market-surveillance authority of the member state where it happened. Timelines are strict: 15 days from awareness for most serious incidents; 2 days for widespread infringement or serious disruption of critical infrastructure; 10 days where a person has died. Retaining incident logs and the notifications sent to authorities is part of the evidence trail.

What a deployer must be able to show

Most companies that use third-party AI tools are deployers under Article 26, not providers. The deployer's evidence burden is lighter, but it is not zero.

Under Article 26, a deployer must follow the provider's instructions for use, implement human oversight measures, monitor the system for risks in its specific operating context, and keep logs for at least six months. If the deployer is a public body, or if it deploys a creditworthiness or life/health-insurance AI system (Annex III points 5(b) or 5(c)), Article 27 requires a Fundamental Rights Impact Assessment. The FRIA can build on an existing GDPR Data Protection Impact Assessment under Article 27(4), but it covers distinct ground — the AI-specific risks to fundamental rights in the deployer's specific use context.

Evidence a deployer should be able to produce: a record of how they verified the provider's system was registered and accompanied by a Declaration of Conformity before deployment; the instructions-for-use document received from the provider; records showing human oversight was implemented as required; and the Article 27 FRIA where it applies. If the deployer substantially modifies the system or places it on the market under their own name, Article 25 converts them into a provider, and the full provider stack then applies.

Who asks for proof, and in what form

The audiences for your evidence differ in what they emphasise, but they all want the same underlying documentation.

A notified body, engaged for Annex III point 1 biometric systems under the Annex VII procedure, will conduct a systematic review of the technical file, test results, and QMS. They assess conformity before the system is placed on the market.

A market-surveillance authority will typically be triggered by a complaint, a serious incident report, or a sweep. Under Article 79 procedures for systems presenting a risk, they can require documentation on short notice, test the system, and order corrective or restrictive measures. The authority in each member state is designated under Article 70.

Enterprise customers with their own compliance programs routinely conduct vendor due diligence on AI tools they are considering deploying. In regulated sectors — financial services, healthcare, HR — procurement teams increasingly request evidence of conformity assessment completion, a copy of the Declaration of Conformity, and confirmation of EU database registration. This is not a legal obligation on you to disclose, but commercially it is becoming a gate.

External auditors — whether under ISO/IEC 42001, a sector-specific framework, or a bespoke engagement — will work from the same documentation set. The difference from a regulatory inspection is that auditors typically have more time and a broader scope; the evidence quality bar is similar.

Common evidence gaps that fail an audit

Several gaps appear repeatedly in practice, regardless of company size or sector.

The most common is undocumented training-data lineage. Providers can usually describe their model architecture but struggle to produce records of where training data came from, how it was filtered, and what bias assessments were applied. Article 10 makes this a hard requirement. Building the data governance record retroactively — after training is complete — is substantially harder than doing it in the pipeline.

Classification done in someone's head is the second. Many organisations have an informal sense that their AI is or is not high-risk, but no written record of the Article 6 / Annex III analysis and the Article 6(3) exemption reasoning. When a market-surveillance authority asks for the classification record, "we discussed it in a meeting" is not an answer.

Logs not retained or not generated is a related failure. Systems that do not produce automated logs at all, or where logs are overwritten on a rolling basis without any retention policy, leave a structural gap in the Article 12 record.

No version control on the technical file means that when the system changes — retraining, threshold adjustments, new data sources — the Annex IV documentation is not updated. An outdated technical file can itself constitute a breach, and it creates an inconsistency that an auditor will flag immediately.

How Confir helps

Assembling the evidence stack manually is time-consuming and error-prone, particularly for teams that are running compliance alongside their core work. Confir — a rule-based, deterministic EU AI Act compliance tool, not an AI-powered system — automates the core documentation steps.

It generates the classification record from plain-English Article 5 and 6 checklists, including the Article 6(3) exemption assessment, and produces a retrievable classification decision with the rule logic visible. It builds the Annex IV technical documentation pack and the Article 47 / Annex V Declaration of Conformity, structured to the nine-area template. The Article 9 risk register is maintained as a live document, versioned and linked to the overall audit trail. An immutable audit log captures every decision and update, so the evidence is retrievable on demand rather than assembled under pressure.

Confir starts at €600 per year, runs in a browser, and requires no consultants or implementation project. The same intake answers that produce your classification record also populate the technical documentation sections, which removes the most common duplication of effort in compliance programmes.

Frequently Asked Questions

What is the first piece of evidence I need to produce to show EU AI Act compliance?

The classification record comes first — a documented Article 6 / Annex III analysis establishing whether your system is high-risk, limited-risk, or minimal-risk, and your role (provider or deployer). Without that, you cannot know which obligations apply, and everything else in the evidence stack depends on it. If you invoke the Article 6(3) exemption, the reasoning and supporting evidence for that must be documented and the system registered in the EU database under Article 49.

Can I just issue a Declaration of Conformity without completing the full technical file?

No. The Article 47 Declaration of Conformity is an output of a completed conformity assessment under Article 43, which in turn requires the full Annex IV technical documentation to be in place. Issuing a Declaration without the underlying documentation is a breach of the Act and exposes you to fines of up to €15 million or 3% of worldwide turnover under Article 99.

How long do I need to keep the evidence records?

Technical documentation and the Declaration of Conformity must be retained for ten years from the date the system was placed on the market (Article 18). Deployer logs under Article 26 must be retained for at least six months. Post-market monitoring records and serious-incident documentation should be maintained for the life of the system and for any period in which regulatory proceedings could arise.

I am a deployer, not a provider. Do I still need documentation?

Yes, though the requirements are lighter. You need records of the provider's conformity documentation, evidence that human oversight was implemented, and logs retained for at least six months under Article 26. If you are a public body or deploy a creditworthiness or life/health-insurance AI system, you also need a completed Fundamental Rights Impact Assessment under Article 27.

Does passing an ISO/IEC 42001 certification satisfy the EU AI Act conformity assessment?

No. ISO/IEC 42001 is a voluntary AI management system standard. It supports the Article 17 quality management system and contributes evidence to the Article 9 risk management file, but it is not a substitute for the Article 43 conformity assessment or the Article 47 Declaration of Conformity. Those are legal requirements under Regulation (EU) 2024/1689; ISO certification is a complementary governance tool.

What happens if a market-surveillance authority asks for documentation I cannot produce?

Failing to provide documentation to an authority is itself a breach. Supplying incorrect or incomplete information carries fines of up to €7.5 million or 1% of worldwide turnover under Article 99. Underlying non-compliance with the high-risk obligations — such as missing technical documentation or a missing conformity assessment — falls in the €15 million or 3% tier. For companies within the SME and start-up definition, Article 99(6) caps the fine at the lower of the percentage or the fixed amount.

When do I need to have all this in place?

For Article 5 prohibited-practice obligations and Article 4 AI literacy, the requirements have applied since 2 February 2025. For limited-risk Article 50 transparency, the obligation applies from 2 August 2026. For stand-alone high-risk Annex III systems, the full compliance obligation applies from 2 December 2027 (deferred from 2 August 2026 under the Digital Omnibus agreed in May 2026). For high-risk AI embedded in Annex I regulated products, the deadline is 2 August 2028. Assembling the Annex IV technical file and completing the Article 43 conformity assessment alone can take several months, so the 2027 deadline requires starting documentation work well in advance.

Related guides

• EU AI Act Article 6: High-Risk Classification Rules
• Annex III: The High-Risk Use Case List
• Annex IV Technical Documentation Requirements
• Article 9: Building a Risk Management System
• Article 43: Conformity Assessment Procedure
• Article 47: EU Declaration of Conformity
• Article 49: EU Database Registration
• Deployer Obligations Under the EU AI Act