EU AI Act compliance checklist: 10 steps for high-risk AI systems in April 2026

Your AI system flags loan applications, ranks job candidates, or manages infrastructure access, which means it falls under the EU AI Act's high-risk category. Enforcement begins August 2026, and the compliance bar is technical, not procedural. This EU AI Act compliance checklist outlines ten concrete steps you need to complete, with a focus on continuous monitoring, automated testing, and traceable evidence that regulators will actually inspect.

TLDR:

• High-risk AI under the EU AI Act requires continuous risk management, not one-time audits.
• You must register systems in the EU database and maintain technical documentation before market entry.
• Penalties reach €15M or 3% of global revenue for high-risk system compliance failures.
• Incident reporting windows are strict: 72 hours for life-threatening risks, 15 days for serious incidents.
• Openlayer automates EU AI Act compliance through continuous testing, real-time guardrails, and traceable evidence across development and production.

Classify your AI system as high-risk under Annex III

Before any compliance work begins, you need to know where your system sits. The EU AI Act splits high-risk classification into two pathways. The first covers AI embedded in products already regulated under EU safety laws listed in Annex I, such as medical devices, machinery, or aviation components. The second, and more broadly applicable, is Annex III, which lists eight specific use case domains:

• Biometrics and remote identification
• Critical infrastructure management (energy, water, transport)
• Education and vocational training
• Employment, worker management, and access to self-employment
• Access to core private and public services
• Law enforcement
• Migration, asylum, and border control
• Administration of justice and democratic processes

If your system makes decisions, assists decisions, or profiles individuals within any of these domains, high-risk obligations almost certainly apply. A credit scoring model, a hiring tool that ranks candidates, or a system that flags welfare benefit eligibility all qualify.

One important nuance: the Act does carve out exceptions. Systems used purely for narrow procedural tasks or that do not influence substantive outcomes on individuals may fall outside scope. But the bar for that exemption is high, and regulators will review how a system is actually deployed, not how it's described internally.

Build a continuous risk management system

Article 9 of the EU AI Act requires a living system that runs continuously across the full lifecycle of your AI deployment, not a static risk assessment document. This continuous approach aligns with modern AI governance principles. The core obligations break down into four areas:

• Identify known and foreseeable risks to health, safety, and fundamental rights before deployment and as conditions change
• Assess risks under both normal operation and reasonably foreseeable misuse scenarios
• Implement elimination or mitigation measures, with residual risks documented and accepted by authorized personnel
• Run testing across diverse populations, with special attention to vulnerable groups such as minors, elderly users, and individuals with disabilities

A one-time audit before launch will not satisfy regulators. Your risk management process must respond to new data, changed use patterns, and model updates over time. If your system drifts behaviorally in production, your risk posture has changed and your documentation must reflect that. Automated monitoring that tracks model behavior, flags regressions, and feeds findings back into your risk register is the only scalable way to meet this standard across a portfolio of high-risk systems.

Implement data governance and quality controls

Article 10 sets the data standards your training, validation, and testing datasets must meet before a high-risk system can go to market. The requirements cover four areas:

• Datasets must be relevant to the intended purpose and representative of the environments where the system will operate
• Data must be free of errors and complete within reasonable bounds
• You must document data sources, collection methods, and any preprocessing steps
• You must actively check data for potential biases and apply corrective measures where needed

Regulators won't accept a general statement that bias was checked. You need documented evidence: which populations were represented, what tests were run, and what actions were taken when gaps were found. That means automated bias detection across demographic subgroups, with results logged and traceable.

Data quality also degrades in production. Input distributions shift, new edge cases appear, and what was representative at training time may no longer reflect real users six months later. This is where ongoing quality assurance for AI becomes critical. Article 10 compliance requires ongoing monitoring of the data feeding your live system.

Prepare technical documentation before market entry

Annex IV defines what your technical documentation package must contain before a high-risk AI system reaches the market. According to the EU AI Act, this documentation must be prepared before market entry, kept up to date, and remain clear, comprehensible, and complete at all times. (kothes.com) The required contents include:

