The EU AI Act Compliance Checklist

Engineering, security, and compliance teams at companies that build or deploy AI systems used inside the EU. Especially relevant if your product touches employment, education, credit scoring, biometric ID, critical infrastructure, law enforcement, migration, or essential public services — these are the categories classified as high-risk under Annex III.

Non-compliance with high-risk obligations is fined up to €15 million or 3% of global annual turnover, whichever is higher. Prohibited practices (Article 5) carry fines up to €35 million or 7%. Providing false or misleading information to authorities carries up to €7.5 million or 1%. For SMEs and startups, fines are capped at the lower of the two figures.

Risk management system

Article 9 requires providers to establish, implement, document, and maintain a continuous risk management process across the lifecycle of every high-risk AI system. This is not a one-time exercise. The Act explicitly calls it a "continuous iterative process" that must be reviewed and updated regularly.

The process must (a) identify known and reasonably foreseeable risks to health, safety, or fundamental rights from intended use; (b) estimate risks from reasonably foreseeable misuse; (c) evaluate risks emerging from post-market monitoring; and (d) adopt appropriate and targeted mitigation measures. Article 9(5) requires that residual risk after mitigation be acceptable, with providers eliminating or reducing risk "as far as technically feasible" and using design or instructional safeguards for what remains. Article 9(9) specifically requires consideration of impacts on persons under 18 and vulnerable groups.

Engineering checklist

• Maintain a living risk register that documents identified risks, sources, severity, and mitigations. The register must be reviewed at least when material system changes occur.
• Run pre-deployment testing against defined metrics and probabilistic thresholds (Art. 9(8)).
• Wire post-market monitoring data back into the risk register — Article 9 requires the loop to close.
• Document residual risks and the reasoning for accepting them. Auditors will ask.
• Flag risks to minors and vulnerable groups explicitly in the register.

Data and data governance

Article 10 applies to high-risk AI systems trained on data. Training, validation, and testing datasets must be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete" — and they must have appropriate statistical properties for the intended users and contexts of use.

Providers must document the data lifecycle: design choices, collection processes and data origin, preparation operations (annotation, labeling, cleaning, enrichment, aggregation), assumptions about what the data is intended to measure, suitability assessments, and — critically — bias detection and mitigation. If geographic, contextual, behavioral, or functional setting matters for the system's intended deployment, the datasets must reflect that. Article 10 also permits exceptional processing of sensitive personal data only for bias correction, with strict access controls and deletion requirements.

Engineering checklist

• Maintain a data lineage record for every dataset: source, collection method, labeling process, transformations, version.
• Run bias evaluation on training data — across protected attributes where they apply. Document the methodology and findings.
• Test the system on data representative of every deployment region you target.
• If you use sensitive personal data for bias correction, gate it behind strict access controls and deletion timers.
• Plan for "data shortcomings" — Article 10 explicitly requires identification of gaps and how they are addressed.

Technical documentation

Article 11 requires providers to draw up technical documentation before placing a high-risk AI system on the market and to keep it up to date for the system's lifetime. The documentation must demonstrate compliance with all Section 2 obligations of Chapter III (Articles 8–15) and give national authorities and notified bodies what they need to assess conformity. The minimum contents are set out in Annex IV — design specifications, risk assessment, testing results, monitoring plan, and performance data.

SMEs and microenterprises may submit a simplified template — the Commission is required to provide one — and notified bodies must accept it during conformity assessments. Where a high-risk AI system relates to a product already covered by existing EU harmonisation laws (Annex I), the documentation must be consolidated into a single package.

Engineering checklist

• Create the Annex IV technical file before any EU launch. It is not optional and not retroactive.
• Treat the technical file as a living document — update it on material changes, not just at release.
• Include risk management output, dataset documentation, test results, and the post-market monitoring plan.
• Map each Section 2 obligation (Art. 8–15) to a specific section of your file. Auditors trace this.
• If you are an SME, watch for the Commission's simplified template — using it is your right.

Record-keeping (audit logs)

Article 12 is the audit-log article. Every high-risk AI system must have the technical capability to automatically record events ("logs") over the lifetime of the system. The purpose, set out in Article 12(2), is to enable the recording of events relevant to identifying situations that present risk, supporting post-market monitoring, and allowing deployers to monitor system operation.

