Module 4: EU AI Act Deep Dive

3. High-Risk AI: Categories and Criteria

Capsule description

The High-Risk category is the largest one and the one most likely to apply to your system. If your AI affects access to employment, education, essential services, justice, or safety, you're here.

High-Risk doesn't mean prohibited — it means strict obligations (capsule 04 details them). It's the line between "you can deploy with substantial compliance work" and "you can't deploy at all" (unacceptable risk).

This capsule covers:

Annex III: the EU AI Act's 8 high-risk areas.
Annex I: products with AI safety components.
Exceptions: when a system in a high-risk area is NOT high-risk.
Borderline cases: common gray areas.

By the end, you'll be able to identify precisely whether your system is high-risk.

Annex III: The 8 High-Risk areas

Area 1: Biometric identification and categorization

Systems for:

Remote biometric identification (not real-time public — that's prohibited).
Categorization based on biometric data.
Emotion recognition (where not prohibited).

Examples:

Biometric identification systems for building access.
Categorization based on biometric features for marketing.
Emotion recognition in consumer apps (medical, safety contexts).

Critical: real-time public biometric ID is prohibited (capsule 02). Other biometric cases are high-risk.

Area 2: Critical infrastructure

Systems that serve as safety components in the management of:

Road traffic.
Water, gas, heating, and electricity supply.
Critical digital infrastructure.

Examples:

AI controlling traffic light systems.
Predictive maintenance for a power grid.
Autonomous decision-making in water treatment.

Critical: the system must be a safety component (its failure causes a safety hazard), not just any AI in those sectors.

Area 3: Education and vocational training

Systems used to:

Determine access to educational/vocational institutions.
Evaluate learning outcomes or score exams.
Assess the appropriate level of education.
Monitor and detect prohibited behavior during tests.

Examples:

AI grading exams or admissions essays.
An algorithm matching students to programs.
AI-proctoring software during online exams.
A predictive system identifying students at risk of dropping out (sometimes).

Area 4: Employment, worker management, and self-employment

Systems for:

Recruitment: targeted job advertising, screening applications, evaluating candidates.
Promotion and termination decisions.
Allocating tasks based on individual behavior or personal traits.
Monitoring and evaluating the performance of workers.

Examples:

CV screening AI.
Performance evaluation algorithms.
Schedule optimization that considers individual workers.
AI generating performance reviews.

Note: almost any HR-tech with AI lands here.

Area 5: Essential private and public services

Systems to:

Determine eligibility for public benefits and services.
Evaluate creditworthiness or establish credit scores.
Risk assessment for life and health insurance.
Establish the priority of dispatch for emergency services.

Examples:

Welfare/benefits eligibility decisions.
Loan approval algorithms.
Insurance underwriting with AI.
Emergency services triage AI.

Note: financial services + insurance + government services with AI are heavily covered here.

Area 6: Law enforcement

Systems used by authorities to:

Risk assessment of natural persons (potential victim, recidivism risk).
Polygraphs and similar tools (lie detection).
Evaluate the reliability of evidence.
Profile natural persons (acceptable within a limited scope).
Crime analytics (identifying patterns across cases).

Critical: profiling alone is unacceptable (capsule 02). Combined with human review it can be high-risk.

Area 7: Migration, asylum, and border control

Systems for:

Polygraphs and similar tools in an immigration context.
Risk assessment of natural persons in migration contexts.
Examining applications for asylum, visas, residence permits.

Examples:

AI assessing visa applications.
Risk scoring at border control.
Asylum claim evaluation algorithms.

Area 8: Administration of justice and democratic processes

Systems to:

Assist a judicial authority in researching and interpreting facts and the law.
Assist a judicial authority in applying the law to the facts.
Influence the outcome of elections or referenda, or voting behavior.

Examples:

AI legal research tools used by courts.
Sentencing recommendation systems.
Algorithms used for political ad targeting (with caveats).

Annex I: Products with AI safety components

In addition to Annex III, Annex I lists products already regulated under EU product safety legislation, where adding an AI safety component triggers high-risk classification.

Examples:

Medical devices (Regulation (EU) 2017/745).
In vitro diagnostic medical devices (Regulation (EU) 2017/746).
Toys with AI (Directive 2009/48/EC).
Civil aviation security.
Vehicles (some categories).
Industrial machinery.
Pressure equipment.
Lifts.

If your AI is a safety component in any of these products, the classification is automatically high-risk, regardless of Annex III.

When a system in a high-risk area is NOT high-risk

An important exception: Art. 6(3) provides exceptions. A system may NOT be high-risk if it:

Performs a narrow procedural task.
Improves the result of a previously completed human activity (it just enhances, doesn't decide).
Detects decision-making patterns without intending to influence them (analysis only, no replacement).
Performs a preparatory task for an assessment (preparation, not the assessment itself).

Practical examples:

A spell-checker in an education context: it detects spelling errors. A narrow task. NOT high-risk.
A résumé formatter (formats CVs into a standard layout): preparation, not evaluation. NOT high-risk.
Sentiment analysis for a customer service prioritization queue: prioritization only, no decisions about people. Borderline.
Automated email classification for an HR department: it categorizes incoming email. A narrow task. NOT high-risk.

The test for the exception:

Is the AI making decisions about people, or just preparing/organizing data?
Does the AI's output directly affect outcomes for individuals, or is a human still the decision-maker?

If decisions about people are made by humans based on the AI's output, the exception may apply. If the AI itself is decisive, the exception doesn't apply.

Critical: claiming the exception requires a risk assessment + documentation. You can't just assume it; you have to demonstrate it.

Common borderline cases

Borderline 1: Recommendation engines

Recommending products on Amazon: NOT high-risk (no impact on essential services).

Recommending mortgages on a financial site: borderline. If the recommendation is purely informational, NOT high-risk. If the recommendation directly leads to approval/denial, high-risk.

Borderline 2: Customer support chatbots

A general customer support chatbot: typically NOT high-risk.

A chatbot for medical advice: high-risk (it impacts health).

A chatbot for legal advice: high-risk (administration of justice context).

Borderline 3: Educational AI

An AI tutor providing explanations: typically NOT high-risk.

AI grading homework or exams: high-risk.

AI deciding course placement: high-risk.

Borderline 4: HR systems

AI scheduling shifts based on worker preferences: borderline. If it's just optimizing the schedule = lower risk. If it's allocating tasks based on individual traits = high-risk.

AI for résumé parsing (extracting info): borderline. If it's just extracting structured info from a CV = lower risk. If it's scoring candidates = high-risk.

The resolution approach

For borderline cases:

Conservative default: classify as high-risk.
Document the interpretation: argue why the exception applies.
Consult legal: high-stakes systems need legal review.
Implement the high-risk obligations regardless: a prudent defense.

Why the classification matters

If your system is high-risk, you have:

6 obligations (capsule 04).
A conformity assessment before deploy.
Registration in the EU database.
Human oversight requirements.
Extensive documentation.
Post-market monitoring.

Effort estimate: months of work + an ongoing operations cost.

If you wrongly classify as NOT high-risk and the regulator disagrees:

Penalties up to €15M or 3% of revenue.
Forced compliance retroactively.
Reputational damage.

If you wrongly classify as high-risk when you're actually minimal:

Unnecessary compliance cost.
Slower time-to-market.
A competitive disadvantage.

Get the classification right.

Common traps

1. "It's just an LLM, not high-risk"

The use case determines the classification, not the technology. An LLM used for hiring decisions is high-risk regardless of the fact that it's an LLM.

2. Assuming small-scale = not regulated

Scale doesn't matter for the classification. A high-risk AI used for 100 people is still high-risk.

3. Treating "support tool" too loosely

If your "support tool" is decisive in practice (humans rubber-stamp it), it's effectively the decision-maker = high-risk.

4. Ignoring Annex I products

Many engineers focus on Annex III. But Annex I covers many physical products with AI. Check both.

5. Not re-evaluating when features change

A system might NOT be high-risk today. Adding feature X changes the classification. Re-evaluate when the scope changes.

Self-check

1. How do you distinguish a "high-risk" system from one with the Art. 6(3) "exception"?

A concrete test: is the AI itself making decisions about people?

If YES → high-risk.

If NO (the AI prepares data, formats info, performs a narrow procedural task, assists but a human decides) → the exception potentially applies.

Examples:

A CV scoring algorithm: the AI evaluates candidates → high-risk.
A CV formatter: the AI organizes data into a standard layout, the recruiter evaluates → the exception applies.
A loan approval algorithm: the AI decides approve/deny → high-risk.
Loan application data extraction: the AI pulls info from forms, a human officer decides → the exception may apply.

Critical: claiming the exception requires:

Documenting that the AI doesn't make the decision.
Demonstrating that humans actually exercise judgment (not rubber-stamp it).
A risk assessment showing genuinely lower risk.

If humans rubber-stamp the AI's output, you don't have an exception — you have a high-risk system de facto.

2. What's the difference between Annex I and Annex III high-risk?

Annex III: AI systems used in specific sectors (employment, education, etc.). Classification based on the use case.

Annex I: physical products already regulated under EU safety legislation (medical devices, toys, vehicles, etc.). The classification triggers when the AI is a safety component of those products.

Implication:

Annex III: you classify your system by what it does (does it make hiring decisions? credit decisions?).
Annex I: you classify your system by the product it's in (is it a safety component of a medical device?).

Both can apply to one system:

An AI for medical diagnosis: Annex III (essential service — health) + Annex I (medical device).

Both trigger high-risk classification independently.

Practical: check both Annex I and Annex III when classifying. Many engineers only check Annex III.

3. Why doesn't "small scale" exempt you from high-risk classification?

EU AI Act classification depends on the type of risk, not on scale.

If your AI:

Decides who gets a loan, at a scale of 100 people/year → still high-risk.
Decides who gets hired, at 50/year → still high-risk.
Helps make medical diagnoses for one clinic → still high-risk.

The reason: risk per individual doesn't scale down with volume. One person wrongly denied a loan is still harmed.

What scale does affect:

The probability of regulator scrutiny: larger impacts are more likely to be investigated.
Compliance cost: scaling compliance takes more resources.
Penalty severity: percentage-of-revenue penalties hurt large companies more.

But the classification itself is independent of scale. Don't think "we're small, the regulation doesn't apply."

4. What do you do with a system in the gray area between high-risk and minimal?

The conservative procedure:

Default to high-risk: assume the more restrictive classification.
Document your interpretation: why the exception might apply, and the alternative interpretations.
Implement the high-risk obligations: even if you believe the exception applies, implement the obligations:
- It reduces real risk.
- It demonstrates due diligence to the regulator.
- It future-proofs you against the regulation tightening.
Consult legal: for significant systems, get a formal opinion.
Engage with the regulator: the AI Office accepts queries. Regulatory sandbox programs may be available for clarification.
Re-evaluate periodically: regulator guidance will clarify things over time.

What NOT to do:

Assume the most permissive interpretation.
Skip compliance hoping the regulator won't notice.
Wait for enforcement to clarify it.

GDPR taught us: regulators investigate. Better to comply proactively.

Summary and next step

High-Risk is the largest category.
Annex III: 8 areas — biometrics, infrastructure, education, employment, essential services, law enforcement, migration, justice.
Annex I: products with safety components.
The exception (Art. 6(3)): narrow procedural tasks, preparatory tasks, etc.
Borderline cases: default conservative + document + legal review.
Classification matters: 6 obligations vs. minimal = months of work difference.

Checkpoint: you should be able to classify any AI system with confidence into high-risk vs. not.

Bridge to the next capsule: capsule 04 covers the 6 obligations of High-Risk: governance, data quality, technical documentation, human oversight, accuracy/robustness/cybersecurity, registration. It translates them from legal language into engineering action.

Resources

EU AI Act Art. 6 — Classification of high-risk AI — the text.
Annex III — Specific high-risk areas — the list.
Annex I — Products list — the list.

Next: 04-high-risk-obligations.md — The 6 obligations.

Capsule 03 of 08 — Module 4 — AI Ethics & Compliance Guide

← Previous2. Unacceptable Risk: Prohibited Systems Next →4. High-Risk Obligations: The 6 Requirements