The EU AI Act high-risk guide, from classification to action.

The EU AI Act doesn’t classify systems by how capable they are — it classifies them by legal route, and there are exactly two ways into the high-risk tier. A deterministic credit-scoring formula built in a spreadsheet can be high-risk under Annex III, while a far more powerful chatbot answering product questions carries only transparency duties.

Route 1 — products under Annex I legislation (Article 6(1))

High-risk where two limbs both hold: the system is a safety component of (or is) a product covered by the Annex I harmonisation legislation — machinery, medical devices, lifts, toys, civil aviation — and that product already requires third-party conformity assessment. AI inside a regulated product whose conformity route never involves a notified body does not qualify through this route.

Route 2 — stand-alone Annex III use cases (Article 6(2))

High-risk where the system’s intended purpose falls within one of the eight Annex III areas — no physical product needed. A pure SaaS tool that screens and ranks job applicants is squarely inside, however simple its logic. The “neither” answer matters just as much: most systems in a typical company — recommendation, internal search, forecasting, fraud detection — sit outside both routes and carry no high-risk obligations at all.

The route drives everything downstream — which deadline applies, which Article 43 conformity path you follow, and whether the Article 6(3) exemption is even available (it exists only for Annex III systems). Get the route wrong and every later decision inherits the error.

Annex III lists eight use-case areas; a system whose intended purpose falls within any of them is high-risk under Article 6(2), subject only to the Article 6(3) filter. The in-and-out examples below follow the draft Commission guidelines of 19 May 2026 — persuasive, not binding, and liable to change in the final text.

Points 1–4: biometrics, infrastructure, education, employment

Point 1 covers remote biometric identification, biometric categorisation and emotion recognition — but pure verification (device unlock, access control) is carved out. Point 2 is AI as a safety component in critical infrastructure. Point 3 catches admission, grading and exam-monitoring systems. Point 4 — the one most private companies hit first — catches CV-screening, candidate ranking, promotion and termination decisions, and behaviour-based task allocation. Workplace context alone is not a trigger: generic meeting transcription and calendar tools are out.

Points 5–8: services, credit, law enforcement, justice

Creditworthiness assessment and credit scoring of natural persons are in (point 5(b)) — but financial fraud detection is expressly carved out of that same point. Life and health insurance pricing is in (point 5(c)). Points 6–8 — law enforcement, migration and justice — are mostly public-sector facing; the catch for founders is that selling into those buyers makes you the provider of a high-risk system. If you sell govtech, your buyer’s use case is your classification.

Across all eight points, intended purpose controls the analysis — which is why your marketing copy and your instructions for use are classification evidence, not just sales material.

Article 6(3) is the only exit from the Annex III route, and it is narrowly drawn. An Annex III system escapes high-risk status only where it does not pose a significant risk of harm, including by not materially influencing the outcome of decision-making. The exemption is available where the system performs:

1. 1a narrow procedural task;
2. 2an improvement to the result of a previously completed human activity;
3. 3detection of decision-making patterns or deviations, without replacing or influencing the completed human assessment without proper human review; or
4. 4a preparatory task to an assessment relevant to an Annex III use case.

A CV parser that extracts fields into a form is the classic condition (d); a tool that scores or ranks the same CVs is not. The filter gets over-claimed because teams read condition (b) as covering any tool with a human in the loop — the draft guidelines read it far more narrowly.

Two filings survive a claim: document the assessment before placing the system on the market (Article 6(4)), and register it in the EU database anyway (Article 49(2)). A conclusion reached verbally in a product meeting is a liability, not a documented assessment.

On 19 May 2026 the European Commission published draft guidelines on the classification of high-risk AI systems, delivering on the Article 6(5) mandate. Three parts: general classification principles (the central role of intended purpose), the Article 6(1) / Annex I product route, and the Article 6(2) / Annex III route with practical in-scope and out-of-scope examples for each point.

The third part carries the most weight for private companies. It is the first Commission-authored statement of where the line sits — CV screening versus interview scheduling, credit scoring versus fraud detection, biometric identification versus verification — borderlines teams have argued over since the Act took effect.

Clarification, not law

The guidelines are not legally binding — authoritative interpretation rests with the Court of Justice of the EU, and the final text may differ. But market-surveillance authorities will treat them as their working reference, so a classification that diverges from a guideline example needs a written justification for the divergence.