For biometric identification systems (Annex III, point 1(a)), Article 12(3) goes further and prescribes a minimum log content: start and end times of each use, the reference database the system queried, matched inputs, and the identity of the natural persons verifying the results under Article 14(5). Article 26 then requires deployers to retain those logs for at least six months unless other legal requirements apply.

Engineering checklist

• Log every meaningful agent or model action with timestamp, actor, inputs, outputs, and outcome.
• Make logs tamper-evident — append-only storage, hash chaining, or signed manifests.
• For biometric ID systems, record start/end times, reference database, matched inputs, and verifying personnel (Art. 12(3)).
• Plan for a minimum 6-month retention as a deployer (Art. 26). Longer if sectoral law applies.
• Make logs queryable and exportable — auditors and post-market surveillance will request slices.

Transparency and information to deployers

Article 13 obliges providers to design high-risk AI systems so their operation is "sufficiently transparent to enable deployers to interpret a system's output and use it appropriately." That transparency takes the form of instructions for use — delivered "in an appropriate digital format or otherwise" — containing concise, complete, correct, and clear information that is relevant and comprehensible to the deployer.

The instructions must cover: provider and authorized representative contact details; intended purpose; accuracy, robustness, and cybersecurity test results; known risks to health, safety, and fundamental rights; technical capabilities for explaining outputs; performance data for relevant demographic groups; input data specifications; output interpretation guidance; predetermined performance changes; human oversight measures; computational requirements; expected system lifetime; maintenance and update procedures; and the data-logging mechanisms required by Article 12.

Engineering checklist

• Write — and version — formal instructions for use. Not a marketing page; a document for a compliance reader.
• Include accuracy metrics, robustness test results, and known limitations explicitly.
• Document how a deployer should interpret outputs, what tools you provide, and where the system is known to fail.
• Describe the human oversight measures the deployer must implement (this is the bridge to Article 14).
• Cover the operational envelope: compute requirements, expected lifetime, update cadence, maintenance procedures.

Human oversight

Article 14 requires high-risk AI systems to be designed so they can be effectively overseen by natural persons during use. Oversight measures must be commensurate with the risks, level of autonomy, and context of use, and they must be either built into the system by the provider before market placement or identified by the provider for the deployer to implement.

Article 14(4) is the substantive list: a person overseeing the system must be able to (a) understand its capacities and limitations and monitor for anomalies; (b) recognize automation bias, especially in decision-support contexts; (c) correctly interpret outputs; (d) decide not to use the system or override its output; and (e) intervene with mechanisms such as a stop function. For biometric identification under Annex III point 1(a), Article 14(5) requires two natural persons with competence, training, and authority to verify any action based on an identification — with limited exceptions in law enforcement, migration, border control, and asylum where national law deems the requirement disproportionate.

Engineering checklist

• Build a "stop" or override mechanism into every high-risk workflow. Document where and how it engages.
• Provide overseers with interpretation tools — model cards, confidence scores, contextual explanations.
• Train deployer personnel on automation bias. The Act explicitly calls this out.
• Log overrides and stops. They are evidence the oversight mechanism works.
• For biometric ID: enforce two-person verification (Art. 14(5)) unless your sectoral exception applies.

Accuracy, robustness, and cybersecurity

Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity — and to perform consistently across the lifecycle. Providers must declare accuracy levels and relevant metrics in the instructions for use, and the Commission will work with stakeholders to develop measurement benchmarks.

Robustness covers resilience to errors and faults, including redundancy and fail-safe plans. For systems that continue learning after deployment, providers must mitigate "biased outputs influencing input for future operations." Cybersecurity addresses AI-specific attack surfaces explicitly: data poisoning, model poisoning, adversarial examples and model evasion, confidentiality attacks, and model flaws.

Engineering checklist

• Declare accuracy metrics in the instructions for use. Be specific — not "high accuracy".
• Build redundancy and fail-safes for the failure modes you can foresee. Document them.
• For continually learning systems, prevent feedback loops that amplify bias.
• Threat-model AI-specific attacks: data poisoning, prompt injection, model extraction, adversarial inputs.
• Run cybersecurity testing (and ideally external red-teaming) before placing on the market.

Deployer obligations

