High-Risk AI Systems Under the EU AI Act: A Classification Guide

Most of the work to comply with the EU AI Act hinges on a single decision: is your AI system high-risk or not? The answer determines whether you face documentation obligations measured in person-weeks or person-months. It determines whether your product needs a CE mark before going to market. It determines which fines apply when something goes wrong.

The classification rules are written in formal legal prose. They are not impenetrable, but they are precise. A casual reading of "we're not high-risk because we don't do biometrics" misses how the Annex III categories actually work. A surprising number of companies that assume they're out of scope are actually in scope.

This post is the practical classification guide. The two paths to high-risk. The eight Annex III domains in plain English. The escape valve that everyone wants to invoke and few actually qualify for. The edge cases that will get tested in court.

The Two Paths to High-Risk

There are only two ways to be classified as high-risk under the AI Act. Both are worth understanding because they catch different categories of system.

Annex I — AI as a safety component of regulated products. If your AI is built into a product that already requires CE marking under existing EU product safety law — medical devices, in-vitro diagnostics, machinery, toys, lifts, equipment for explosive atmospheres, radio equipment, pressure equipment, recreational craft, cableway installations, gas appliances, motor vehicles, agricultural vehicles, marine equipment, civil aviation — the AI Act stacks on top of those existing rules.

Annex I is straightforward in principle. If your product is already in a CE-regulated category, the AI Act gives you additional AI-specific obligations on top of what you already do. The hard cases are at the edges: is this software a "safety component" of a medical device, or just adjacent to one? Existing case law on the regulated products often answers the question.

Annex III — AI used in one of eight high-stakes domains. This is the path that catches most companies by surprise. Annex III lists eight specific domains where AI use is inherently high-risk regardless of which product the AI is inside. If your AI is used for one of these purposes — even if it's a standalone software product — it's high-risk.

Most production AI in B2B SaaS, in HR tools, in fintech, in education tech, in govtech, in insurance, in any kind of decisioning workflow ends up touching at least one Annex III category. The question for most companies is not "are we high-risk?" but "which Annex III category applies, and how broadly?"

The Eight Annex III Domains in Plain English

The legal text uses careful, narrow language. Here's what each category actually catches.

1. Biometric identification and categorization. AI that identifies a person from biometric data (face recognition, voice ID, gait recognition) or categorizes people by sensitive biometric attributes (emotion, race, political view inferred from biometrics). This covers face-unlock features when used for identification, voice authentication for support hotlines, behavioral biometrics for fraud detection, and any system that infers demographic attributes from images or audio.

2. Critical infrastructure. AI used as a safety component in the management of road traffic, water supply, gas, heating, electricity, and digital infrastructure. The "safety component" qualifier matters — accounting software for an electric utility is not high-risk; AI that controls grid frequency is. Note that the digital infrastructure inclusion is broad: AI managing the operation of large-scale cloud or telecom infrastructure can qualify.

3. Education and vocational training. AI used for admissions decisions, evaluating learning outcomes, assigning students to programs, or monitoring prohibited behavior during exams. This catches: admissions algorithms, automated grading, plagiarism detection that affects academic outcomes, proctoring software, adaptive learning systems that influence student placement.

4. Employment, worker management, and access to self-employment. AI used for recruitment, screening, evaluation of candidates, decisions affecting work terms, task allocation, and monitoring/evaluation of workers. This is the big one for HR tech. Resume screeners, video interview analyzers, performance review tools, productivity monitoring, task assignment algorithms — almost all are high-risk if used in EU markets. Even AI that just "ranks" candidates for human review qualifies if the ranking substantially influences the outcome.

5. Access to essential private and public services and benefits. AI used to evaluate eligibility for public assistance, credit scoring (with narrow exceptions for fraud detection), insurance pricing for life and health insurance, dispatching emergency services. This catches: most fintech credit decisions, insurtech pricing models, social benefit algorithms, AI-driven triage in healthcare. The phrase "essential services" is interpreted broadly.

6. Law enforcement. AI used for risk assessment of individuals, polygraph-like tools, deep fake detection in evidence, evaluation of reliability of evidence, predictive policing, profiling. The list explicitly limits this to law enforcement use; the same AI sold to a private security firm is not automatically high-risk under this category (though it may catch on biometrics or employment categories).

