EU AI Act High-Risk Classification: How Article 6 Actually Works

Ask five compliance teams whether their system is "high-risk" under the EU AI Act, and at least two will answer based on how the system feels rather than how Article 6 actually tests it. The test is mechanical, not intuitive, and it runs in two independent tracks — and it's worth confirming first that the system clears Article 5's prohibited-practices screen, since no high-risk classification saves a system that falls into one of those eight banned categories.

Track one: products already covered by EU safety law

If your AI system is a safety component of a product already regulated under the legislation listed in Annex I — medical devices, machinery, toys, lifts, and similar categories with existing EU conformity-assessment regimes — and that product requires third-party conformity assessment, the AI component is high-risk by extension. This track catches AI embedded in physical products more often than software teams expect: a diagnostic algorithm inside a Class IIa medical device inherits high-risk status through the device's own regulatory pathway, not through a separate AI-specific test.

Track two: the Annex III use-case list

This is the track that catches most standalone software. Annex III lists specific use-case categories, and if your system falls into one of them, it's presumptively high-risk. The categories that generate the most classification questions:

• Employment — systems used for recruitment, candidate screening, or decisions on promotion and termination
• Access to essential services — creditworthiness evaluation, eligibility for public benefits, risk assessment for life and health insurance pricing
• Biometric identification and categorization — remote biometric identification is treated separately and more strictly; categorization by sensitive attributes is its own listed category
• Education — systems that determine access to educational institutions or evaluate learning outcomes in ways that affect a student's course

The exemption teams get wrong

Article 6(3) carves out an exemption: a system that falls into an Annex III category is not high-risk if it doesn't materially influence the outcome of the decision — for example, a system that performs a narrow procedural task, improves the result of a previously completed human activity, or detects patterns without replacing human assessment.

Teams reach for this exemption too quickly. It does not cover "a human technically clicks approve." The exemption is about the system's actual influence on the outcome, and the Act places the burden on the provider to document why the exemption applies — including, specifically, a requirement to register the exemption assessment before placing the system on the market. If your documentation folder doesn't contain that assessment, you don't have a defensible exemption; you have an assumption.

What high-risk status actually requires

Classification isn't the end of the analysis — it's the trigger for a specific set of obligations under Articles 9 through 15: a risk management system maintained across the system's lifecycle, data governance requirements for training data, technical documentation, automatic logging capability, transparency obligations toward deployers, human oversight measures, and defined levels of accuracy, robustness, and cybersecurity. Each of those is a separate, auditable requirement, not a single checkbox.

How this connects to your broader governance program

Article 6 classification should plug directly into the risk-tiering step of your governance framework, not run as a separate parallel process — a system that classifies as high-risk under Annex III should land in your "consequential" tier automatically. See our governance framework checklist for how that tiering is meant to work end to end.