An AI system becomes high-risk under the EU AI Act through one of two routes only: either it is a product or safety component covered by the Annex I product-safety legislation (Article 6(1)), or it is a standalone system used in one of the eight sensitive domains listed in Annex III (Article 6(2)). The Commission's draft classification guidelines, published on 19 May 2026, walk through both routes in detail and make clear that the narrow exceptions in Article 6(3) almost never apply once a system carries out profiling.
For most organisations, the single most consequential compliance question under the AI Act is binary: is my system high-risk, or is it not? Everything else follows from that answer. High-risk status triggers the full weight of the obligations in Chapter III, from risk management and data governance to logging, human oversight, technical documentation and registration in the EU database. A wrong answer in either direction is costly: classify down and you face enforcement; classify up unnecessarily and you carry a compliance burden the law never intended.
On 19 May 2026 the European Commission finally published the draft guidelines that are supposed to settle this question. They are issued under Article 6(5), which obliged the Commission to provide classification guidance, and they arrive across three documents: a horizontal set of general principles, plus two annex-specific volumes covering the Annex I product route and the Annex III use-case route. A targeted consultation runs until 23 June 2026, and the final text is expected by the end of the year.
The draft guidelines are non-binding. They explain how the Commission reads Article 6, but they do not create new obligations and cannot override the regulation itself. The substance still matters enormously: market surveillance authorities and courts will treat the Commission's reasoning as the most authoritative reading available. Note also that the deadline for Annex III high-risk obligations has moved to 2 December 2027 under the Digital Omnibus package, on which the Council and Parliament reached political agreement on 7 May 2026. Formal adoption is still pending.
Why the timing is awkward
The guidelines were due in February 2026, eighteen months after the AI Act entered into force. They landed roughly three months late, and they land into a moving target. The Digital Omnibus package has pushed the application date for Annex III high-risk systems from August 2026 to 2 December 2027, and for Annex I systems embedded in regulated products to 2 August 2028. That delay buys organisations more time to act on the classification question, but it does not change the question itself. The two routes described below are the ones every provider will eventually have to work through.
Route one: Article 6(1) and Annex I
The first route covers AI systems that are bound up with physical product safety. A system is high-risk under Article 6(1) when two conditions are both met. First, the AI system is itself a product, or is a safety component of a product, covered by one of the Union harmonisation laws listed in Annex I. That list reaches into machinery, medical devices, in-vitro diagnostics, toys, lifts, radio equipment, civil aviation, motor vehicles and more. Second, that product is required to undergo a third-party conformity assessment before it can be placed on the market under the relevant Annex I law.
The logic here is integration rather than novelty. The AI Act does not invent a separate regime for these systems; it folds AI risk into the existing product-safety machinery. If a medical-device manufacturer already needs a notified body to assess its device, the AI component travels with it. The draft guidelines provide non-exhaustive examples of what counts as a safety component, while stressing that an example appearing on the list does not by itself make a given deployment lawful.
The practical takeaway for the Annex I route is that classification follows the product, not the buzzword. An AI model marketed as a generic tool may become high-risk the moment it is integrated as a safety component into a regulated machine.
Route two: Article 6(2) and Annex III
The second route is the one most organisations will care about, because it captures standalone software used in sensitive areas of life. Under Article 6(2), a system is presumptively high-risk if it falls within one of the eight domains of Annex III:
| # | Annex III domain | Typical examples |
|---|---|---|
| 1 | Biometrics | Remote biometric identification, biometric categorisation, emotion recognition |
| 2 | Critical infrastructure | Safety components managing water, gas, electricity, digital infrastructure, traffic |
| 3 | Education and vocational training | Admissions scoring, exam evaluation, detecting prohibited exam behaviour |
| 4 | Employment and worker management | CV screening, candidate ranking, promotion and termination decisions |
| 5 | Essential private and public services | Creditworthiness scoring, benefits eligibility, life and health insurance pricing |
| 6 | Law enforcement | Risk assessment of offending, evidence reliability, profiling of individuals |
| 7 | Migration, asylum and border control | Visa and asylum risk assessment, document verification |
| 8 | Administration of justice and democracy | Assisting judicial decisions, influencing elections |
The decisive concept here is intended purpose. A provider must assess what the system is designed and marketed to do before placing it on the market. The draft guidelines are blunt on a point that has caused a lot of wishful thinking: bolting a human into the loop does not rescue a system from high-risk status. If the intended purpose and area of use fall within Annex III, human involvement at the point of decision does not change the classification. Oversight is a high-risk obligation, not an escape hatch from it.
The Article 6(3) exceptions: narrow by design
Article 6(3) is the only valve that lets an Annex III system out of high-risk status. It says that a system listed in Annex III is not 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 then fixes four, and only four, situations where that can be the case.
| Exception | What it covers | Practical example |
|---|---|---|
| Narrow procedural task | The system performs a limited, well-defined procedural step | Transforming unstructured data into structured form |
| Improving prior human work | The system refines the result of a completed human activity | Cleaning up the language of a human-drafted document |
| Detecting decision patterns | The system flags deviations from prior decision patterns without replacing the human assessment | Flagging that a grade is inconsistent with a teacher's usual marking |
| Preparatory task | The system performs a preparatory step before a human assessment | Indexing, searching or translating files ahead of review |
Two limits keep these exceptions tight. The provider claiming an exception carries the burden: it must document its assessment before the system goes to market, and that documentation must be available to authorities on request. An unsupported assertion that "this is just a procedural tool" will not survive scrutiny.
The harder limit is the profiling carve-out. Article 6(3) states that a system is always high-risk, no exception available, if it performs profiling of natural persons within the meaning of Article 4(4) GDPR. Profiling there means any automated processing of personal data to evaluate personal aspects, in particular to analyse or predict performance at work, economic situation, health, preferences, behaviour, location or movements. Because so many Annex III use cases in employment, credit, insurance and law enforcement are built precisely on that kind of evaluation, the profiling rule swallows most attempts to invoke the four exceptions. If your system profiles people, the analysis stops there.
Interconnected systems count as one
A final point in the draft guidelines closes an obvious workaround. Where several AI systems are combined so that their joint outputs or shared intended purpose materially influence a decision about a person, the whole configuration is treated as a single AI system for classification purposes. You cannot split a high-risk function into a chain of individually innocent-looking components and argue that none of them, taken alone, crosses the threshold. Classification looks at the combined effect.
What providers should do now
The delay to 2 December 2027 is breathing room, not a reprieve. The classification analysis is the foundation for every other obligation, and it cannot be done at the last minute because it depends on how a system is designed and described from the outset. Three steps follow from the draft guidelines:
First, map each AI system to the two routes. Decide whether it is product-bound (Annex I) or use-case-bound (Annex III), and document the reasoning. Second, where a system sits in an Annex III domain, test honestly whether any Article 6(3) exception genuinely applies, and check the profiling question first because it is dispositive. Third, write the assessment down before deployment, because the burden of proving an exception sits with the provider.
The consultation window is also an opportunity. It runs until 23 June 2026, which gives organisations a chance to flag where the examples are unclear or where their own systems fall into the grey zones the guidelines do not yet resolve.