7. Migration, asylum, and border control. AI used for risk assessment, polygraph-like tools, evaluation of applications, monitoring/surveillance of border crossings. Specific to government deployment in these areas.

8. Administration of justice and democratic processes. AI used to assist judicial decisions, in alternative dispute resolution affecting parties' legal rights, or to influence elections/voting behavior at scale. The election-influence inclusion is broad and probably catches large social media recommendation systems that affect political content — though the exact scope will be tested.

The Escape Valve

Article 6(3) of the AI Act creates an exemption from high-risk classification even if your system falls in an Annex III domain. The exemption applies when the system:

• (a) performs a narrow procedural task; or

• (b) is intended to improve the result of a previously completed human activity; or

• (c) is intended to detect decision-making patterns or deviations from prior decision-making patterns without replacing or influencing the human assessment; or

• (d) is intended to perform a preparatory task to an assessment relevant to the use cases listed in Annex III.

This sounds generous and isn't. The Commission has indicated, and early enforcement guidance has confirmed, that these exemptions are meant to be narrow. They are designed to exclude AI that, for instance, formats a job applicant's resume into a standardized layout (narrow procedural), or AI that spell-checks a judge's written opinion (improves prior human activity), not AI that substantively contributes to the decision.

In practice, four signals that the exemption probably does NOT apply:

1. The AI's output is read by humans who use it to make decisions affecting the people involved.

2. The AI's output materially changes the outcome distribution compared to not using the AI.

3. The AI is marketed as improving decision quality or speed.

4. The AI is described as "assisting" decision-making in any non-trivial way.

If any of those are true for your system, you should plan to be high-risk and treat the exemption as a fallback argument, not as your primary classification.

Worked Examples

Abstract definitions help less than concrete examples. Here's how the classification applies to common AI products in the European market.

A resume screener that ranks candidates for a recruiter to review. High-risk. Annex III category 4 (employment). The "rank for human review" framing does not save you — the ranking substantially influences which candidates the recruiter actually evaluates, which is "substantial influence" on the decision.

An AI assistant that helps a doctor draft visit notes. Depends on what the notes are used for. If notes go into the patient record and are used for billing/diagnosis, the AI is interacting with a regulated product (electronic health records, often a Class IIa medical device in the EU). Probably high-risk via Annex I.

A fraud detection model for a bank. Generally NOT high-risk. The credit scoring category in Annex III has an explicit carve-out for "AI systems put into service or used for the purpose of detecting financial fraud." This is one of the cleaner exclusions.

A customer support chatbot that answers product questions. Generally NOT high-risk — but check the boundary. If the chatbot makes decisions about returns, refunds, or eligibility for services, you've slid into Annex III category 5 (essential services) territory.

A document classifier that routes legal documents to the right reviewer. Probably NOT high-risk under the narrow procedural exemption — if it's literally just routing. If it also flags risk levels or extracts critical terms that influence the legal review, the exemption is harder to claim.

An AI tutor that adapts lessons based on student performance. Probably high-risk. Annex III category 3 (education) covers AI that "evaluates learning outcomes." Adaptive lesson assignment based on performance evaluation substantially influences educational outcomes.

Algorithmic management tools for gig workers (route optimization, task scoring). High-risk. Annex III category 4 covers AI used to "monitor and evaluate work" and to make decisions about task allocation. Even if the worker is technically self-employed, the AI Act treats these systems as high-risk.

A coding copilot that suggests code completions. Generally NOT high-risk. None of the Annex III categories apply to general-purpose software development tools.

A code review tool that decides whether to merge a pull request automatically. Depends on what's being deployed. For internal engineering tools, generally not high-risk. For tools deployed into safety-critical software (medical devices, automotive systems), Annex I considerations apply.

What Classification Triggers

If you classify as high-risk, the obligations are:

• Risk management system maintained throughout the AI lifecycle

• Data governance ensuring training data is relevant, representative, and free of errors

• Technical documentation sufficient for regulators to assess compliance

• Record-keeping of system events sufficient for traceability

• Transparency to deployers — clear instructions for safe use

• Human oversight measures built into the system design

• Accuracy, robustness, and cybersecurity appropriate to the use case

• Quality management system for providers

• Conformity assessment before placing on the market

• CE marking and registration in an EU database

• Post-market monitoring with incident reporting

