EU AI Act high-risk classification — a decision tree for AI builders.

Companion piece to our EU AI Act for banks guide. This page was updated after the Commission published draft high-risk classification guidelines in May 2026. The draft is interpretive and non-binding; a targeted consultation remained open through July 23, 2026. The regulation itself remains the primary legal source.

The classification matters more than the answer

Before the decision tree, the meta-point: a defensible classification with a documented rationale is better than the "right" answer with no paper trail. Regulators don't grade classifications in isolation; they grade your reasoning. A system you classified as not-high-risk with three pages of rationale is much safer than the same system classified as not-high-risk with a one-line memo. The tree below produces classifications and forces the rationale at each step.

Application timeline as of July 19, 2026

The timeline is moving. The Commission's July 2026 overview reports that prohibited-practice and AI-literacy rules have applied since February 2, 2025, GPAI obligations since August 2, 2025, and transparency rules from August 2026. Following the May 2026 political agreement on the AI Omnibus, the Commission describes high-risk use-case rules applying from December 2, 2027 and product-integrated high-risk rules from August 2, 2028. Confirm the adopted legal text and any transitional rule before relying on these dates.

Step 1 — Is it AI under the Act's definition?

Article 3(1) defines an AI system as "a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions, that can influence physical or virtual environments."

Practical filter:

• Yes, AI: ML models, LLMs, computer vision, NLP, recommender systems, decision-support systems with learned components.
• Probably not: rules-based systems where every output is deterministically computed by hand-written code (a tax calculator, a static scorecard, a rules engine).
• Edge cases: heuristic search, optimisation solvers and statistical techniques require analysis against Article 3(1) and the Commission's AI-system-definition guidance. Record why the system does or does not meet each element.

Step 2 — Is it prohibited under Article 5?

If yes, stop. The system can't be placed on the EU market or used by EU operators. Prohibited practices include:

• Subliminal or purposefully manipulative techniques causing significant harm.
• Exploiting vulnerabilities (age, disability, social or economic situation) causing significant harm.
• Social scoring by public authorities or in the public interest, where the score causes detrimental treatment in unrelated contexts.
• Predicting criminal offences based purely on profiling.
• Untargeted scraping of facial images from the internet or CCTV to build facial recognition databases.
• Emotion recognition in workplace and education (with narrow medical/safety exceptions).
• Biometric categorisation inferring sensitive attributes (with narrow law-enforcement exceptions).
• Real-time remote biometric identification in publicly accessible spaces by law enforcement (with narrow exceptions).

For most commercial AI, Article 5 isn't a concern. For AI products in employment, education, public services, security, or content moderation — read it carefully.

Step 3 — Is it Annex III high-risk?

Annex III lists eight high-risk use-case areas. If your AI system falls into one, it's high-risk by classification (with a narrow Article 6(3) exception we'll cover next).

The eight areas, with the most-litigated examples for tech companies:

1. Biometrics — remote biometric identification, biometric categorisation, emotion recognition.
2. Critical infrastructure — safety components in road traffic, water, gas, heating, electricity.
3. Education and vocational training — admissions, evaluation of learning outcomes, monitoring during tests, allocation to programs.
4. Employment, workers management, access to self-employment — recruitment, advertisement targeting for job ads, candidate filtering, performance evaluation, promotion / termination decisions, work allocation, monitoring.
5. Access to essential private and public services and benefits — public-benefit eligibility, credit-scoring of natural persons, life and health insurance risk assessment / pricing, emergency services dispatch / triage.
6. Law enforcement — risk assessment for individuals, polygraph and similar, evidence reliability, predictive policing in narrow conditions, profiling.
7. Migration, asylum, and border control management — polygraph and similar, risk assessment of migration / security, applications for asylum / visas / residence, detection / recognition / identification.
8. Administration of justice and democratic processes — judicial-decision assistance, alternative dispute resolution, influencing election outcomes through targeted information.

For tech-company AI, the most common landings are area 4 (employment), area 5 (essential services / credit / insurance), and indirectly area 1 (biometrics for identity verification).

Step 4 — Does Article 6(3) apply?

Article 6(3) carves out an exception: even if a system falls in an Annex III area, it's NOT high-risk if it does not pose a "significant risk of harm to the health, safety, or fundamental rights of natural persons." The exception applies in four cases:

• (a) The system is intended to perform a narrow procedural task.
• (b) The system is intended to improve the result of a previously completed human activity.
• (c) The system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review.
• (d) The system is intended to perform a preparatory task to an assessment relevant for the use cases listed in Annex III.

Article 6(4) requires providers relying on the Article 6(3) exception to document the assessment before placing the system on the market or putting it into service. If the system performs profiling of natural persons, Article 6(3) does not provide the exception.

The right way to use 6(3): only when you can write a one-page memo justifying it, and when you would happily produce that memo to a regulator. If you can't, treat the system as high-risk.

