EU AI Act High-Risk: How to Classify Your AI System

Key takeaways

• The EU AI Act high-risk deadline moved, but the classification rules in Article 6 did not change. Regulation (EU) 2026/1744 deferred Annex III obligations to 2 December 2027 and Annex I obligations to 2 August 2028.
• You cannot know which deadline applies to you until you have classified. Article 50 transparency duties were never deferred and have applied since 2 August 2026.
• There are two routes into high-risk status: an Annex I product route and an Annex III use-case route. Only the second is a list you can look yourself up in.
• The Article 6(3) exemption is not relief. Claiming it means documenting the assessment before market placement and registering the claim in the public EU database.
• Human oversight, a terms-of-service disclaimer and a modular architecture do not change classification. Classification follows intended purpose.

The deadline moved, the determination did not

If you have been waiting for the EU AI Act high-risk regime to settle before classifying your systems, the waiting is the risk. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, amending the AI Act itself (Regulation (EU) 2024/1689). It pushed the compliance dates back. It did not touch the question of who is in scope. Three dates now sit on the same regulation, and they diverge:

1. 2 December 2027. Obligations for standalone high-risk systems listed in Annex III, moved back from 2 August 2026.
2. 2 August 2028. Obligations for AI embedded in products already covered by EU product-safety law under Annex I, moved back from 2 August 2027.
3. 2 August 2026. The Article 50 transparency duties, which were not deferred at all. Disclosure that a user is interacting with an AI system applied from that date, with a short grace period to 2 December 2026 for marking machine-generated content.

The practical consequence is easy to miss. A team that has not classified cannot tell which of those three dates governs its roadmap. Worse, the deferral was agreed as a set of fixed dates rather than the conditional, standards-readiness trigger the Commission originally proposed, according to Gibson Dunn’s analysis of the agreement. There is no further slippage built in to wait for. Classification is therefore the first governance act, not a downstream compliance task. It determines your deadline, your obligation set, whether you need a conformity assessment at all, and whether you owe a registration entry before you ship. If your AI inventory does not carry a determination per system, you do not have a compliance position; you have a plan to form one later.

Two routes into EU AI Act high-risk status, and only one is a list

Article 6 defines two independent paths. A system needs to satisfy only one of them.

Route one: Annex I products and safety components

Under Article 6(1), a system is high-risk when both conditions hold. First, the AI system is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I. That legislation covers machinery, medical devices, lifts, toys, radio equipment, in-vitro diagnostics and similar regulated product families. Second, that product is required to undergo a third-party conformity assessment under the same legislation (Article 6). The second condition does a lot of work and is regularly overlooked. Being inside an Annex I product family is not sufficient on its own. If the product’s own regime allows self-assessment, this route does not close. “Safety component” is broader than it sounds. Article 3(14) catches a component whose failure or malfunctioning endangers health and safety, not only one whose stated job is safety. A combustion-efficiency optimiser sold as an energy feature can qualify, because its malfunction creates a carbon monoxide risk. The Digital Omnibus narrowed the notion somewhat, excluding components that merely assist a user without creating a health or safety risk, as Travers Smith notes in its review of the changes.

Route two: Annex III use cases

Under Article 6(2), a system is high-risk if it falls within one of the use cases listed in Annex III and is not caught by one of the Article 6(3) filters. This is the route most software companies travel, and the one people mean when they search for the EU AI Act high-risk list. The two routes carry the same obligation set once triggered, but different dates: December 2027 for Annex III, August 2028 for Annex I. A product company shipping an AI component into regulated hardware and a SaaS vendor selling a hiring tool are on different clocks.

The eight Annex III areas, read the way an auditor reads them

Most guides reproduce Annex III as a list of sectors. That framing causes misclassification, because the annex does not regulate sectors. It regulates decisions. Read each area as the decision the system touches.

• Biometrics. Remote biometric identification, biometric categorisation that infers sensitive or protected attributes, and emotion recognition. Note that some biometric practices are prohibited outright under Article 5 rather than merely high-risk.
• Critical infrastructure. Only where the system acts as a safety component in the management or operation of digital infrastructure, road traffic, or utility supply. A back-office analytics tool for a utility is not automatically in scope.
• Education and vocational training. Admission decisions, evaluating learning outcomes, assessing the appropriate level of education, and monitoring prohibited behaviour during tests. Summative assessment is the trigger.
• Employment and worker management. The entire recruitment pipeline from sourcing and screening through to selection, plus decisions on promotion, termination, task allocation and performance monitoring. This is the broadest area in practice and the one most SaaS vendors underestimate.
• Access to essential private and public services. Eligibility for public benefits, creditworthiness and credit scoring, risk assessment and pricing in life and health insurance, and emergency call triage and dispatch.
• Law enforcement. Assessing the risk of offending or reoffending, evaluating evidence reliability, polygraph-type tools, and profiling in the course of investigations.
• Migration, asylum and border control. Risk assessments, examination of visa and asylum applications, and identification.
• Administration of justice and democratic processes. Assisting judicial authorities in researching and interpreting facts and law, and systems intended to influence the outcome of an election or voting behaviour.

