AI Act High Risk Classification
How to classify an AI system as high-risk under Article 6 and Annex III of the EU AI Act after the Digital Omnibus, with the new 1a to 1c carve-outs, a decision tree and worked examples.
Updated
12 min read
113 views
Key takeaways: AI Act high risk classification 5
How the Omnibus changed Article 6 without touching Annex III, and the carve-outs and worked examples for classifying a system as high risk.
- The list did not change, the carve-outs did Annex III and Annex IV were both left untouched by the Omnibus, while Article 6 itself was rewritten with new carve-out paragraphs 1a, 1b and 1c.
- Two tracks, two dates Annex I high-risk systems apply from 2 August 2028 under Article 6(1), while Annex III high-risk systems apply earlier, from 2 December 2027, under Article 6(2).
- Convenience features are not automatically safety components Article 6(1a) excludes purely non-safety convenience and optimization functions from the safety-component test, but Article 6(1b) pulls back in anything whose failure would endanger health or safety.
- A worked example beats a checklist The three worked examples in this article, covering credit scoring, CV screening and predictive maintenance, show the classification test applied to real features rather than in the abstract.
- The statutory guidance deadline has already passed The Article 6(5) classification guidelines were due by 2 February 2026 and remain unpublished, so documenting an Article 6(4) classification now is more reliable than waiting for guidance that is already overdue.
In short: AI Act high risk classification changed when Regulation (EU) 2026/1744 rewrote Article 6 of the EU AI Act in substance, not only its dates: new paragraphs 1a, 1b and 1c narrow which product-embedded systems count as a safety component, while a system whose failure would endanger health and safety stays in scope. Annex III still lists exactly eight high-risk areas, untouched by the Omnibus. It binds from 2 December 2027, eight months before the Annex I route applies from 2 August 2028. The Article 6(5) guidelines meant to draw these lines were due by 2 February 2026, and as of 27 July 2026 the Commission still describes them as in preparation. Classify your system against the statute below; the Commission's own Article 6 reader still shows the unamended text and cannot be trusted for this call.
The two-track test for high-risk classification
Two separate routes lead to the same "high-risk" label, and since the Omnibus they no longer share one application date.
Track 1, Article 6(1) and Annex I, product-embedded systems (2 August 2028)
Article 6(1) applies only where both of its conditions hold at once: point (a), "the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I," and point (b), "the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment... pursuant to the Union harmonisation legislation listed in Annex I." Both must hold together. The new 1a to 1c paragraphs shape point (a). This track binds from 2 August 2028, a year later than the original 2027 date.
Track 2, Article 6(2) and Annex III, standalone or listed-use-case systems (2 December 2027)
Article 6(2) is one sentence: "In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk." No safety-component test applies, and no third-party assessment either. A system qualifies simply by matching one of Annex III's eight areas. New paragraphs 1a to 1c never touch this route, since they amend paragraph 1, not paragraph 2. This track binds from 2 December 2027, eight months ahead of Annex I, inverting a common assumption that the product-embedded system carries the earlier duty. The standalone route the Omnibus left untouched arrives first instead.
Annex III's eight areas, unchanged
Its own chapeau text is direct: "High-risk AI systems pursuant to Article 6(2) are the AI systems listed in any of the following areas." Eight numbered areas follow in Annex III, and a system only reaches the Article 6(2) route by falling inside one of them.
| Annex III area | Sub-points that matter |
|---|---|
| 1. Biometrics, in so far as permitted under Union or national law | Remote biometric identification, biometric categorization by protected attributes, emotion recognition. Verification of a claimed identity is excluded. |
| 2. Critical infrastructure | Safety components managing critical digital infrastructure, road traffic, water, gas, heating or electricity supply. |
| 3. Education and vocational training | Access or admission decisions, evaluating learning outcomes, assessing accessible education level and monitoring test behavior. |
| 4. Employment, workers' management and access to self-employment | Recruitment or selection, including job ads and filtering applications, plus decisions on promotion, termination or task allocation. |
| 5. Access to essential private and public services and benefits | Eligibility for public assistance benefits, creditworthiness or credit scoring with fraud detection excepted, life and health insurance pricing, emergency dispatch or triage. |
| 6. Law enforcement, in so far as permitted under Union or national law | Victim-risk assessment, polygraphs, evaluating evidence reliability, assessing offending or re-offending risk, and profiling in criminal investigations. |
| 7. Migration, asylum and border control management, in so far as permitted under Union or national law | Polygraphs, assessing security, migration or health risk, examining asylum, visa or residence applications, detecting persons, travel-document verification excepted. |
| 8. Administration of justice and democratic processes | Assisting a judicial authority in researching and applying the law, plus influencing an election, referendum or voting behavior, campaign-logistics tools excepted. |
None of the eight areas gained or lost a sub-point. What changed sits inside Article 6 itself.
What Article 6 actually changed - the new 1a, 1b, 1c
Nobody checking Annex III found this scope change, because it never lived there. Point (8) of the amending act inserted three new paragraphs into Article 6 itself, and even the Commission's own Article 6 page still carries an unresolved amendment disclaimer, one of the stale sources our EU AI Act compliance hub covers in full. A reader who trusts that page alone sees Article 6(1) with no 1a, 1b or 1c at all.
1a, non-safety assistance, optimization and convenience functions do not qualify
New paragraph 1a reads in full: "For the purposes of this Regulation, including paragraph 1 of this Article, 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." The operative word is "solely": a feature that genuinely does only one of those things, with no safety role at all, cannot be swept into the Article 6(1)(a) safety-component test, however tightly it sits inside a regulated product.
1b, the safety-critical exception to 1a
Paragraph 1b is the backstop, one sentence long: "Notwithstanding paragraph 1a, AI systems the failure or malfunctioning of which would endanger health and safety shall qualify as safety components." Read 1a and 1b together, never 1a alone: a feature marketed purely as convenience or efficiency still counts as a safety component the moment its own failure could endanger health or safety, whatever the provider calls it. This is the paragraph most summaries skip.
1c, third-party assessment for non-safety risks does not trigger 6(1)(b)
Paragraph 1c targets the other half of the Article 6(1) test, point (b) rather than point (a): "A product that is required to undergo a third-party conformity assessment solely due to risks other than risks to health and safety, in particular risks relating to the distribution of radio spectrum or electromagnetic interference that do not affect health and safety, shall not be considered as fulfilling the condition in paragraph 1, point (b)." Radio-equipment rules often require third-party assessment for spectrum or electromagnetic-interference reasons unrelated to safety, and 1c says that assessment alone does not satisfy point (b). Point (8) left Article 6(2), Article 6(3) and Article 6(5) untouched, so none of these carve-outs reaches an Annex III system.
The Omnibus also touches Annex I directly: Point (41) deletes point 1 from Section A and adds a new point 21 to Section B, naming Regulation (EU) 2023/1230, the Machinery Regulation. This article works through the Article 6(1) and Article 6(2) tests in full; what that Section A to Section B move changes for a specific machinery product's own conformity-assessment path turns on the Machinery Regulation itself, a question outside this article's scope, and our EU AI Act compliance hub carries the dates that apply once a product lands in either Annex.
Decision path - classify your system in five questions
Run these in order against one feature at a time, since two features in the same product can land on opposite sides of Article 6.
- Confirm the feature is an AI system as the Act defines the term. A fixed lookup table or a hand-written script never reaches Article 6.
- If the feature sits inside an Annex I product needing third-party assessment, run the 1a to 1c test: a purely non-safety function is not a safety component under 1a. Any health-and-safety failure is one regardless under 1b. A third-party assessment covering only non-safety risks like radio spectrum fails point (b) under 1c.
- Check the feature by name against Annex III's eight areas, not a general sense of risk. Area membership alone triggers Article 6(2), independent of Article 6(1).
- For a feature matching an Annex III area, test the Article 6(3) derogation, covered in full in the dedicated section below.
- Record which path applies, file the Article 6(4) documentation and Article 49(2) registration if claiming the derogation, and mark 2 December 2027 for an Annex III route or 2 August 2028 for an Annex I route.
| Verdict | Provision | Applies from |
|---|---|---|
| High-risk, Annex I safety component confirmed under 1a to 1c | Article 6(1) and Annex I | 2 August 2028 |
| High-risk, Annex III area matched, no derogation or profiling present | Article 6(2) and Annex III | 2 December 2027 |
| Not high-risk, Annex III matched but the Article 6(3) derogation holds | Article 6(3), plus Article 6(4) documentation and Article 49(2) registration | No high-risk duty |
| Not high-risk at all | No Annex I match and no Annex III area match | Not applicable |
Running a fixed sequence before writing code is the same discipline our OWASP agentic top 10 coverage recommends for agentic-system risk, a different framework answering the same underlying question of where a feature actually sits.
Worked examples
Three features engineering teams actually build, run through the five questions above.
Example A, credit scoring
A credit-scoring feature that sets a person's credit limit is named directly in Annex III, "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score," so it is high risk under Article 6(2) from 2 December 2027, since 1a to 1c touch only Article 6(1). Any Article 6(3) derogation attempt runs into that paragraph's own backstop: profiling of natural persons is always high risk, and a credit score is a profile by definition. Annex III's own narrower exception here, "with the exception of AI systems used for the purpose of detecting financial fraud," rarely covers a lending feature.
Example B, CV screening
A CV-screening feature that filters applications before a recruiter sees them falls under Annex III's employment area, which names "the recruitment or selection of natural persons... to analyse and filter job applications, and to evaluate candidates" directly, so it is high risk under Article 6(2) from 2 December 2027 with no route through 1a to 1c. Whether Article 6(3)'s "preparatory task" condition covers a filtering step that never makes the final call is a real question, not a settled one, close to what the overdue Article 6(5) guidelines were meant to answer. Until the Commission publishes them, treat a feature that materially affects who gets an interview as high risk and document the reasoning under Article 6(4).
Example C, predictive maintenance
A predictive-maintenance feature flagging vibration anomalies on a production line, built solely to cut downtime and defects, sits inside machinery already subject to third-party conformity assessment. If that assessment addresses only a non-safety requirement, a radio module's spectrum compliance for instance, new 1c blocks the Article 6(1)(b) condition outright, and read for its stated purpose alone, new 1a keeps it out of the safety-component definition too. Neither carve-out survives once the feature's failure could let a machine exceed a safety limit and injure an operator: 1b's "notwithstanding paragraph 1a" wording pulls that fault back in, and if the machine still needs third-party assessment for that hazard, Article 6(1) resolves toward high risk from 2 August 2028.
The Article 6(3) derogation and its four conditions
Article 6(3) was not touched by the Omnibus. An Annex III system escapes high-risk status only where "it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making," and even then only if one of four conditions holds. Article 6(3) lists them as a narrow procedural task, improving a prior human activity's result, detecting decision patterns without replacing the prior assessment, or a preparatory task to that assessment. One closing sentence overrides all four at once: "Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons." Article 6(4) turns the derogation into paperwork: a provider relying on it "shall document its assessment before that system is placed on the market or put into service," and "shall be subject to the registration obligation set out in Article 49(2)."
Why the Article 6(5) classification guidelines matter, and why they are late
Article 6(5) keeps its own deadline, unaffected by the Chapter III deferral: the Commission "shall, after consulting the European Artificial Intelligence Board (the 'Board'), and no later than 2 February 2026, provide guidelines specifying the practical implementation of this Article... together with a comprehensive list of practical examples of use cases of AI systems that are high-risk and not high-risk." Point (40) confirms the exclusion, deferring Chapter III's Sections 1 to 3, other than Article 6(5), to the 2027 and 2028 dates, so 6(5) kept its original date. That date passed six months ago. The Commission's own FAQ page on the AI Act, last updated 27 July 2026, still states: "The Commission is preparing guidelines for the high-risk classification, which will be published ahead of the application date for these rules." Put the two facts together: a statutory deadline already missed, and a live page still describing the guidelines as work in progress. Until they land, our AI governance framework coverage makes the same point from the deployment side: document a defensible Article 6(4) classification now rather than wait on guidance that has already missed its deadline.
How Pharos Production supports AI Act risk classification
The five questions above only work if one person is accountable for the answer. Article 6(4) ties a specific duty to whoever claims the Article 6(3) derogation: document the assessment before the system reaches the market, with a named owner attached to that call rather than a committee revisiting it once a year.
Our AI governance practice builds the classification logic against Article 6 and the right Annex into a program a notified body can review, with our compliance and regtech solutions team keeping the resulting Article 6(4) documentation and Article 49(2) registrations current on the other side of that decision.
Sources: Regulation (EU) 2024/1689 (the EU AI Act), Article 6 and Annex III, via EUR-Lex; Regulation (EU) 2026/1744 of 8 July 2026 (the Digital Omnibus on AI), points (8), (40) and (41), via EUR-Lex, ELI data.europa.eu/eli/reg/2026/1744/oj; the European Commission's AI Act regulatory framework page and its FAQ page on navigating the AI Act, last updated 27 July 2026; and the AI Act Service Desk's Article 6 page, observed 28 July 2026. This article is engineering guidance, not legal advice. Confirm every classification against the primary text with qualified counsel before you rely on it.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
An AI system is high-risk if it matches either of two tracks. Under Article 6(2), a system is high-risk simply by falling inside one of the eight areas listed in Annex III, no other test required.
Under Article 6(1), a system is high-risk only if it is a safety component of, or is itself, a product covered by Annex I legislation, and that product needs third-party conformity assessment.
-
No, the Omnibus left both Annex III and Annex IV untouched, so the list of high-risk areas itself did not change. What changed instead sits inside Article 6, where new paragraphs 1a, 1b and 1c narrow which product-embedded systems count as a safety component.
The Omnibus did touch Annex I directly through point (41), deleting one entry from its Section A and adding a new entry naming the Machinery Regulation to Section B.
-
Article 6(1a) excludes systems used solely for non-safety-related user assistance, performance optimization, service efficiency, automation, convenience or quality control from counting as safety components. Article 6(1b) immediately narrows that exclusion: a system whose failure or malfunction would endanger health and safety still qualifies as a safety component regardless of 1a.
Reading 1a alone therefore misses the point, since 1b pulls back anything genuinely safety-critical.
-
There is a narrow one, under Article 6(1c). A product that needs third-party conformity assessment solely for risks unrelated to health and safety, such as radio spectrum or electromagnetic interference, does not satisfy the Article 6(1)(b) condition on that basis alone.
This exemption only affects the Article 6(1) and Annex I track, since point (8) of the Omnibus left Article 6(2) and Annex III untouched.
-
The Article 6(3) derogation lets an Annex III system escape high-risk status if it does not pose a significant risk of harm and meets one of four conditions: performing a narrow procedural task, improving the result of a completed human activity, detecting decision patterns without replacing the prior assessment, or performing a preparatory task to that assessment. A single backstop overrides all four at once, since any system performing profiling of natural persons is always high risk regardless of which condition it meets.
A provider relying on the derogation must document that assessment under Article 6(4) and register under Article 49(2).
-
There is no confirmed date yet. Article 6(5) required the Commission to publish classification guidelines no later than 2 February 2026, and that deadline has already passed.
As of 27 July 2026, the Commission's own FAQ page on the AI Act still describes the guidelines as being prepared, with no publication date given, so a documented Article 6(4) classification is more reliable right now than waiting on guidance that is already overdue.
-
Annex I systems are product-embedded safety components that need third-party conformity assessment under Article 6(1), applying from 2 August 2028. Annex III systems are standalone or listed-use-case systems that qualify by matching one of the eight areas the annex lists under Article 6(2), with no safety-component or third-party-assessment test and applying eight months earlier, from 2 December 2027.
Because the standalone route carries the earlier date, a team that assumes product-embedded systems always come first has the sequencing backward.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
