EU AI Act High-Risk System Compliance Checklist

The EU AI Act’s compliance deadlines for high-risk AI systems changed in 2026. The AI Omnibus — part of the European Commission’s Digital Simplification Package — was adopted in June 2026 and entered into force on 27 July 2026, pushing back the applicability dates for high-risk obligations that would otherwise have landed on 2 August 2026. This is a practical checklist against the dates as they now stand: what’s due when, and what a provider or deployer of a high-risk system actually has to do before each deadline.

This page covers the high-risk system compliance track — Annex I and Annex III of the Act. It’s a different track from the general-purpose AI model obligations covered in EU AI Act GPAI Code of Practice and Mapping AI Safety Programs to the EU AI Act GPAI Code. If you’re a foundation-model provider working out GPAI obligations, start there instead; this page is for anyone building, deploying, or procuring an AI system that falls into a high-risk use case such as biometrics, employment, education, or essential services.

The current deadlines

Under the AI Omnibus, the applicability dates for high-risk obligations are now:

• 2 December 2027 — Chapter III obligations apply to AI systems that are high-risk under Article 6(2) and Annex III (the “direct listing” route: biometrics, critical infrastructure, education, employment, essential private and public services, law enforcement, migration/asylum/border control, and the administration of justice and democratic processes).
• 2 August 2028 — Chapter III obligations apply to AI systems that are high-risk under Article 6(1) and Annex I (systems that are safety components of products already covered by EU product-safety legislation, such as machinery, medical devices, toys, or lifts).
• 2 August 2030 — separate compliance deadline for high-risk AI systems used by public authorities and EU institutions.

These are adopted, binding dates, not a proposal. Before the Omnibus, the Act’s own default applicability date of 2 August 2026 (Article 113) would have applied to Annex III systems; the Omnibus deferred that specifically, giving providers and deployers roughly an extra sixteen months. Two related dates worth keeping in view: prohibited-practice bans and AI-literacy obligations have applied since 2 February 2025, and GPAI model obligations have applied since 2 August 2025 (with a compliance deadline of 2 August 2027 for GPAI models already on the market before that date) — both already in force regardless of the high-risk timeline.

Step 1: Confirm your system is actually high-risk

Article 6 sets two separate routes into high-risk classification, and they’re the two dates above:

• Annex III (Article 6(2)): your system is high-risk if it falls into one of the use cases Annex III lists by name — biometric identification and categorisation, management of critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including credit scoring and insurance risk assessment), law enforcement, migration/asylum/border control, and the administration of justice and democratic processes.
• Annex I (Article 6(1)): your system is high-risk if it’s a safety component of a product that’s itself covered by EU harmonisation legislation requiring third-party conformity assessment — e.g. machinery, medical devices, toys, or lifts.

Article 6(3) carves a narrow exemption out of the Annex III list: a system can avoid high-risk classification if it does not pose a significant risk of harm to health, safety, or fundamental rights and it only performs a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing human judgement, or performs a preparatory task for an Annex III assessment. That exemption does not apply if the system profiles natural persons — profiling stays high-risk regardless. A provider relying on the exemption has to document the assessment and, per Article 49, register before putting the system into service.

If your system doesn’t clear either Annex I or Annex III, the deadlines below don’t apply to it — though the obligations that are already in force (prohibited practices, AI-literacy, GPAI where relevant) still might.

Step 2: If you’re the provider — work through Chapter III, Sections 2 and 3

Chapter III sets out what a provider of a high-risk system has to build before the applicability date hits. In article order:

• Risk management system (Article 9): a documented, iterative process covering the system’s full lifecycle — identifying and evaluating known and foreseeable risks, and testing and mitigating them.
• Data and data governance (Article 10): training, validation, and testing datasets have to be subject to governance practices and be relevant, sufficiently representative, and, to the best extent possible, free of errors.
• Technical documentation (Article 11): documentation demonstrating compliance, drawn up before the system is placed on the market and kept up to date.
• Record-keeping (Article 12): the system has to automatically log events over its lifecycle to the extent needed to identify risks and enable post-market monitoring.
• Transparency and instructions for use (Article 13): the system has to be designed to be sufficiently transparent for deployers to interpret its output, and accompanied by instructions that let deployers actually comply with their own obligations.
• Human oversight (Article 14): the system has to be designed so a human can effectively oversee it, including the ability to intervene or stop it.
• Accuracy, robustness, and cybersecurity (Article 15): the system has to achieve an appropriate level of each throughout its lifecycle.
• Quality management system (Article 17): a documented QMS covering the provider’s own compliance process, not just the product.
• Conformity assessment (Article 43), EU declaration of conformity (Article 47), and CE marking (Article 48): most Annex III systems can self-assess; some categories require a notified body. The declaration of conformity and CE marking follow once the assessment is complete.
• EU database registration (Article 49): Annex III systems have to be registered in the EU database before being placed on the market or put into service.

Step 3: If you’re the deployer — work through Article 26 (and Article 27)

