Is my AI system high-risk under the EU AI Act? A decision tree

The EU AI Act has four tiers — prohibited, high-risk, limited-risk, minimal-risk. The one most teams need to get right is high-risk, because that's where the bulk of the obligations live (technical documentation, conformity assessment, CE marking, ongoing monitoring) and the cost of misclassification runs into months of unplanned work.

Here is the decision tree, in the order the regulators actually apply it. At each step, if the answer locks in a higher tier, the lower tiers stop mattering.

Step 1 — Does the system involve any Article 5 prohibited practice?

Article 5 lists practices that cannot be placed on the EU market at all. The headline ones:

• Subliminal techniques causing significant harm
• Exploitation of vulnerabilities (age, disability, social or economic situation)
• Social scoring by public authorities
• Individual predictive policing based solely on profiling
• Untargeted scraping of facial images for recognition databases
• Emotion recognition in workplaces or educational institutions
• Biometric categorisation inferring sensitive attributes (race, religion, sexual orientation, …)
• Real-time remote biometric identification in publicly accessible spaces by law enforcement

If any of these apply, the system is prohibited. Stop here, redesign, or leave the EU market. There is no "indicative" interpretation of Article 5; it is a hard rule.

Step 2 — Is the AI a safety component of, or itself a regulated product under, Annex I/II?

Article 6(1) is the first path to high-risk. The system is high-risk if both are true:

1. It is a safety component of a product covered by EU harmonisation legislation listed in Annex I (machinery, medical devices, toys, lifts, automotive, aviation, marine equipment, …) — *or it is itself such a product*.
2. The product is required to undergo a third-party conformity assessment under that legislation.

Concrete examples:

• An AI module that adjusts machinery braking force in a CE-marked industrial line: high-risk.
• An AI-driven diagnostic feature inside an MDR-regulated medical device: high-risk.
• An LLM-based copilot that *suggests* dosing to a doctor but is not part of a medical device: doesn't enter via this path. (Probably enters via Annex III — keep going.)

This step traps a lot of teams who assume "we're a software company, not a hardware company" and skip it. If you ship into a regulated industry, recheck this carefully.

Step 3 — Does the intended use fall into any Annex III sector?

Article 6(2) is the second path to high-risk. Annex III lists eight sectors. Your system is high-risk if its intended use falls into any of them:

1. Biometrics — identification, categorisation, emotion recognition.
2. Critical infrastructure — road traffic, water, gas, electricity, digital infrastructure.
3. Education and vocational training — admissions, evaluation, exam monitoring.
4. Employment and worker management — recruitment, evaluation, task allocation, performance monitoring.
5. Access to essential private and public services — credit scoring, insurance pricing, public benefits eligibility, emergency dispatch.
6. Law enforcement — risk assessment, evidence evaluation, profiling.
7. Migration, asylum, and border control.
8. Administration of justice and democratic processes.

The classifier in step 3 is the intended use, not the technology stack. A general-purpose LLM is not by itself high-risk; an LLM deployed *for* CV screening is, because that's Annex III(4).

This is where the most common misclassification happens. Teams say "we're just a chatbot" and skip Annex III. But if the chatbot determines worker schedules (employment), evaluates loan applications (essential services), or filters student admissions (education), that's Annex III.

Step 4 — Does the Article 6(3) derogation apply?

If you answered yes to step 3, there is one escape route. Article 6(3) says an Annex III system is not high-risk if it performs a narrow procedural / preparatory / pattern-detection task and does not pose a significant risk to health, safety, or fundamental rights.

Examples Recital 53 cites:

• A narrow procedural task (e.g. converting unstructured data to structured data).
• A task that is preparatory to assessment relevant for the listed use cases.
• Pattern detection that does not replace or influence a human assessment without proper human review.

If you rely on Article 6(3), you carry the burden of documenting *why* the derogation applies. The provider must register the system in the EU database before placing it on the market. So this is "high-risk-light" rather than "no obligations".

If the derogation applies, you exit the high-risk path and go to step 5. If not, you are high-risk — stop here and start the Annex IV documentation work.

Step 5 — Article 50 transparency triggers

Even if you escaped high-risk, four user-facing situations bring transparency obligations:

• Direct interaction with people (chatbot, voice assistant): tell users they are interacting with an AI — Article 50(1).
• Synthetic content generation (image, audio, video, text): mark output as machine-generated, in machine-readable form — Article 50(2).
• Emotion recognition or biometric categorisation: inform exposed persons — Article 50(3).
• Deepfake: disclose that content is artificially generated or manipulated — Article 50(4).

Any of these → limited-risk. You owe the relevant disclosure but no Annex IV documentation.

Step 6 — GPAI overlay (Articles 51–55)

This isn't a tier on its own; it sits on top of any of the above. If your system is or relies on a General-Purpose AI model:

• Standard GPAI (Article 53) → technical documentation of the model, downstream-provider information, copyright policy, training-data summary.
• GPAI with systemic risk (Article 55) → standard obligations plus model evaluation, systemic risk assessment, incident reporting, cybersecurity measures.

The systemic-risk threshold is currently set at 10²⁵ FLOP of training compute (or specifically designated by the Commission). Most teams aren't training their own foundation models, so this lands on the few model providers, not on integrators.

Step 7 — None of the above

If steps 1–6 all came up negative, your system is minimal-risk. The Act has no mandatory product obligations on its face. Your job is documentation: write down *why* the system is minimal-risk so a future audit can reproduce the analysis.

---

Where teams trip up

In our validation calls with mid-size AI teams, three traps came up over and over:

1. Skipping step 2. "We're software, not hardware." But if you ship features into a regulated product, the regulated product's conformity regime pulls you in.
2. Reading step 3 too narrowly. The classifier is *intended use*, not *technology*. Re-read your sales collateral; if it pitches a use case in Annex III, you're in Annex III.
3. Treating step 4 as a free pass. The derogation requires *documentation*. If you can't write down the analysis, you can't claim it.

If you want a starting point, take the [free 5-question risk classifier](/quiz). It applies the same tree, deterministically, in about three minutes — and emails you a one-page PDF you can share with your team.

*Documentation tool, not legal advice. Have qualified counsel review documents with legal effect.*