If your system produces an input to any of those decisions, you are in the annex until a filter takes you out. That is the correct default, and it is the opposite of how most teams reason about it. Our EU AI Act operator’s guide sets out what follows once the determination lands on high-risk.

Article 6(3): the exemption that costs more than compliance

Article 6(3) is the most misread provision in the EU AI Act high-risk regime. It allows a provider to conclude that a system listed in Annex III is nonetheless not high-risk, because 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 four filters

A system escapes only if it meets at least one of these conditions:

1. Narrow procedural task. Converting unstructured data to structured data, classifying incoming documents into predefined categories, or detecting duplicates.
2. Improving a previously completed human activity. The system refines a result a human has already produced, without replacing or autonomously redoing that judgment.
3. Detecting decision-making patterns or deviations from them. Flagging that a decision departs from prior patterns, without replacing or influencing the human assessment absent proper review.
4. Performing a preparatory task. Indexing, searching, translating or linking material ahead of an assessment.

The Commission’s draft guidance reads these narrowly. A system that ranks, scores or labels inputs as more or less useful for a human assessor has gone beyond a purely procedural task, because that ordering shapes the decision. On the fourth filter, the test is proximity to the final decision and whether the output amounts to a specific recommendation, according to Freshfields’ analysis of the draft guidelines.

The two carve-outs

Two things disable the filters entirely. A system that performs profiling of natural persons is always high-risk, with no exception. And a component sitting inside a larger architecture cannot claim a filter where the combined intended purpose or the joint outputs of that architecture materially influence a high-risk decision.

Why claiming the exemption is a public act

Here is the part that changes the economics. Under Article 6(4), a provider who concludes that an Annex III system is not high-risk must document that assessment before the system is placed on the market or put into service. Under Article 49(2), that provider must then register itself and the system in the EU database. The Digital Omnibus retained this registration duty while reducing the information required. So the exemption is not a private decision made in a design review. It is a filed claim, visible to regulators, with your reasoning attached and available to national competent authorities on request. If a market surveillance authority has sufficient reason to believe the system was misclassified, it can evaluate the classification and require you to bring the system into full high-risk compliance within a set period. Compare the two paths honestly. Accepting high-risk status means building the Article 9 risk management system and the rest of the Chapter III obligations on a December 2027 clock. Claiming the exemption means producing a defensible legal analysis now, publishing the claim now, and carrying the risk of reclassification with retroactive exposure. For a genuinely procedural system the exemption is right. For a borderline one it is often the more expensive road.

Three ways teams get the determination wrong

The draft Commission guidelines close three arguments about EU AI Act high-risk status that are still common in design reviews.

“Our terms of service exclude high-risk use”

Classification turns on intended purpose, defined in Article 3(12) as the use for which the provider intends the system, as specified in the instructions for use, in promotional and sales materials, in statements, and in the technical documentation. A contractual disclaimer buried in terms of service does not override what your marketing says the product does. Where documentation presents broad applicability across contexts without clearly excluding high-risk uses, the intended purpose can be read to include them, particularly where those uses are feasible and reasonably foreseeable. There is a second edge here. Under Article 25, a distributor, importer or deployer that puts its own name on a high-risk system, substantially modifies it, or repurposes a general system for a high-risk use becomes the provider and inherits the provider obligations. Buying a general-purpose tool and pointing it at a hiring decision makes you the provider of a high-risk system.

“We have a human in the loop”

Human involvement cannot by itself prevent a system from being classified as high-risk. Classification is decided by intended purpose; oversight is what Article 14 requires after a system is already classified. Treating a reviewer as a classification shield inverts the structure of the regulation. The degree of human involvement is not irrelevant. It can support an argument that a system performs only a limited or preparatory function that does not materially influence the decision, which feeds the Article 6(3) analysis. But that is a filter argument with evidence behind it, not a general exemption. The distinction between human-in-the-loop and human-on-the-loop matters for Article 14 design, not for whether Article 6 bites.

“We split it into components”

Where several AI components form a broader system with a combined intended purpose, or whose joint outputs materially influence a decision, the assessment is holistic. Splitting an architecture into individually innocuous services does not defeat classification. The guidelines extend the same reasoning to agentic systems that coordinate through interconnected actions. Only genuinely separable components performing strictly procedural or preparatory functions, and not contributing to the high-risk purpose, stay outside.