Most organisations encountering this checklist are deployers — procuring or operating a high-risk system someone else built — rather than providers. Article 26 sets the deployer-side obligations:

• Use the system according to the provider’s instructions for use.
• Assign human oversight to people with the competence, training, and authority to exercise it, and give them the support they need.
• Where the deployer controls the input data, ensure it’s relevant and sufficiently representative for the system’s intended purpose.
• Monitor the system’s operation per the instructions for use, and inform the provider (and, where relevant, the market surveillance authority) if it presents a risk or a serious incident.
• Keep the system’s automatically generated logs for at least six months, unless a longer period is otherwise required.
• If the deployer is a public authority or EU institution, verify the system is registered in the EU database before putting it into use.
• Before deploying a system in the workplace, inform workers’ representatives and affected workers.
• Where the system makes or materially informs a decision affecting a natural person, inform that person the system is in use.

A subset of deployers — public bodies, and private entities providing public services, banking, or insurance — also have to complete a Fundamental Rights Impact Assessment under Article 27 before putting a high-risk system into use, and again after any material change. The FRIA has to describe the deployer’s intended process for using the system, the timeframe and frequency of use, the categories of people likely to be affected, the specific risks of harm to them, the human-oversight measures in place, and the steps for mitigating risk and handling complaints. A deployer can reuse an earlier FRIA for materially similar deployments, and can cross-reference an existing GDPR Article 35 data protection impact assessment rather than duplicating that analysis. Two Annex III categories are exempted from the FRIA requirement (point 2, and points 5(b) and (c)).

Step 4: Work the calendar backward from your deadline

Conformity assessment, technical documentation, and EU database registration are not same-week tasks, and a notified-body assessment (where one is required) adds a queue you don’t control. For an Annex III system, treat 2 December 2027 as the date everything above has to already be true, not the date to start — build in registration and conformity assessment lead time, and account for CASRAI’s own guidance on NIKOLAI-based metadata tracking if you’re using it to document provenance and compliance status internally.

How this differs from the GPAI Code of Practice track

It’s easy to conflate the two EU AI Act compliance tracks because they’re both live at once. They’re separate:

• The GPAI track (covered in EU AI Act GPAI Code of Practice and Mapping AI Safety Programs to the EU AI Act GPAI Code) applies to providers of general-purpose AI models — the underlying foundation models themselves — under Articles 53–55. It’s already in force, and the voluntary Code of Practice is the main route to demonstrating compliance with it.
• The high-risk system track covered on this page applies to specific AI systems (which may well be built on top of a general-purpose model) used in one of the Annex I or Annex III use cases, under Chapter III. It has its own separate deadlines, obligations, and conformity-assessment process, and it binds providers and deployers, not just model providers.

An organisation can face both tracks at once — for example, a hospital deploying a diagnostic tool built on a general-purpose model may need to confirm the model provider’s GPAI compliance and independently satisfy Article 26 as the deployer of what is very likely an Annex III high-risk system under the essential-services or health categories.

FAQ

Did the EU AI Act’s high-risk deadlines actually change, or is this still a proposal?

They changed, and it’s adopted law, not a proposal. The AI Omnibus was adopted in June 2026 and entered into force on 27 July 2026, moving the Annex III applicability date from the Act’s original default of 2 August 2026 to 2 December 2027, and setting 2 August 2028 for Annex I.

What’s the difference between an Annex I and an Annex III high-risk system?

Annex III lists specific high-risk use cases directly (biometrics, employment, education, essential services, law enforcement, and others) — a system is high-risk simply by falling into one of those categories. Annex I instead covers AI systems that are safety components of products already regulated under other EU product-safety law, such as machinery or medical devices; those follow the sectoral conformity-assessment process for the underlying product.

Do these deadlines apply to general-purpose AI models?

No. GPAI model obligations under Articles 53–55 have applied since 2 August 2025 already, independent of the high-risk system deadlines covered here. See EU AI Act GPAI Code of Practice for that track.

We’re not sure whether our system counts as high-risk. What do we do?

Work through Article 6 directly: check whether the system’s use case matches an Annex III listing or whether it’s a safety component of an Annex I product. If it matches Annex III, check the Article 6(3) exemption conditions — narrow procedural task, improving completed human work, pattern detection without replacing judgement, or preparatory assessment — and confirm the system doesn’t profile natural persons, since profiling overrides the exemption. Document that assessment either way; if you claim the exemption, you still have to register before deployment.

What happens if a system isn’t compliant by its deadline?

The Act’s penalty provisions have applied since 2 August 2025 alongside the governance and notified-body framework. Missing a high-risk applicability date doesn’t pause enforcement — it means the system is out of compliance with Chapter III obligations that are already legally binding on providers and deployers as of that date.

Does a system already on the market get more time?

The Act’s transitional provisions treat systems already placed on the market or put into service differently from new ones in some circumstances, generally tying continued obligations to whether the system undergoes a significant design change after the applicability date. Confirm your specific situation against Article 111 rather than assuming a blanket grace period — this checklist covers the standard applicability dates, not every transitional edge case.