Article 26 sets out the duties of deployers — the organizations that use high-risk AI systems in a professional capacity. Deployers must follow the provider's instructions for use, assign qualified personnel with appropriate training and authority to oversee AI decisions, ensure input data is relevant and representative for the intended purpose, and monitor system performance per the provided guidelines.

Deployers must inform the provider, distributor, and relevant market surveillance authority if they discover risks or serious incidents. They must retain system-generated logs for at least six months unless other legal requirements apply. They must inform workers before deployment in workplace settings, and notify affected individuals when high-risk systems make or influence decisions about them. Public-authority deployers must register systems in the EU database before use. Biometric identification for law enforcement requires prior judicial authorization, with narrow exceptions for initial suspect identification.

Engineering checklist (for deployers)

• Operate the system only within the provider's documented intended purpose. Document deviations.
• Assign a trained, authorized overseer. Record who, when, and what they are responsible for.
• Retain logs for at least 6 months. Sectoral law may require longer.
• Inform workers and affected individuals where the Act requires it.
• Complete a data protection impact assessment using the provider's information (where GDPR applies).

How identity and audit-trail infrastructure maps to the Act

The Act repeatedly asks the same engineering question across articles: can you prove who did what, with what data, under what authorization, and what oversight was applied? Article 12 makes the logging requirement explicit. Article 14 requires oversight and intervention. Article 26 requires retention. Article 11 requires the documentation to demonstrate it.

For organizations shipping AI agents, the practical implication is that every agent needs a verifiable identity, every action needs an immutable log entry, and every export needs to be independently checkable. That is the core of what Vorim AI provides: Ed25519 agent identities, scoped permissions with allow/deny outcomes, SHA-256 hash-linked audit trails, and signed export bundles. The audit bundle is the artefact a compliance reviewer or notified body will actually open.

None of this replaces the substantive obligations — your risk management process under Article 9, your data governance under Article 10, your accuracy and robustness work under Article 15. But it does close the evidence gap that most teams discover only when an auditor asks for a six-month slice of agent activity by 17:00 on Friday.

Frequently asked questions

When does the EU AI Act apply to high-risk systems?

Under the May 2026 Digital Omnibus, Annex III high-risk AI obligations apply from 2 December 2027 (deferred from 2 August 2026), and Annex I product-embedded high-risk systems from 2 August 2028. The Act entered into force on 1 August 2024. Prohibitions under Article 5 applied earlier (from 2 February 2025), and general-purpose AI model rules applied from 2 August 2025.

What counts as a high-risk AI system?

Two pathways. First, AI systems used as a safety component of a product, or themselves a product, covered by the EU harmonisation legislation in Annex I and required to undergo third-party conformity assessment. Second, AI systems used in the eight categories listed in Annex III: biometrics; critical infrastructure; education; employment and worker management; access to essential private and public services; law enforcement; migration, asylum, and border control; and administration of justice and democratic processes. The Commission can amend the Annex III list.

We are not in the EU. Does the Act apply?

The Act has extraterritorial reach. It applies to providers placing AI systems on the EU market or putting them into service in the EU regardless of where the provider is established, and to providers and deployers of AI systems whose output is used in the EU. If a US-based provider's AI agent is used by a German bank, the Act applies.

What are the fines?

Up to €35 million or 7% of global annual turnover for prohibited practices (whichever is higher). Up to €15 million or 3% for other operator violations including non-compliance with high-risk system obligations. Up to €7.5 million or 1% for supplying false or misleading information to authorities. For SMEs, fines are capped at the lower of the two figures.

Is this article legal advice?

No. This is an engineering and operations reference summarizing publicly available regulatory text. Binding interpretation belongs with EU counsel.

Score your EU AI Act readiness

Ten questions, 60 seconds, a personalized report covering the articles above. Free. No signup required to see your score.

• Regulation (EU) 2024/1689 — the Artificial Intelligence Act, Official Journal of the European Union
• EU AI Act Explorer — artificialintelligenceact.eu
• European Commission AI Act page — digital-strategy.ec.europa.eu
• Vorim AI compliance overview — vorim.ai/compliance-info

Last reviewed: 17 May 2026. Article citations verified against the consolidated text as published on artificialintelligenceact.eu. This page is not legal advice.