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:
The Digital Omnibus narrowed this route considerably, and the narrowing is what keeps ordinary business software out of it. Three new paragraphs were inserted into Article 6. The first says that AI used solely for non-safety purposes is not a safety component at all:
“AI systems that are solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control shall not qualify as safety components.”
Regulation (EU) 2024/1689, Article 6(1a), as inserted by Regulation (EU) 2026/1744The second paragraph closes the obvious gap: under Article 6(1b), an AI system whose failure or malfunctioning would endanger health and safety qualifies as a safety component regardless. The test is consequence, not label — a component sold as a convenience feature is still caught if people get hurt when it fails.
The third takes aim at a technicality that would otherwise have swept in a great deal of connected hardware. Article 6(1c) provides that a product required to undergo third-party conformity assessment solely for reasons other than health and safety — the text names risks relating to the distribution of radio spectrum and electromagnetic interference — does not satisfy the second condition above.
What this means in practice. If your AI is a feature inside software — an assistant, a scheduler, a quality check, a recommendation — and it is not sold as part of a regulated physical product, Route 1 is almost certainly not your route. Ask Route 2 instead. Where it does bite is the classic product cases: a medical device, a machine, a vehicle, a lift — and there the question is whether failure of the AI part endangers health or safety.
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 |
Four of these areas carry most of the “does my use case qualify?” questions, so they have their own decoders: education (point 3), employment & HR (point 4), credit scoring & essential services (point 5) and administration of justice (point 8) — use-case-by-use-case verdicts, including what is not high-risk but prohibited.
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. Fraud detection and prudential capital models are carved out, and points 5(b) and 5(c) are the only Annex III systems that trigger a FRIA for a private deployer — both unpacked in the point 5 decoder.
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.
Annex III high-risk classification applies from 2 December 2027; the Annex I product-safety route applies from 2 August 2028. The two routes have different application dates. The Regulation as enacted set them in Article 113; the Digital Omnibus moves both:
| Route | As enacted | After the Digital Omnibus |
|---|---|---|
| Article 6(2) — Annex III high-risk use cases | 2 August 2026 | 2 December 2027 |
| Article 6(1) — Annex I product-safety route | 2 August 2027 | 2 August 2028 |
For most software, finance, HR and public-sector teams, the date that matters is now 2 December 2027. The Article 5 prohibitions, by contrast, have applied since 2 February 2025 — the prohibited check comes before the high-risk one.
The Digital Omnibus on AI — published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744, in force since 27 July 2026 — defers the high-risk obligations to the fixed dates above; the final text dropped the earlier idea of making them conditional on the availability of harmonised standards. What does not move: the Article 5 prohibitions, the Article 4 AI literacy duty, the GPAI rules, and the Article 50 transparency obligations (from 2 August 2026). See what actually changed →
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.
Now work out what this means for one system: the EU AI Act compliance checklist walks the Article 6 decision above — prohibitions, both high-risk routes, the Article 6(3) exception and the profiling carve-out — and then hands you the obligations for whatever it lands on. Free, no sign-up.
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.