High-Risk AI System Classification: The Complete EU AI Act Guide
High-risk AI system classification under the EU AI Act determines everything that follows: which obligations apply, what documentation you must maintain, whether you need a conformity assessment, and when your compliance deadline falls. Getting the classification right is the single most consequential step in any AI Act compliance project. This guide maps the complete classification framework — the two-track system in Article 6, all eight Annex III domains, the Article 6(3) escape hatch that can take a system out of high-risk, the Commission’s May 2026 classification guidelines, and what the Digital Omnibus changes (and doesn’t change) about who falls in scope.
High-risk AI system classification: the two-track structure
Article 6 of the AI Act creates two distinct routes by which an AI system becomes high-risk. They operate independently — a system can fall under one, both, or neither.
| Track | Legal basis | What makes a system high-risk | Compliance deadline |
|---|---|---|---|
| Track 1: Product-embedded | Art. 6(1), Annex I | AI is a safety component of, or is itself, a product regulated under EU sectoral safety law listed in Annex I (medical devices, lifts, toys, radio equipment, etc.) | 2 Aug 2028 (deferred by Omnibus — pending) |
| Track 2: Use-case based | Art. 6(2), Annex III | AI is used in one of eight specific high-risk domains listed in Annex III (biometrics, employment, law enforcement, etc.) — subject to the Art. 6(3) escape hatch | 2 Dec 2027 (deferred by Omnibus — pending) |
Track 1: AI embedded in regulated products (Annex I)
A system is high-risk under Track 1 if it is a safety component of — or is itself — a product governed by EU sectoral safety legislation listed in Annex I. The original Annex I list includes medical devices, in-vitro diagnostic medical devices, civil aviation safety components, marine equipment, lifts, radio equipment, machinery, and pressure vessels.
The Digital Omnibus makes a material change here. The Machinery Regulation has been moved from Annex I Section A to Section B. For AI embedded in machinery products, the full suite of Chapter III AI Act obligations no longer applies directly. Instead, the Commission must adopt delegated acts incorporating AI-specific health and safety requirements into the Machinery Regulation by 2 August 2028. If you make AI-enabled industrial machinery, this reduces your AI Act compliance burden significantly — but the underlying Machinery Regulation requirements still apply, and you must monitor the Commission’s delegated acts closely.
The Omnibus also tightens the definition of “safety component.” AI systems used solely for user assistance, performance optimisation, service efficiency, automation, or convenience — where a failure or malfunction would not create risks to health or safety — do not qualify as safety components and therefore do not trigger Track 1 high-risk classification. This is an important carve-out for AI features that improve product experience without touching safety functions.
Track 2: The eight Annex III domains
The second and broader route to high-risk classification is use-case based. If your AI system is used in one of eight domains listed in Annex III, it is presumptively high-risk. These domains were chosen because AI deployment in these areas poses the greatest risk to health, safety and fundamental rights.
| # | Annex III domain | Key examples |
|---|---|---|
| 1 | Biometric identification and categorisation | Remote biometric identification; biometric categorisation inferring sensitive attributes; emotion recognition in law enforcement, border management, work and education |
| 2 | Critical infrastructure | Safety components of digital infrastructure, road transport, supply of water, gas, heating, electricity |
| 3 | Education and vocational training | Determining access to, or assigning persons to, educational institutions; evaluating learning outcomes; monitoring and detecting prohibited student behaviour |
| 4 | Employment and worker management | Recruitment, candidate selection, task allocation, performance evaluation, promotion and termination decisions, worker monitoring |
| 5 | Access to essential private and public services | Credit scoring; insurance risk assessment; emergency call evaluation and dispatch prioritisation; social benefits eligibility assessment |
| 6 | Law enforcement | Individual risk assessment for crime; polygraph and lie detection tools; deepfake detection in investigations; crime analytics profiling populations |
| 7 | Migration, asylum and border control | Polygraphs; risk assessment for irregular migration; asylum application examination; border surveillance systems |
| 8 | Administration of justice and democratic processes | AI assisting judicial authorities in researching and interpreting facts and law; election administration and voting |
One point that catches many organisations: the domain test is about intended purpose and actual use, not just what the system is called or how it is marketed. An AI tool sold as a “talent analytics platform” that makes recommendations materially influencing hiring decisions falls within domain 4 regardless of how it is branded.
The Article 6(3) escape hatch: when Annex III systems are not high-risk
Falling within an Annex III domain does not automatically make a system high-risk. Article 6(3) provides an important escape: an Annex III system is not considered high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision-making.
The regulation specifies four conditions under which this escape applies. A system qualifies as non-high-risk where it:
- performs a narrow procedural task;
- improves the result of a previously completed human activity;
- detects decision-making patterns or deviations without replacing or influencing a completed human assessment; or
- performs a preparatory task to an assessment relevant for the Annex III purpose.
Where a provider concludes their system is not high-risk under this escape, they must document that assessment before placing the system on the market or putting it into service and register it in the EU database with the reasoning. Under the Omnibus (pending adoption), the registration information requirements for self-assessed non-high-risk systems are slightly simplified — but the registration obligation itself is preserved.
The Commission’s May 2026 classification guidelines: what they change
On 19 May 2026 the Commission published draft guidelines on high-risk AI system classification that work through each of the eight Annex III domains in detail with practical examples. Two clarifications from these guidelines are immediately significant for anyone doing a classification assessment.
First, intended purpose is determined from the totality of the product — instructions for use, promotional materials, technical documentation, and how the system is actually positioned in the market — not from a single document. A provider cannot escape high-risk classification by adding a clause to their terms of service excluding high-risk uses if their marketing, onboarding materials and technical architecture tell a different story. Regulators will look at what you built and how you sold it, not only at what your contract says.
Second, the presence or absence of human review is irrelevant to classification. Whether a human reviews the AI’s output before a decision is made does not determine whether the system is high-risk. It is only relevant to compliance once the system is classified — specifically to the human oversight obligations under Article 14. An HR AI that recommends candidates for rejection is in the employment domain whether or not a recruiter reviews the recommendation before acting on it.
The draft guidelines are open for stakeholder comment and not yet finalised, but they represent the Commission’s authoritative interpretation of the classification rules and should be treated as such in any current assessment.
What the Omnibus changes for high-risk classification
It is important to be precise about what the Digital Omnibus does and does not change for classification. The Omnibus changes the compliance deadlines and narrows certain definitions — but it does not change the core classification methodology or the Annex III domain list.
What changes under the Omnibus (pending OJ publication):
- Compliance deadline for Annex III: 2 August 2026 → 2 December 2027 (16 months)
- Compliance deadline for Annex I: 2 August 2027 → 2 August 2028 (12 months)
- Machinery Regulation: moved from Annex I Section A to B — full Chapter III suite no longer applies directly to AI-enabled machinery
- Safety component definition: narrowed to exclude AI used solely for non-safety user assistance, optimisation, efficiency or convenience
- Legacy systems: systems already on the market before the relevant application date only fall under high-risk obligations if they undergo a significant design change after that date
What does not change: the eight Annex III domains, the Article 6(3) escape logic, the Article 6(1) safety-component test (as narrowed above), the high-risk compliance obligations themselves, and the requirement to classify systems and document the assessment. The extra time the Omnibus provides is time to prepare — not permission to defer classification.
High-risk compliance: what is actually required
Once a system is classified as high-risk, providers must build and maintain a comprehensive compliance architecture before the system reaches the market and throughout its life.
- Risk management system (Art. 9) — a continuous, documented process identifying and mitigating risks across the system’s lifecycle
- Data governance (Art. 10) — training, validation and testing data must be relevant, representative, appropriately free of errors, and complete
- Technical documentation (Art. 11) — comprehensive documentation prepared before market launch, covering system design, capabilities, limitations, performance metrics and validation
- Automatic record-keeping / logging (Art. 12) — the system must automatically log events necessary to identify risks and enable post-market monitoring
- Transparency to deployers (Art. 13) — clear, accurate instructions for use enabling deployers to operate the system properly and exercise oversight
- Human oversight (Art. 14) — design measures ensuring effective human oversight, including the ability to interpret and override outputs
- Accuracy, robustness and cybersecurity (Art. 15) — appropriate levels for the intended purpose, including resilience against manipulation
- Conformity assessment (Art. 43) — self-assessment or third-party assessment depending on system type, before market launch
- EU Declaration of Conformity + CE marking (Arts. 47–48)
- EU database registration (Art. 49) — mandatory even for self-assessed non-high-risk systems
For the full picture of compliance obligations and deadlines, see our EU AI Act overview and the complete compliance timeline.
What to do now
- Run a full AI inventory. Classification cannot start without knowing every AI system your organisation provides or deploys.
- Apply the two-track test to each system. Annex I safety component (Track 1)? Annex III domain (Track 2)? Both questions, independently.
- Apply the Article 6(3) escape carefully and document it. The Commission’s May 2026 draft guidelines are your reference.
- Don’t rely on terms of service to escape classification. The totality of how you design and market the system determines its classification.
- Start the compliance build now. Risk management systems and technical documentation take months. For fines, see our Article 99 penalties guide. For SME-specific obligations, see our AI Act for SMEs guide.
- Register in the EU database. Even self-assessed non-high-risk systems must be registered. This obligation is not deferred by the Omnibus.
Frequently asked questions
How do I know if my AI system is high-risk?
Apply the two-track test. First: is the AI a safety component of an Annex I product? Second: is its intended purpose within one of the eight Annex III domains? If yes to either, it is presumptively high-risk. Then check the Article 6(3) escape — narrow procedural task, improving a completed human activity, or not materially influencing decision-making?
Does the Omnibus change which systems are classified as high-risk?
Not directly. It changes compliance deadlines and narrows the safety-component definition and Machinery Regulation treatment — but not the Annex III domain list or Article 6(3) escape logic. A system high-risk today remains high-risk under the Omnibus.
Can I escape high-risk classification by adding an exclusion to my terms of service?
No. The Commission’s May 2026 draft guidelines are clear: intended purpose is determined from instructions for use, promotional materials, and technical documentation as a whole. A terms-of-service exclusion that contradicts how the system is designed and marketed will not hold.
Is human review of AI outputs relevant to classification?
No. Per the Commission’s May 2026 draft guidelines, the presence or absence of human review before a decision is not relevant to classification. It is only relevant to human oversight compliance obligations once classification is determined.
When is the deadline for high-risk compliance?
Under the Digital Omnibus (pending adoption): 2 December 2027 for Annex III stand-alone systems; 2 August 2028 for Annex I product-embedded systems. Until OJ publication, the original dates remain the legal text. See the full AI Act compliance timeline.
Key takeaways
- High-risk AI system classification uses two independent tracks: Annex I product-embedded (Art. 6(1)) and Annex III use-case-based in eight domains (Art. 6(2)).
- The Article 6(3) escape can take an Annex III system out of high-risk if it performs only a narrow procedural task or does not materially influence decision-making — but must be documented and registered.
- The Commission’s May 2026 guidelines clarify that intended purpose is determined from the totality of the product, and that human review is irrelevant to classification.
- The Omnibus defers deadlines to December 2027 / August 2028 and narrows the safety-component definition — but does not change the eight Annex III domains or the classification methodology.
- Classification must happen now: database registration, inventory, and the compliance build all depend on knowing which systems are high-risk.
