High-risk classification is the gate that decides whether the EU AI Act’s heaviest obligations apply to you. Here is the actual decision logic in Article 6 and Annex III — in plain language, with the exceptions most summaries miss.
Almost every concrete EU AI Act obligation — the risk management system (Art 9), technical documentation, human oversight (Art 14), registration — only bites if your system is classified high-risk. Article 6 is where that classification is decided. Get it wrong and you either over-engineer compliance for a minimal-risk tool, or miss obligations on a system that genuinely qualifies.
Article 6 of Regulation (EU) 2024/1689 defines two independent routes. A system is high-risk if it satisfies either one.
A system is high-risk when both conditions hold:
Separately, “AI systems referred to in Annex III shall be considered to be high-risk.” This is the route most software, financial-services and HR teams care about, because it is defined by what the system is used for, not by product-safety law.
“AI systems referred to in Annex III shall be considered to be high-risk.”
Regulation (EU) 2024/1689, Article 6(2)Annex III lists eight areas. If your AI system is used in one of these contexts — and is not caught by an exception below — it is high-risk under Article 6(2).
| # | Annex III area | Typical examples |
|---|---|---|
| 1 | Biometrics (where its use is permitted under Union or national law) | Remote biometric identification, biometric categorisation, emotion recognition |
| 2 | Critical infrastructure | AI as a safety component in road traffic, or supply of water, gas, heating, electricity, and critical digital infrastructure |
| 3 | Education and vocational training | Admissions/assignment, scoring tests, detecting prohibited exam behaviour |
| 4 | Employment, workers management and access to self-employment | CV screening, candidate ranking, task allocation, performance evaluation |
| 5 | Access to essential private and public services and benefits | Creditworthiness / credit scoring, eligibility for public assistance, risk pricing in life and health insurance |
| 6 | Law enforcement (where permitted under law) | Risk assessment of offending, evidence reliability evaluation, profiling |
| 7 | Migration, asylum and border control management (where permitted under law) | Visa/asylum application assessment, security risk assessment |
| 8 | Administration of justice and democratic processes | Assisting a judicial authority in researching and interpreting facts and law |
Financial services note. Creditworthiness assessment and credit scoring sit in Annex III point 5, and risk assessment and pricing in life and health insurance are explicitly named. This is why banks and insurers treat their scoring and pricing models as high-risk by default — the burden then falls on demonstrating that an exception applies, not on proving the system is in scope.
Being listed in Annex III does not automatically make a system high-risk. Article 6(3) provides a derogation: an Annex III system is not high-risk where it “does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons” and meets at least one of four conditions:
The profiling carve-out. The exception never applies if the system performs profiling of natural persons. A system that profiles people is “always” considered high-risk, regardless of how narrow or preparatory the task looks. This is the single most common place teams get the classification wrong.
And the exception is not a free pass on paperwork. Under Article 6(4), a provider that concludes its Annex III system is not high-risk must document that assessment before placing the system on the market or putting it into service. In other words: claiming the exception is itself a documented compliance act.
The two routes have different application dates under Article 113:
| Route | Applies from |
|---|---|
| Article 6(2) — Annex III high-risk use cases | 2 August 2026 |
| Article 6(1) — Annex I product-safety route | 2 August 2027 |
For most software, finance, HR and public-sector teams, the date that matters is 2 August 2026.
One moving part worth tracking: a proposed EU simplification package — the Digital Omnibus on AI, provisionally agreed in 2026 but not yet adopted into law as of mid-2026 — would defer the Annex III high-risk obligations (reported to late 2027). Until it is formally adopted and published in the Official Journal, the binding deadline in the Regulation as enacted remains 2 August 2026 — so plan against that date and watch the legislative process.
Classification is not a one-time legal opinion you file away. To run Article 6 across a portfolio you need, per system: a record of its intended purpose and use context, the Annex III area it touches (if any), whether an Article 6(3) exception was claimed, and the documented Article 6(4) assessment behind that claim. When systems change — new use cases, new data, new deployment — the classification has to be re-checked.
That is fundamentally an inventory problem. You cannot classify, document, or defend systems you have not catalogued. An AI inventory is step zero: a single register where every system carries its classification, its rationale, and a change history a regulator can follow.
Model Inventory for Jira turns each AI system into a Jira work item with a built-in EU AI Act category field (Article 6) and dynamic risk tiering. Record the Annex III area, the exception rationale, and an immutable change history — inside the Jira your team already uses, with no new vendor or data processor. It is the inventory and classification layer; your wider compliance programme still owns the legal assessment itself.
See how it worksThis page is a practical explanation, not legal advice. Always confirm classification against the official text of Regulation (EU) 2024/1689 and, where the stakes warrant it, qualified counsel.