AI Act Annex III Explained: 8 Categories That Make Your AI High-Risk
Annex III of the EU AI Act is the single most important piece of text for any company trying to figure out whether its AI system is high-risk. It's a list of 8 categories, each describing use cases where AI systems are presumed to carry significant risk to people's health, safety, or fundamental rights.
If your AI system falls into one of these categories, you face the full weight of the high-risk compliance framework: risk management, technical documentation, conformity assessment, EU database registration, and ongoing monitoring.
This article walks you through every category with practical examples, explains what commonly gets misclassified, and shows you exactly how the Article 6(3) exceptions work.
How Annex III Classification Works
The classification process under Article 6(2) is straightforward in principle: if an AI system is intended to be used in any of the areas listed in Annex III, it is classified as high-risk.
The key word is intended use. It's not about what the system theoretically could do — it's about how you market, design, and deploy it. A general-purpose NLP model isn't automatically high-risk, but the same model integrated into a hiring tool becomes high-risk because of its intended deployment context.
Let's go through each category.
Category 1: Biometrics (§1)
This category covers three types of AI systems.
1a. Remote biometric identification systems. These identify natural persons at a distance by comparing their biometric data (face, gait, voice) against a reference database. This explicitly excludes AI systems used for biometric verification (one-to-one matching to confirm a person is who they claim to be) — that's considered lower risk when the person initiates and consents to the process.
Real-world examples: Surveillance cameras with facial recognition in retail stores, airport passenger identification systems, tools that scan crowds to find specific individuals.
1b. Biometric categorization systems. These assign people to specific categories based on biometric data, where those categories involve sensitive attributes — race, political opinions, trade union membership, religious beliefs, sex life, or sexual orientation.
Real-world examples: A system that infers ethnicity from facial features, a tool that categorizes people by gender expression from video feeds, software that attempts to predict political leanings from physical characteristics.
1c. Emotion recognition systems. These infer emotions from biometric data such as facial expressions, voice tone, body language, or physiological signals. Note that since February 2025, emotion recognition in workplaces and educational institutions is outright prohibited under Article 5, with very narrow exceptions for medical or safety reasons.
Real-world examples: Customer service platforms that detect caller frustration from voice analysis, market research tools that analyze facial reactions to advertisements, employee sentiment analysis from video calls.
What's NOT in this category: Standard facial recognition for device unlock (one-to-one verification, not remote identification), photo beauty filters, basic age gate tools that don't categorize by sensitive attributes, sentiment analysis of text (this analyzes language, not biometric data).
Category 2: Critical Infrastructure (§2)
AI systems that serve as safety components of the management and operation of critical infrastructure fall here. This covers digital infrastructure, road traffic, water supply, gas supply, heating supply, and electricity supply.
The crucial qualifier is "safety component." The AI system must directly affect the safe operation of infrastructure. An analytics dashboard that shows historical data isn't a safety component. An AI system that automatically adjusts power grid loads to prevent blackouts is.
Real-world examples: AI-driven electricity load balancing and grid management, automated traffic signal optimization systems, predictive maintenance tools for water treatment plants where failure could cause contamination, AI systems managing gas pipeline pressure.
What's NOT in this category: IT infrastructure monitoring (servers, cloud services) unless it manages physical critical infrastructure, general business analytics for utility companies, customer service chatbots at an energy company, smart home thermostats (they control comfort, not infrastructure safety).
Category 3: Education & Vocational Training (§3)
This category targets AI systems that influence access to education, evaluation of learning, or academic progression.
3a. Determining access to or admission. AI that decides who gets into an educational or vocational institution, or that substantially influences admission decisions.
3b. Evaluating learning outcomes. AI that assesses or scores student performance, including determining whether outcomes meet required standards.
3c. Assessing appropriate education level. AI that determines what level of education a person should receive, including curriculum placement and tracking decisions.
3d. Monitoring prohibited behavior during tests. AI proctoring systems that watch for cheating during exams.
Real-world examples: University admissions systems that screen and rank applicants using AI, automated essay-grading platforms used for formal academic assessment, adaptive learning platforms that permanently assign students to academic tracks, AI-powered exam proctoring that detects suspicious behavior.
What's NOT in this category: Learning management systems that simply deliver content without making placement decisions, quiz apps where results don't affect formal qualifications, language learning apps (Duolingo-style) where assessment is informal and self-directed, plagiarism detection tools that flag content for human review without making the academic decision themselves (this could qualify for an Article 6(3) exception).
Category 4: Employment & Worker Management (§4)
This is the broadest and most commonly triggered category for SaaS companies. It has six subcategories covering the full employment lifecycle.
4a. Recruitment and candidate sourcing. AI that publishes targeted job advertisements, screens applications, or filters candidates.
4b. Decision-making in recruitment. AI used to evaluate, interview, assess, or select candidates for hiring.
4c. Decisions about employment relationships. AI used for promotion decisions, termination decisions, task allocation based on individual behavior or personality traits, and decisions about employment contract terms.
4d. Monitoring and evaluating performance. AI used to monitor work performance, evaluate employees, or assess behavior in work-related relationships.
Real-world examples: Applicant tracking systems (ATS) with AI ranking or scoring, video interview analysis tools that evaluate candidate facial expressions or speech patterns, AI-driven performance review platforms that score employees, workforce management tools that assign shifts or tasks based on behavioral profiles, employee monitoring software that tracks productivity and flags underperformance, AI tools that recommend termination based on performance patterns.
This category extends beyond direct hiring tools. If your SaaS product helps companies manage their workforce and uses AI to make or influence decisions about individual workers, it's likely here.
What's NOT in this category: Simple job boards without AI matching, time-tracking software that records hours without behavioral analysis, payroll processing, generic HR admin tools (leave management, document storage), employee surveys where AI summarizes aggregate results but doesn't evaluate individuals.
Category 5: Access to Essential Private and Public Services (§5)
This category focuses on AI that affects people's access to critical services and financial products.
5a. Creditworthiness assessment. AI used to evaluate whether a person is eligible for credit, or to determine the credit score of a natural person. This is one of the most clearly defined subcategories — if your fintech product uses AI to make lending decisions, you're here.
5b. Risk assessment for insurance. AI used in risk assessment and pricing for life and health insurance. Property insurance and auto insurance are not explicitly covered (though they may fall under general consumer protection rules).
5c. Public assistance eligibility. AI used to evaluate eligibility for public benefits, grants, or other forms of public assistance, and AI that revokes, reduces, or reclaims such benefits.
5d. Emergency services. AI used to classify or prioritize emergency calls (dispatching ambulances, firefighters, police), including AI that determines the priority or urgency of emergency dispatch.
Real-world examples: AI credit scoring for consumer lending, buy-now-pay-later platforms with AI-based approval, health insurance premium calculation using AI risk models, public benefits application processing with AI screening, 911/112 call routing systems with AI triage.
What's NOT in this category: General fraud detection systems (unless they directly affect credit decisions), financial analytics for investment advice (this isn't creditworthiness assessment), property insurance risk scoring, payment processing platforms, general customer analytics for financial services.
Category 6: Law Enforcement (§6)
This covers AI systems used by law enforcement authorities for individual risk assessment (likelihood of committing or re-committing offenses), polygraph-style tools and emotional state assessment during questioning, evaluation of evidence reliability, predicting crime occurrence for specific individuals or groups, profiling in criminal investigations, and crime analytics to find patterns and links between evidence.
Most relevant for SaaS companies that sell to government and law enforcement agencies. Commercial SaaS products used in consumer or enterprise contexts typically don't trigger this category.
Category 7: Migration, Asylum & Border Control (§7)
Covers AI used by competent authorities for assessing risks posed by individuals entering or staying in a territory, assisting with examination of asylum applications, and detecting or recognizing individuals in migration contexts.
Again, primarily relevant for companies selling to government immigration authorities rather than commercial SaaS.
Category 8: Administration of Justice & Democratic Processes (§8)
Covers AI systems used to assist judicial authorities in researching and interpreting facts and law and applying the law to concrete sets of facts, and AI systems intended to influence the outcome of elections or referendums (excluding tools used for organizing campaigns that don't directly interact with voters to influence their choices).
Real-world examples for SaaS: AI legal research platforms used within the judiciary, AI-driven judicial decision support systems, voter microtargeting tools that use AI to influence individual voting decisions.
What's NOT in this category: Legal research tools used by law firms (not judicial authorities), campaign management software that handles logistics, generic political advertising tools.
Common Misconceptions About Annex III
Several widespread misunderstandings lead companies to either overestimate or underestimate their risk level.
Misconception 1: "My chatbot is high-risk because it uses AI." A customer-facing chatbot is typically limited-risk under Article 50 (requiring disclosure of AI use), not high-risk. It becomes high-risk only if it's deployed in one of the 8 Annex III use cases — for example, a chatbot that screens job candidates (Category 4) or triages emergency calls (Category 5).
Misconception 2: "Any AI that processes personal data is high-risk." Processing personal data alone doesn't trigger high-risk. The GDPR governs personal data processing. The AI Act's high-risk classification depends on the use case, not the data type. However, profiling natural persons always prevents you from claiming an Article 6(3) exception.
Misconception 3: "Recommendation engines are high-risk." E-commerce product recommendations, content recommendations, and playlist suggestions are generally minimal risk. They become high-risk only if they feed into consequential decisions in an Annex III domain — for example, recommending which insurance product to offer a specific customer based on AI risk scoring.
Misconception 4: "If I'm a deployer, not a provider, I don't have to worry." Deployers of high-risk AI systems have their own obligations, including using systems according to instructions, ensuring human oversight, monitoring for risks, and informing providers of issues. You can't outsource compliance entirely.
Misconception 5: "General-purpose AI models are automatically high-risk." GPAI models (like GPT, Claude, or Gemini) have separate obligations under Articles 53–55. They're not classified as high-risk by default. However, when a GPAI model is integrated into a system intended for an Annex III use case, that system is high-risk.
Article 6(3) Exceptions in Detail
Article 6(3) is your potential off-ramp from high-risk classification. But it's narrower than many people think.
The profiling gate: If your system performs profiling of natural persons — meaning it automatically processes personal data to evaluate, analyze, or predict aspects of a person's characteristics, behavior, interests, or movements — the exception cannot apply. Period. Profiling closes the door to all exceptions.
This is critically important for SaaS products. If your system builds user profiles, creates behavioral scores, or segments individuals based on inferred characteristics, you cannot use Article 6(3) even if your core functionality seems procedural.
Exception conditions (at least one must apply):
(a) Narrow procedural task. The system performs a function that is purely administrative and doesn't affect the substance of the decision. The classic example is data format conversion — converting a PDF resume to structured fields without any filtering or ranking. The moment the system adds a score, a ranking, a flag, or any assessment, it's no longer procedural.
(b) Improving completed human activity. The system enhances something a human already did. Think grammar correction on a human-written report, or data quality checks on manually entered records. The human activity must be complete before the AI touches it.
(c) Pattern detection for human review. The system identifies patterns or anomalies but presents them purely for human consideration. It doesn't filter, rank, or prioritize — it just surfaces patterns. A fraud detection dashboard that shows suspicious transactions for an analyst to investigate might qualify, as long as it doesn't auto-block transactions or rank risk levels.
(d) Preparatory task. The system gathers or organizes information as a preparation step for a decision in an Annex III area, but doesn't itself filter, recommend, or rank. This is the most commonly claimed exception, but also the most commonly overclaimed. If your system sends a recruiter a shortlist of 20 candidates from 200 applications, that's filtering, not preparation.
The provider's obligation: If you rely on an Article 6(3) exception, you must document why the exception applies, and under the current AI Act, you must register the system in the EU database along with your reasoning. (The Digital Omnibus proposes removing this registration requirement for excepted systems, but that's not yet law.)
How Classification Affects Your Compliance Roadmap
Understanding exactly which categories and subcategories apply to your system determines your compliance roadmap. A system in Category 4 (employment) faces requirements emphasizing fairness, bias testing, and transparency to candidates. A system in Category 5 (essential services) faces scrutiny on accuracy, explainability, and data quality for financial decisions. A system in Category 1 (biometrics) faces additional fundamental rights impact assessments.
The obligations (Articles 9–15) apply uniformly to all high-risk systems, but the practical implementation looks different depending on your category. Risk management for a hiring AI centers on discrimination risk. Risk management for a credit scoring AI centers on financial exclusion risk.
Take Action
Knowing your classification isn't optional — it's the first step of compliance. And getting it wrong creates either unnecessary burden (if you over-classify) or dangerous exposure (if you under-classify).
Classify your AI system for free at complyance.io. Our classification engine maps your system against all 8 Annex III categories and their subcategories, evaluates Article 6(3) exceptions, and gives you a documented classification with specific article references — all in under 10 minutes.
Disclaimer: This article is for informational purposes only and does not constitute legal advice. Classification decisions should be verified with a qualified legal professional specializing in AI regulation.