• A general description of the system, its intended purpose, and the populations it affects
• Design specifications, development methodology, and the architecture of the underlying model
• Testing procedures and results, covering performance benchmarks and failure modes
• Risk management documentation showing identified risks and the controls applied
• A post-market monitoring plan outlining how you will track the system after deployment

Regulators expect evidence, not assertions. Teams that build traceability into their development workflow from day one will find this step far more manageable than those trying to reconstruct it after the fact.

Complete conformity assessment and obtain CE marking

Article 43 requires a conformity assessment before any high-risk AI system enters the EU market. The procedure depends on system type and deployment context. Most high-risk AI systems not embedded in regulated products under Annex I can use the internal control procedure defined in Annex VI. For systems covering biometric identification or safety components under Annex I product regulations, third-party assessment through a notified body under Annex VII is required. Key conformity assessment steps:

• Verify which procedure applies based on your system category and deployment context.
• Complete internal or third-party assessment against all applicable requirements.
• Sign the EU declaration of conformity, identifying the legal entity taking responsibility.
• Affix the CE marking before market placement. Certificates from notified bodies are valid for up to five years.
• Retain documentation for at least ten years post-deployment.

"Substantial modification" is a defined trigger. Retraining on significantly different data, changing intended purpose, or altering risk profile may restart the assessment. Build change control processes that flag these modifications early.

Register your system in the EU database

Article 49 requires providers to register high-risk AI systems in the EU database maintained by the European Commission before placing them on the market. Registration requires submitting:

• Provider name, location, and contact details
• System name, version, and intended purpose
• A description of the populations and use cases the system affects
• Reference to the conformity assessment completed under Article 43
• A copy of the EU declaration of conformity

Registration is not a one-time filing. If system details change after initial submission, the record must be updated. Letting registration information go stale creates a gap between what regulators see on file and what you are actually running in production.

Design for human oversight and transparency

Articles 13 and 14 govern how your system must be designed to support human control and what information deployers need to exercise it effectively.

Article 14 requires that high-risk systems be built so humans can meaningfully monitor outputs, intervene, and override decisions. Implementing LLM guardrails is one technical approach to support this requirement. Oversight mechanisms must be proportionate to risk level and context. A fraud detection model used by a trained analyst warrants different controls than an automated benefit eligibility system affecting vulnerable individuals with no intermediary review.

Transparency requirements

Article 13 sets documentation standards for deployers. Your instructions for use must cover:

• The system's intended purpose and performance limits
• Accuracy and robustness metrics across relevant subgroups
• Known risks, edge cases, and conditions under which outputs may be unreliable
• Steps deployers must take to maintain meaningful human oversight

Oversight mechanism requirements

Article 14 specifies that oversight measures should allow operators to:

• Understand system capabilities and limitations in their specific deployment context
• Detect and respond to anomalies, unexpected outputs, or declining performance
• Disregard, override, or pause system outputs when warranted
• Prevent automation bias, where users over-trust outputs despite signals of unreliability

If your system lacks logging, interpretability features, or alerting that surfaces anomalies to human reviewers in real time, you have a structural compliance gap, not a documentation gap.

Implement accuracy, robustness, and cybersecurity measures

Article 15 sets performance obligations that go beyond documentation. Your system must achieve and maintain appropriate levels of accuracy throughout the full deployment lifecycle. Three areas drive the technical requirements:

• Accuracy metrics must be defined, disclosed in instructions for use, and validated against subgroup performance, beyond aggregate scores using an AI model evaluation platform
• Robustness requires the system to handle errors, inconsistencies, and unexpected inputs without producing unsafe outputs
• Cybersecurity protections must guard against attacks targeting training data, model weights, and inference inputs

Data poisoning and adversarial attacks on live inference are both in scope. Testing procedures need to actively probe for these vulnerabilities before deployment and monitor for anomalies in production that could signal model manipulation. Automated testing across diverse inputs, including edge cases and adversarial examples, is the evidence regulators will look for. Threshold-based alerting tied to defined accuracy benchmarks provides both runtime control and an audit trail.

Implement post-market monitoring and incident reporting

Articles 72 and 73 extend your compliance obligations well past go-live. Post-market monitoring must be built into your quality management system from the start, not retrofitted after deployment.

