Table of Contents
⚡ TL;DR — Read This First:
- The EU AI Act creates four risk tiers: Unacceptable, High-Risk, Limited Risk, and Minimal Risk.
- Annex III lists eight specific categories of high-risk AI — if your system falls into any of them, significant compliance obligations apply immediately.
- Misclassifying your system — either too conservatively or too liberally — carries real legal and commercial risk. This guide helps you get the classification right.
The question I get more than any other from product managers and legal teams is this: “Does the EU AI Act actually apply to us?” More often than not, the honest answer is: probably yes, but let’s check carefully.
The AI Act’s risk classification system sounds straightforward in summary form. In practice, applying it to a real product — with all its edge cases, integrations, and evolving use cases — is one of the more nuanced exercises in modern compliance. Getting it wrong in either direction is expensive: under-classify and you face enforcement exposure; over-classify and you spend months building compliance infrastructure you didn’t need.
This guide walks through the Annex III categories with concrete examples, the grey zones regulators are actively debating, and the process for documenting your classification decision. For the full regulatory context, see our Ultimate Guide to EU AI Act Compliance (2026 Edition).
The Four-Tier Risk Framework: A Quick Map
Before diving into Annex III specifically, it helps to understand where “high-risk” sits within the Act’s broader structure.
| Risk Tier | Definition | Regulatory Response | Examples |
|---|---|---|---|
| Unacceptable Risk | Poses a clear threat to safety or fundamental rights | Completely prohibited | Social scoring by governments, real-time biometric surveillance in public |
| High Risk (Annex II + III) | Significant potential harm to health, safety, or fundamental rights | Full compliance obligations (Articles 8–15) | CV screening tools, credit scoring AI, medical device software |
| Limited Risk | Poses specific, manageable transparency risks | Transparency obligations only (Article 50) | Chatbots, deepfake tools, emotion recognition |
| Minimal Risk | Negligible harm potential | No specific obligations (voluntary codes encouraged) | Spam filters, basic recommendation systems, AI in video games |
The official EU AI Act text, including the full Annex III list, is available on EUR-Lex. For sector-specific guidance as it’s published, monitor the European Commission’s AI policy hub.
Breaking Down the Eight Annex III High-Risk Categories
Annex III lists eight categories of high-risk AI systems. I’ll take each in turn — including the specific product types that fall in, and the edge cases where classification isn’t obvious.
Category 1: Biometric Identification and Categorisation
This covers AI systems used to identify individuals using biometric data — including facial recognition, gait analysis, voice recognition for identification purposes, and emotion recognition used in security contexts.
Clearly in scope: Facial recognition systems for employee time-tracking; automated identity verification in onboarding flows; systems that infer emotional state for security screening.
Grey zone: Face-matching tools used purely for device unlock (not identification of individuals in a database) have been debated. The current consensus among legal advisors is that a device unlock function is likely out of scope, but any system that matches a face against a database of known individuals — even a small internal one — falls within Annex III.
Category 2: Management and Operation of Critical Infrastructure
AI used in the safety components of critical infrastructure — energy grids, water management, transportation, financial systems — is high-risk by definition.
Clearly in scope: Predictive maintenance systems for power plant equipment; AI-driven load balancing in electricity distribution; automated trading systems that can affect market stability.
Grey zone: A general-purpose analytics tool that happens to be used by a utility company sits in an ambiguous position. The key question is whether the AI output directly informs a safety-critical operational decision. If yes — even indirectly — you’re in scope.
Category 3: Education and Vocational Training
AI systems used to determine access to, or make decisions about, educational outcomes are high-risk. This includes automated grading systems, student scoring tools, and AI that determines who gets access to educational resources.
Clearly in scope: AI-powered exam proctoring tools that flag suspected cheating; automated grading systems that assign academic scores; student risk-prediction models used to identify dropout candidates.
Grey zone: Personalised learning tools that adapt content without making access or outcome decisions occupy a lower-risk position. But the moment your system outputs a score, a recommendation about a student’s academic future, or a decision about access — you’re in Annex III.
Category 4: Employment, Worker Management, and Access to Self-Employment
This is the category that catches the most SaaS companies by surprise. Any AI system that meaningfully influences hiring, promotion, task allocation, or performance assessment falls here.
Clearly in scope: CV screening tools that rank or filter candidates; interview assessment AI (including video-based personality scoring); performance management tools that generate individual worker scores; task allocation systems in logistics platforms.
Grey zone: An AI tool that summarises CVs for a human recruiter — without ranking or scoring — is in a more defensible position. But if the summarisation systematically influences selection (e.g., by highlighting certain attributes over others), the argument that it’s not making a consequential decision starts to weaken. When in doubt, treat it as high-risk and document why.
For SaaS founders specifically, our post on how to bake EU AI Act compliance into your product from day one addresses this category in depth.
Category 5: Access to Essential Private and Public Services
AI used in decisions about access to credit, insurance, social benefits, housing, or emergency services falls in this category. This is where financial services firms and insurers have the most exposure.
Clearly in scope: Automated credit scoring systems; AI underwriting tools for insurance; social benefit eligibility assessments; automated loan approval or rejection systems.
Grey zone: AI tools used to detect fraud (rather than make credit decisions) occupy a contested space. Regulators are converging on the view that if the fraud detection output directly triggers a service denial or account restriction, it’s in scope.
Category 6: Law Enforcement
AI systems used by law enforcement to assess risk of individuals, analyse crime patterns, or identify individuals using biometric data are high-risk. This category is largely relevant to government and public sector operators rather than commercial software companies.
Category 7: Migration, Asylum, and Border Control Management
AI used in visa assessment, asylum case processing, or border risk profiling falls here. Again, primarily relevant to government systems and specialist legal technology providers.
Category 8: Administration of Justice and Democratic Processes
AI systems used to assist courts in making decisions, or AI used in the context of elections and democratic processes, are high-risk. Legal research AI that produces case outcome predictions — if those predictions directly inform judicial decision-making — may fall here.
The Classification Decision: How to Document It
Regardless of where your system lands, documenting your classification decision is essential. A well-structured classification memo should record:
- The system’s primary purpose and the specific task the AI performs
- The decision-making context — does the AI output directly influence a consequential decision about a person?
- Which Annex III categories were considered and the reasoning for inclusion or exclusion
- Whether GPAI models are incorporated and what obligations that creates
- The date of the assessment and the names of the people who made it
- A trigger for reassessment — what system changes would require this classification to be revisited
This document becomes part of your Technical File under Article 11. For guidance on building the full Technical File, see our pillar guide on Article 11 and Annex IV. For teams needing to maintain this as a living record, Unorma’s AI System Inventory feature stores classification decisions alongside all other compliance records in one auditable location.
The “Not High-Risk” Exemption in Article 6(3)
Even if your system falls into an Annex III category, Article 6(3) provides a limited exemption. A system is not high-risk if it meets all three of these conditions:
- It is intended to perform a narrow procedural task
- It is intended to improve the result of a previously completed human activity
- It is intended to detect decision-making patterns but is not used to replace or influence human decisions
In practice, this exemption is narrower than it sounds. If a client or regulator can argue that your system’s output influenced a consequential decision — even if you describe it as “just a tool” — the exemption is unlikely to hold. Treat it as a fallback argument, not a primary classification strategy.
What to Do If You’re High-Risk
If your analysis confirms you’re operating a high-risk AI system, the next step is a structured compliance gap analysis against Articles 8 through 15. Our 6-Month EU AI Act Readiness Checklist gives you the exact phase-by-phase roadmap to get there.
Frequently Asked Questions
What makes an AI system “high-risk” under the EU AI Act?
Under Article 6, a system is high-risk if it falls into one of two tracks: (1) it is a safety component of a product covered by existing EU product safety legislation (Annex II), or (2) it independently falls within one of the eight categories listed in Annex III. The defining thread in Annex III is that the AI’s output materially influences consequential decisions about individuals — in employment, education, credit, or safety contexts.
Can the same AI model be high-risk in one application and minimal-risk in another?
Yes, absolutely. Risk classification is determined by use case and deployment context, not by the underlying model itself. A large language model used to summarise internal documents is likely minimal-risk. The same model integrated into a hiring tool that ranks candidates is high-risk under Annex III Category 4. This is a critical reason why every deployment of an AI system needs its own classification assessment.
We use a third-party AI API in our product. Are we a “provider” or a “deployer”?
If you integrate a third-party model into your product and make it available to end users as part of your commercial offering, you are almost certainly a provider under the Act — even though you didn’t build the underlying model. You are responsible for ensuring the integrated system meets Annex III obligations. The third-party model provider has separate obligations under GPAI rules. See our post on using third-party LLMs and your obligations as a deployer for more detail.
Is there a formal process for registering a classification decision with the EU?
Not for the classification decision itself — that’s an internal process. However, if your system is confirmed as high-risk, you must register it in the EU AI Act database under Article 71 before placing it on the market. The classification assessment feeds into the Technical File, which underpins that registration.
How often do we need to reassess our AI system’s risk classification?
The regulation requires a reassessment whenever the system undergoes a “substantial modification” — which includes changes to the training dataset, significant updates to the model architecture, or an expansion into new use cases. A practical rule of thumb: add a classification review trigger to your product change management process, and conduct a formal review at least annually even if no major changes have occurred.
What if two of our systems together create a high-risk outcome, but neither does individually?
This is an emerging issue regulators are actively addressing. The current position is that system-level risk — where individual components combine to produce a high-risk outcome — can trigger Annex III obligations. If your system architecture deliberately combines outputs to make consequential decisions about individuals, document the combined functionality carefully and seek legal advice on classification.
Not sure if your AI system is high-risk?
Unorma’s AI System Inventory includes a guided classification workflow that maps your system against every Annex III category and produces a documented classification memo — ready to include in your Technical File.Start Your Classification Assessment →
Jasper Claes is a Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets. He advises product and legal teams on implementing practical compliance frameworks aligned with evolving regulations such as the EU AI Act. Through his writing, Jasper focuses on translating complex regulatory requirements into clear, actionable guidance for teams building and deploying AI systems.