What the Commission’s draft guidelines change in practice

Article 6(5) obliges the Commission to publish guidelines on the practical implementation of the classification rules. The draft arrived on 19 May 2026, later than the 2 February 2026 date the Act set, and opened a targeted consultation that was extended to 23 July 2026 after stakeholders asked for more time (European Commission). The final text is expected by the end of 2026. The draft is organised into general principles, the Annex I safety-component route, and the Annex III use cases, with practical examples of systems that should and should not be classified as EU AI Act high-risk systems. The Commission is explicit that the examples are not exhaustive and may be updated. Two things follow for a governance team. The guidelines are non-binding, so they do not create obligations on their own. But they are written to direct market surveillance authorities toward uniform enforcement, which makes them the working baseline an authority will measure you against. And because the text is still draft, a determination made today should record which version it relied on, and carry a review trigger for when the final guidelines land. That is ordinary AI compliance hygiene, and it is cheap to build in now and expensive to retrofit across a portfolio later.

Turning the determination into a record you can defend

An EU AI Act high-risk classification that lives in a Slack thread is not a classification. Whether you land on high-risk or on an Article 6(3) filter, the output should be a dated, owned record. At minimum it should carry:

• The system identity and version, so the determination is pinned to something specific.
• The intended purpose as published, quoting your own instructions for use and marketing copy rather than paraphrasing them.
• Which route was tested, Annex I or Annex III, and the outcome of each.
• If a filter is claimed, which one, with the reasoning and the evidence that the system does not materially influence the decision.
• The profiling check and the architecture check, both recorded as explicit negatives rather than left silent.
• The named owner, the date, and the trigger that forces a re-assessment.

That last item is the one teams skip. Substantial modification restarts the analysis, and so does a change in how the product is marketed. A determination is a statement about a version and a stated purpose, and both of those move. Keeping the record next to the technical documentation rather than in a separate legal folder is what makes it retrievable when an authority asks. This is the same discipline that underpins any working AI governance programme: the decision and its evidence live together, and both are addressable.

FAQ

What are the EU guidelines for high-risk AI systems? The European Commission published draft guidelines on the classification of high-risk AI systems on 19 May 2026, under Article 6(5) of the AI Act. They interpret the classification concepts and give practical, non-exhaustive examples of systems that should and should not be treated as high-risk. A targeted consultation ran until 23 July 2026 and the final version is expected by the end of 2026. The guidelines are non-binding, but they are intended to steer market surveillance authorities toward consistent enforcement, so they function as the practical benchmark. What are the high-risk use cases for AI systems according to the EU AI Act? Annex III lists eight areas: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services including creditworthiness and insurance pricing; law enforcement; migration, asylum and border control; and the administration of justice and democratic processes. A system in one of those areas is high-risk unless it meets one of the four Article 6(3) filters, and it is always high-risk if it profiles natural persons. Is the EU AI Act mandatory? Yes. It is a regulation, so it applies directly in all EU member states without national transposition. What changed in 2026 is timing rather than obligation: Regulation (EU) 2026/1744 deferred the EU AI Act high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Prohibited practices and the Article 50 transparency duties already apply. Does the EU AI Act apply to the US? It applies to providers that place AI systems on the EU market or put them into service in the EU, wherever they are established, and to providers and deployers outside the EU where the output produced by the system is used in the EU. A US company with EU customers, or whose model output reaches people in the EU, is generally in scope. Establishment is not the test; market and output are. Does the December 2027 deferral mean we can wait? No, for two reasons. If you intend to rely on the Article 6(3) exemption, the assessment must be documented and registered before the system is placed on the market, which is a pre-market duty rather than a 2027 one. And if the determination lands on high-risk, the December 2027 date is when a conformity assessment, technical documentation, logging, a quality management system and registration must all already be in place, not when the work starts. Who decides whether a system is high-risk, the provider or the deployer? The provider makes and documents the determination. Deployers are not passive, though: under Article 25 a deployer becomes a provider, with the full provider obligation set, if it puts its own name or trademark on a high-risk system, substantially modifies it, or uses a system outside its stated purpose for a high-risk application. Many organisations that consider themselves deployers are providers of at least one system.

Conclusion

The Digital Omnibus bought time on the EU AI Act high-risk obligations. It bought none on the question. Article 6 still asks whether a system is a safety component in a regulated product, whether it sits in one of the eight Annex III areas, and whether any of the four narrow filters genuinely applies. The answer sets your deadline, your obligation set and your registration duty, and the one route that looks like an escape carries a pre-market documentation and registration cost of its own. The organisations that will be ready in December 2027 are the ones treating classification as a governed, versioned decision now, with an owner and a review trigger, rather than a legal memo written once the deadline is close enough to feel real.