Each of these is a real project. Together, they are typically a 3-9 month effort for a single system, depending on complexity. Plan budget accordingly. Don't assume your existing security/compliance posture covers the AI-specific obligations — it generally doesn't.

How to Classify Operationally

The practical classification process:

1. List every AI system you build or deploy. Be inclusive — include third-party AI features inside your products, AI inside SaaS you've integrated, internal AI tools your operations team uses.

2. For each system, identify which Annex III categories might apply. Multiple categories can apply to one system. Be thorough.

3. For each candidate Annex III category, document why it applies. What domain does the AI operate in? What decisions does it influence? Who is affected?

4. For each high-risk candidate, evaluate the Article 6(3) exemption. Walk through the four exemption clauses. Document why each does or does not apply. Be honest — this document will be reviewed by regulators if you're audited.

5. Get legal review on borderline cases. Pay for an AI-specific lawyer's opinion. The 2-4 hour consultation that confirms or rejects your analysis is dramatically cheaper than a regulatory fine.

6. Publish the classification internally. Make it findable. Engineering needs to know which systems are high-risk because the code, documentation, and operational requirements change.

7. Re-evaluate when systems change. A scope expansion can flip a low-risk system into high-risk. A pruning of features can flip the other way. Classification is not a one-time exercise.

What Happens If You Get It Wrong

The downside of mis-classifying as low-risk when you're actually high-risk is significant: enforcement actions, fines up to 3% of global revenue, and the requirement to either bring the system into compliance or withdraw it from the EU market. The reputational damage of being publicly cited for non-compliance is harder to quantify but real.

The downside of over-classifying as high-risk when you didn't need to is documentation work and operational overhead. You did the compliance work you didn't need to do. Annoying but recoverable.

The asymmetry is clear. When in doubt, classify as high-risk. The exemption can be applied later if your analysis matures; the compliance work can't be retroactively done if regulators come knocking.

The Takeaway

The classification step is where most companies make their biggest AI Act mistake. They read "high-risk" and think "we're not biometric ID, we're fine." That misreads the Annex III categories, which catch a much wider set of common AI use cases — especially in HR tech, fintech, insurtech, education, and any decisioning workflow involving access to services.

Most of the work of complying with the AI Act starts with knowing which of your systems are in scope. Spend the time on classification carefully. Document the reasoning. Get legal review on edge cases. Treat borderline as high-risk. Build the compliance stack for the systems that need it.

The cost of careful classification is small. The cost of getting it wrong is large.

Frequently Asked Questions

What makes an AI system 'high-risk' under the EU AI Act?

An AI system is high-risk if it is either a safety component of a regulated product (Annex I — medical devices, machinery, automotive, etc.) or it is used in one of eight specific domains listed in Annex III (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice). Most production AI in any of those domains qualifies as high-risk unless a narrow exemption applies.

What are the eight Annex III high-risk domains?

Biometric identification and categorization; management of critical infrastructure (water, gas, electricity, transport, digital); education and vocational training; employment and worker management; access to essential private and public services (credit, insurance, benefits); law enforcement; migration, asylum, and border control; administration of justice and democratic processes. If your AI substantially affects decisions in any of these areas, you are high-risk by default.

What's the 'narrow procedural task' exemption?

Annex III lists a four-part escape valve: a system in a high-risk domain is NOT high-risk if it (1) performs a narrow procedural task, (2) improves the result of a previously completed human activity, (3) does not substantially influence the decision, or (4) is preparatory only. The exemption is meant to exclude AI that proofreads a cover letter from being classified as a hiring system. It is narrow. Most production AI in high-risk domains does not qualify.

Who decides if my AI is high-risk?

You do, in the first instance — you self-classify, document your reasoning, and conduct a conformity assessment. National regulators audit your classification and can challenge it. Courts ultimately resolve disputes. The risk of mis-classifying yourself as low-risk is significant: you face the high-risk fines (3% of global turnover) plus the embarrassment of having argued the wrong position publicly. Get legal review on edge cases before publishing your classification.

What if I think my AI is borderline?

Treat borderline as high-risk. The cost of complying as high-risk when you didn't need to is documentation work. The cost of not complying and being wrong is fines, market withdrawal, and reputational damage. For systems in any Annex III domain that do anything meaningful with their outputs, the safer answer is to comply. Reserve the exemption argument for systems that are genuinely peripheral — and document the analysis carefully.