Classification tells you whether a system is high-risk; your role tells you which obligations you carry for it. The duties split between the provider — who develops the system or places it on the market under its own name — and the deployer, who uses it under its own authority. Roughly: build-time evidence versus run-time discipline.

The provider stack (Articles 8–22)

The heavy stack: a risk management system (9), data governance (10), technical documentation per Annex IV (11), automatic logging (12), transparency and instructions for use (13), human-oversight-by-design (14), and accuracy, robustness and cybersecurity (15) — plus quality management (17), conformity assessment (43), CE marking (48) and EU database registration (49). It is a system, not a checklist: the Article 9 output feeds the Annex IV file, which the Article 43 assessment draws on. Scope it with the Annex IV technical documentation template.

The deployer list (Article 26)

Lighter and operational: use the system per the provider’s instructions, assign competent human oversight, keep input data relevant where you control it, monitor operation, retain logs for at least six months, and inform affected workers before putting a high-risk system into use. Most companies are deployers for most systems and providers only for what they build or white-label — track the split in the AI system register template.

When a deployer becomes the provider (Article 25)

The trapdoor between the roles: a deployer inherits the full Articles 8–22 stack where it puts its name on a high-risk system, makes a substantial modification, or repurposes a non-high-risk system into a high-risk use. The three traps that catch founders: fine-tuning a vendor model, rebranding a vendor tool in your own UI, and repurposing an internal tool into an Annex III use case.

The fundamental rights impact assessment under Article 27 is the single most over-claimed obligation in compliance marketing. The scope is narrow, and most private companies deploying high-risk AI sit outside it.

The FRIA binds only three groups of deployers: bodies governed by public law, private entities providing public services, and deployers of two specific Annex III systems — point 5(b) creditworthiness and credit scoring, and point 5(c) life and health insurance pricing. A private company deploying a CV-screening tool under point 4 does not need a FRIA, whatever a vendor deck says; a regional bank deploying a credit-scoring model does, because of point 5(b).

What it contains, and when

Completed before first use, it covers the deployment processes, the period and frequency of use, the categories of affected persons, the specific risks of harm, the human-oversight measures, and the mitigations if risks materialise. The deployer then notifies the market-surveillance authority of the outcome, and updates the assessment when elements change.

Build on your DPIA — don’t duplicate it

Article 27 lets the deployer rely on an existing GDPR Article 35 DPIA where it already covers the ground — the FRIA complements it rather than restarting. The overlap map is in FRIA vs DPIA, and the FRIA template gives you the Article 27(1) structure.

Two timeline mistakes dominate boardroom conversations in mid-2026: assuming everything has been delayed, and assuming nothing has. Both are wrong.

Already binding today

The Article 5 prohibitions have applied since 2 February 2025, with the €35 million / 7% tier attaching to breaches now, and the GPAI regime of Articles 51–55 since 2 August 2025. The Digital Omnibus moves neither — its only change here is an addition: a new prohibition (the CSAM and so-called nudifier ban) taking effect 2 December 2026.

What the Omnibus changes, and what it doesn’t

Reaching political agreement on 6–7 May 2026, the Omnibus would defer stand-alone Annex III high-risk to 2 December 2027 and Annex I product-embedded high-risk to 2 August 2028 — but as of June 2026 this is agreed, not yet law (until Official Journal publication, Article 113 still reads 2 August 2026), and on fixed calendar dates (the standards-contingent “stop the clock” variant was rejected). Most Article 50 transparency is unchanged; content-marking and watermarking land on 2 December 2026.

Everything above converts into a single 90-day programme. The sequencing below assumes you are starting from an unstructured position — pull milestones forward where parts already exist.

Days 1–30 — inventory & classify

Build the complete AI system inventory, including AI features inside the SaaS tools you subscribe to; run every system through the two Article 6 routes and the Annex III point mapping; and write the Article 6(4) memo for every Article 6(3) claim. Baseline with the readiness assessment method.

Days 31–60 — roles, gaps, FRIA scope

Fix the provider or deployer role per system (flagging every Article 25 shift risk), run the gap analysis method against the Articles 8–15 stack and the Article 26 list, and complete the Article 27 scope check — commissioning a FRIA only where it returns yes.

Days 61–90 — roadmap, evidence, owner

Convert the gap list into a dated remediation roadmap with every milestone landing before 2 December 2027; stand up the evidence base (Annex IV documentation, automatic logging, named human-oversight assignments, six-month log retention); and appoint a named compliance owner with board visibility.