Step 5 — Annex I product-safety integration

Separately from Annex III, an AI system is also high-risk if it is a safety component of a product covered by EU product-safety legislation listed in Annex I, OR is itself such a product, OR is required to undergo a third-party conformity assessment under that legislation.

Annex I covers a wide range: machinery, toys, recreational craft, lifts, pressure equipment, radio equipment, in-vitro diagnostic medical devices, civil aviation, motor vehicles, marine equipment, rail, agricultural and forestry vehicles, etc. If you build AI for these domains, you're in. The AI Act sits on top of the existing product-safety regime.

Step 6 — General-Purpose AI (GPAI) — separate track

If your system is a general-purpose AI model (LLM, foundation model, multimodal model), Title VIII applies separately from the high-risk track. Two tiers:

• All GPAI providers — technical documentation, downstream provider information, copyright policy, training-data summary.
• GPAI with systemic risk — additional obligations: model evaluation, adversarial testing, serious incident tracking, cybersecurity for the model and physical infrastructure. Triggered when the model exceeds 10²⁵ FLOPs of training compute or is otherwise designated by the Commission.

If you build on top of a GPAI rather than provide one, you may have downstream obligations as a "deployer" but you don't pick up GPAI-provider obligations. The provider does.

Step 7 — Limited-risk transparency (Article 50)

If the system isn't prohibited and isn't high-risk, but interacts with humans, generates content, or performs emotion recognition / biometric categorisation in any non-prohibited context, transparency obligations apply:

• Disclose to users that they are interacting with an AI.
• Disclose AI-generated or manipulated content (deepfakes, generated text in public-interest contexts).
• Disclose emotion recognition / biometric categorisation when applicable.

These are usually UI/UX changes plus a privacy-notice update, not a heavy compliance program.

Step 8 — Other AI systems

If no branch above applies, the system may have no system-specific high-risk or Article 50 obligation under this decision tree. That does not mean “unregulated”: provider or deployer duties, AI-literacy requirements, data protection, consumer protection, product law, employment law and sector rules may still apply. Article 95 also supports voluntary codes of conduct.

What to do with the classification

For each AI system in scope, produce a one-page classification memo:

• System name, intended purpose, intended users.
• Step-by-step rationale through the tree above (with citation to specific articles).
• Final classification: prohibited / high-risk Annex III / high-risk Annex I / GPAI / limited / minimal.
• If high-risk under Annex III, the specific area (3.5(b), 3.4, etc.).
• If 6(3) exception applied, the rationale per criterion plus confirmation that no profiling occurs.
• Date, classifier (named human), reviewer (named human), legal sign-off.

This memo is the artifact you hand to internal audit, an EU-AI-Act notified body (for high-risk), or a regulator. It's also the seed document Sia RegAI's agent uses to scaffold the downstream Annex IV documentation if the system lands as high-risk.

Keeping classifications current with Sia RegAI

RegReview can monitor the adopted AI Act and selected Commission materials, preserve new versions and route potentially affected classifications to an accountable reviewer. RegMatcher can connect an approved interpretation to the relevant systems, policies and controls, then retain the rationale as teams build a repeatable, human-reviewed classification workflow.

For an agreed internal AI inventory, that workflow can support:

• Walking each system through the decision tree with citations to the controlling article and annex.
• Drafting a classification memo for qualified review rather than treating model output as the decision.
• Starting the relevant documentation and control assessment when a system is classified as high-risk.
• Reassessing affected systems when the legal source, intended purpose or deployment context changes.

Measure value with a controlled pilot: baseline the classification effort, review time, rework and exception rate; then compare the same inventory and acceptance criteria.

Common pitfalls

• Stopping at Annex III without checking Annex I. Product-safety legislation captures a lot of AI that builders don't think of as "high-risk."
• Over-using 6(3). The exception is narrow. If the system involves profiling natural persons, don't claim it.
• Forgetting deployer obligations. If you deploy someone else's high-risk AI, you have your own Article 26 obligations (use logs, monitoring, human oversight). Classification of the system as high-risk doesn't off-ramp you.
• Treating GPAI as separate from product AI. If you build a product on top of a GPAI, both tracks apply: GPAI to the underlying model (handled by the provider), product to your specific use of it.
• Single-shot classification. An AI system's intended purpose can change. Re-classify on material changes; document the trigger.

Closing

The EU AI Act looks intimidating because it's long and the penalties are real. The classification framework underneath, run as a tree, is tractable. The mistake most AI builders make is treating it as a single legal question; the win is treating it as a triage workflow that produces defensible memos for each system.

Get the tree right, document the rationale, repeat for every system. The compliance program flows from the classifications.

Primary sources

• EUR-Lex — Regulation (EU) 2024/1689
• European Commission — draft high-risk classification guidelines, May 2026
• European Commission — high-risk systems guidelines and July 2026 timeline
• European Commission — AI Act implementation overview