Article 72 requires a proportionate monitoring plan covering how you collect and analyze performance data from real-world use, track new risks, and feed findings back into your risk management system. An AI compliance automation platform can implement these requirements. What "proportionate" means in practice depends on your risk tier and deployment context.

Article 73, though, sets incident reporting timelines with zero flexibility:

• Serious incidents affecting health, safety, or fundamental rights must be reported to national market surveillance authorities within 15 days of becoming aware.
• Incidents involving risk to life or suspected serious breaches require reporting within 72 hours.

Continuous automated monitoring is what makes these timelines achievable. Manual review cycles are too slow when a 72-hour reporting window starts the moment your team becomes aware of an incident, not when the investigation concludes. Systems that surface anomalies and performance regressions in real time give you the lead time to investigate, document, and notify before deadlines close.

Understand penalties for noncompliance

The EU AI Act's enforcement framework uses a three-tier penalty structure tied directly to violation severity.

For high-risk systems, most compliance failures land in the middle tier. Regulators weigh factors like infringement severity, organizational size, intent versus negligence, and corrective actions taken. Article 99 of the EU AI Act also allows authorities to treat cooperation with investigations as a mitigating factor. For large enterprises, the percentage-based calculation almost always exceeds the flat cap. Organizations assessing their options can review our analysis of AI compliance tools to support these requirements.

How Openlayer accelerates EU AI Act compliance

Compliance isn't proven by documentation alone. It's proven by continuous, traceable evidence tied directly to your AI systems. Openlayer runs 100+ prebuilt evaluations continuously across development and production, covering bias, hallucinations, toxicity, and adversarial robustness. Every result is logged and traceable, generating the Annex IV documentation trail without manual reconstruction. Real-time guardrails block prompt injections and PII leakage before they reach downstream systems, directly supporting Article 15 cybersecurity obligations and Article 10 data governance requirements. Continuous monitoring tracks model behavior across live inferences, surfacing regressions fast enough to meet Article 73's 72-hour incident reporting window.

Final thoughts on meeting high-risk AI system obligations

Compliance with the EU AI Act comes down to one thing: can you prove your system works safely across its full deployment lifecycle. Your EU AI Act compliance checklist needs to cover risk management, data quality, technical documentation, and post-market monitoring with traceable evidence at every step. The requirements aren't ambiguous, but meeting them manually creates bottlenecks that slow deployment and leave gaps in your audit trail. Automated evaluation and continuous monitoring give you the evidence regulators expect without rebuilding your documentation from scratch every time your model updates. Get in touch if you want to discuss how continuous testing supports compliance without slowing down development.

FAQ

What qualifies as a high-risk AI system under the EU AI Act?

High-risk systems fall into two categories: AI embedded in regulated products under Annex I (medical devices, machinery), or AI used in the eight domains listed in Annex III, including biometrics, employment decisions, credit scoring, law enforcement, and access to critical services. If your system influences decisions affecting individuals in these areas, high-risk obligations apply.

How quickly do I need to report incidents under Article 73?

You must report serious incidents to market surveillance authorities within 15 days of becoming aware, but incidents involving risk to life or suspected serious breaches require notification within 72 hours. This timeline starts when your team becomes aware of the issue, not when investigation concludes, making real-time monitoring critical.

Does my technical documentation need to be updated after initial market entry?

Yes. Annex IV documentation must be kept current throughout the system's lifecycle, beyond initial preparation before launch. Any substantial modification, such as retraining on different data, changing intended purpose, or altering risk profile, may trigger a new conformity assessment and require updated documentation.

What accuracy requirements does Article 15 impose on high-risk systems?

Article 15 requires you to define, disclose, and validate accuracy metrics across demographic subgroups, beyond aggregate scores. Your system must maintain these accuracy levels throughout deployment, handle errors without producing unsafe outputs, and include cybersecurity protections against data poisoning and adversarial attacks.

Can I use internal assessment for CE marking or do I need a notified body?

Most high-risk systems not embedded in Annex I products can use the internal control procedure under Annex VI. Systems covering biometric identification or safety components under Annex I product regulations require third-party assessment through a notified body under Annex VII, with certificates valid for up to five years.