Classification as high-risk under the EU AI Act is not a question of how sophisticated your AI system is, or even how much data it processes. It is a question of what your system is intended to do. Annex III of Regulation (EU) 2024/1689 sets out eight categories of use cases in which AI systems are presumed to carry significant risk to health, safety, or fundamental rights. And if your system falls into any of them, the full weight of the regulation applies.
That means a risk management system under Article 9, technical documentation under Article 11, data governance requirements under Article 10, human oversight mechanisms under Article 14, accuracy and robustness standards under Article 15, conformity assessment before deployment, registration in the EU database under Article 49, and ongoing post-market monitoring. For deployers specifically, Article 26 adds its own layer: use AI only as instructed, keep logs, conduct fundamental rights impact assessments where required, and ensure human oversight is operationally possible.
This page walks through every Annex III category in plain language, explains what qualifies and ( just as importantly) what does not, and flags the compliance implications for each. If you are trying to determine whether your AI system is high-risk, this is the reference to start with.
How Annex III classification works
Annex III operates under Article 6(2): an AI system is high-risk if it is intended to be used in any of the listed areas. Intended use is the operative concept; classification follows the purpose a system is designed and marketed for, not its underlying architecture.
A general-purpose AI model is not high-risk by default; the same model integrated into a CV-screening tool is.
There is a narrow escape route. Article 6(3) provides that an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, and if it meets at least one of four conditions:
- It performs a narrow procedural task.
- It improves the result of a previously completed human activity.
- It detects decision-making patterns without replacing or influencing human assessment.
- It performs a preparatory task to an assessment in an Annex III area.
One absolute constraint applies: if your system profiles natural persons (automated processing of personal data to evaluate aspects of their behaviour, characteristics, interests, or location) the Article 6(3) exception is unavailable, and the system is always high-risk. Providers relying on the exception must document their assessment before placing the system on the market (Article 6(4)).
The 8 Annex III categories in the EU AI Act
Category 1: Biometrics
Relevant law: Subject to permissibility under Union or national law.
Biometrics sits at the top of Annex III for good reason. AI systems in this category process physical or behavioural characteristics to identify, categorise, or infer things about individuals. With high potential for errors that carry serious consequences.
What is covered:
1(a) Remote biometric identification systems. Systems that identify natural persons at a distance and without their active participation by comparing biometric data against a reference database.
The classic example is a facial recognition system that attempts to match unknown individuals in a CCTV feed against a database. Post-event remote biometric identification (matching footage after an incident) falls here, as does real-time identification.
Note that real-time remote biometric identification in publicly accessible spaces for law enforcement is not merely high-risk; it is largely prohibited under Article 5(1)(h), with three narrow exceptions.
What is excluded: Biometric verification systems whose sole purpose is to confirm that a specific individual is who they claim to be are explicitly excluded. If your system checks "is this person the one in their passport?" rather than "who is this person?", it is not captured under 1(a).
1(b) Biometric categorisation according to sensitive or protected attributes. AI systems that assign natural persons to categories based on biometric data where those categories correspond to protected characteristics (race, political opinion, religion, sexual orientation, and similar attributes).
Note that categorisation by sensitive attributes using biometric data in many contexts is prohibited outright under Article 5(1)(g); where it is not prohibited, it is high-risk.
1(c) Emotion recognition. AI systems intended to infer the emotional state of natural persons from biometric or other signals. Emotion recognition in workplaces and educational institutions is prohibited under Article 5(1)(f). Where emotion recognition is lawful (certain research contexts, for example) the system is high-risk.
Compliance implication for deployers: Biometric systems face the strictest oversight requirements, and several use cases overlap with the prohibition list. Before deploying any AI that processes biometric data, confirm whether the system is prohibited, high-risk, or both, as they require different responses.
Category 2: Critical infrastructure
AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating, or electricity.
What is covered: The defining criterion is the safety component. An AI system that has the potential to cause failure, disruption, or harm to critical infrastructure qualifies. Examples include AI that manages load distribution across a power grid, systems controlling water treatment processes, or traffic management AI that could cause accidents if it fails.
What is excluded: AI used for operational optimisation without safety implications falls outside this category. An AI that optimises energy pricing does not qualify; an AI that controls valve operations in a gas supply network does. The distinction is between consequence of failure (which is the legal test) and function.
Compliance implication for deployers: Critical infrastructure operators should map every AI system to the question: what happens if this system makes an error or fails? If the answer involves physical harm or infrastructure failure, high-risk classification is likely.
Category 3: Education and vocational training
AI systems that determine access to education, evaluate learning outcomes, or monitor student behaviour.
What is covered:
3(a) Systems that determine access or admission to educational and vocational training institutions at any level; undergraduate admissions tools, apprenticeship selection systems, and similar.
3(b) Systems that evaluate learning outcomes, including where those outcomes influence how the learning process is structured for an individual student.
3(c) Systems used to assess what level of education a person will receive or can access; capability or aptitude assessment tools feeding into placement decisions.
3(d) Systems that monitor and detect prohibited behaviour of students during tests; AI-based exam proctoring tools.
What is excluded: AI that assists learning without affecting access, grades, or behavioural assessment is generally not in scope. A tutoring chatbot that explains concepts but does not assess or grade students is typically not high-risk under this category.
Compliance implication for deployers: Educational institutions and EdTech companies deploying AI for admissions, assessment, or proctoring should assume high-risk classification and begin the conformity process. The stakes (access to education) are precisely the kind of consequential decision the EU AI Act is designed to regulate.
Category 4: Employment, workers' management and access to self-employment
This is arguably the broadest Annex III category in terms of the number of deployed systems it captures, and one of the most commercially significant.
What is covered:
4(a) AI used for recruitment or selection; including targeted job advertising (showing job ads to certain demographic groups), filtering and ranking job applications, and evaluating candidates at any stage of the hiring process.
4(b) AI used to make or influence decisions about terms of employment, including promotion, termination, task allocation based on individual behaviour or personal traits, and monitoring and evaluating employee performance and behaviour.
What is excluded: Systems that simply help HR teams manage administrative processes (scheduling software, absence tracking without performance inference, or tools that organise existing HR data without ranking or evaluating individuals) are generally not in this category.
Compliance implication for deployers: Any organisation using AI to screen CVs, rank candidates, score employees, or make decisions about working conditions is almost certainly in scope. This is one of the most commonly misclassified areas; many HR teams believe their ATS or performance tool is too simple to qualify, when the classification question turns not on complexity but on the decision the system informs.
Category 5: Access to essential private and public services
What is covered:
5(a) AI used by public authorities (or on their behalf) to evaluate eligibility for essential public assistance benefits and services, including healthcare services, and to grant, reduce, revoke, or reclaim them. Systems used by local councils, welfare agencies, and healthcare authorities to assess entitlement qualify here.
5(b) AI used to evaluate the creditworthiness of natural persons or establish their credit score. This covers credit decisioning models, mortgage affordability tools, and scoring systems used in lending; but explicitly excludes AI systems used for detecting financial fraud.
5(c) AI used for risk assessment and pricing in relation to natural persons in the case of life and health insurance. Actuarial AI models that influence individual insurance premiums or risk classifications are covered.
5(d) AI that evaluates and classifies emergency calls, or is used to dispatch or prioritise emergency first response services (including police, firefighters, and medical aid) as well as emergency healthcare patient triage systems.
Compliance implication for deployers: Financial services and insurance companies using AI in underwriting, credit decisioning, or pricing need to treat these systems as high-risk by default. The credit fraud detection carve-out is specific and narrow; it applies only where fraud detection is the explicit purpose of the system.
Category 6: Law enforcement
Relevant law: Subject to permissibility under Union or national law.
Law enforcement AI carries the highest potential for serious, irreversible harm to individuals; arrest, prosecution, detention. The Annex III provisions in this category are correspondingly detailed.
What is covered:
6(a) AI used by or on behalf of law enforcement authorities to assess the risk of a natural person becoming the victim of criminal offences.
6(b) AI used by or on behalf of law enforcement authorities as polygraphs or similar tools.
6(c) AI used by or on behalf of law enforcement to evaluate the reliability of evidence in the course of criminal investigation or prosecution.
6(d) AI used by law enforcement to assess the risk of a person offending or re-offending, or to assess personality traits and characteristics or past criminal behaviour of individuals or groups. This includes predictive policing tools when they incorporate any information beyond pure profiling.
6(e) AI used by law enforcement for profiling of natural persons (automated processing of personal data to evaluate aspects of behaviour, characteristics, or circumstances) in the course of detecting, investigating, or prosecuting criminal offences.
What is excluded: The category applies only to law enforcement use. The same AI system used by a private company for fraud detection does not fall under Category 6, it may fall under Category 5 depending on its function.
Compliance implication for deployers: Law enforcement AI is subject to some of the most stringent oversight requirements under the Act and is explicitly excluded from AI regulatory sandbox protections in certain respects. Public authorities in this area should plan for extensive documentation and human oversight obligations.
Category 7: Migration, asylum and border control management
Relevant law: Subject to permissibility under Union or national law.
What is covered:
7(a) AI used by competent public authorities or EU institutions as polygraphs or similar tools in the migration and border context.
7(b) AI used to assess risk posed by a natural person seeking to enter or who has entered EU territory; including security risk, irregular migration risk, or health risk.
7(c) AI that assists in examining applications for asylum, visa, or residence permits; including assessing the credibility of evidence provided by applicants.
7(d) AI used to detect, recognise, or identify natural persons in the context of migration, asylum, or border control management; excluding verification of travel documents.
What is excluded: The travel documents exemption in 7(d) is specific: AI used to verify that a travel document is authentic and belongs to its holder is not captured. Broader biometric identification of unknown individuals at borders is.
Compliance implication for deployers: This category applies primarily to government agencies and public authorities managing immigration and border operations. Private-sector operators providing AI to these authorities should confirm with their customers whether deployment triggers high-risk obligations on the deployer side.
Category 8: Administration of justice and democratic processes
What is covered:
8(a) AI used by judicial authorities, or on their behalf, to assist in researching and interpreting facts and law, or in applying the law to a specific set of facts. This also covers alternative dispute resolution contexts. AI tools that help judges analyse case law, assess evidence, or suggest sentencing parameters fall here.
8(b) AI intended to influence the outcome of an election or referendum, or to influence the voting behaviour of natural persons. This does not cover AI used solely for administrative or logistical purposes in running a political campaign; the condition is direct influence on voting behaviour or electoral outcomes.
Compliance implication for deployers: LegalTech companies providing AI to courts or arbitration bodies should treat their systems as high-risk. The electoral AI provision is deliberately broad; any AI designed with the intent of shifting how people vote is in scope, regardless of its technical form.
What high-risk classification means in practice
If your AI system falls into any of the eight categories above (and the Article 6(3) exception does not apply) you face obligations across the full high-risk compliance framework:
Before deployment:
- Establish a risk management system covering the system's entire lifecycle (Article 9)
- Implement data governance for training, validation, and testing datasets (Article 10)
- Prepare technical documentation per Annex IV's eleven-point specification (Article 11)
- Build in automatic logging and record-keeping functionality (Article 12)
- Ensure the system provides transparency to deployers via adequate instructions for use (Article 13)
- Implement human oversight measures sufficient to detect, correct, and override the system's operation (Article 14)
- Meet accuracy, robustness, and cybersecurity requirements (Article 15)
- Complete conformity assessment; self-assessment or third-party depending on the category (Article 43)
- Register the system in the EU AI Act database (Article 49)
After deployment:
- Operate a post-market monitoring system proportionate to the system's risk and scale (Article 72)
- Log incidents and malfunctions and report serious incidents to competent authorities (Article 73)
- For deployers specifically: conduct a fundamental rights impact assessment before deploying systems in certain contexts (Article 27), use the system in line with the instructions for use (Article 26(1)), and ensure human oversight is genuinely operational
The enforcement deadline for standalone Annex III systems was moved to 2 December 2027 under the provisional Digital Omnibus agreement of May 2026, a deferral from the original 2 August 2026 date. That is not an invitation to postpone preparation. The documentation and monitoring infrastructure required by the Act takes time to build, and organisations that start after the deadline announcement will not finish by enforcement.
Can Annex III be changed?
Yes. Article 7 empowers the European Commission to amend Annex III by delegated act to add new high-risk use cases or (in narrower circumstances) to remove categories that evidence shows do not warrant the classification. The criteria for additions include the severity and probability of harm, the reversibility of that harm, the degree of power asymmetry between the AI system operator and the affected persons, and the scale of potential impact.
The Commission published draft classification guidelines in 2026 (as required by Article 6(5)) providing practical examples and interpretation guidance. Organisations should monitor these guidelines alongside the official Annex III text, as the guidance shapes how market surveillance authorities will apply the list in practice.
Deeploy and high-risk AI compliance
Post-market monitoring and logging are not one-off exercises. For every system in the table above, the EU AI Act requires continuous tracking of performance, detection of changes in behaviour, and automatic logging sufficient to identify system-level risks; obligations that run for the entire operational life of the system.
Deeploy provides continuous monitoring, automated logging, and audit-ready documentation for AI systems running in production. Whether your high-risk system sits in the employment, financial services, or essential services category, Deeploy’s platform gives deployers the technical infrastructure the Act requires.
Frequently asked questions
There are two routes to high-risk classification. Under Article 6(1), an AI system that is a safety component of a product covered by EU harmonised legislation (such as medical devices or machinery) is high-risk, provided its failure or malfunction would endanger health or safety. Following the Digital Omnibus, AI used solely for non-safety purposes, such as user assistance, optimisation, service efficiency, automation, convenience, or non-safety quality control, no longer qualifies under this route.
Under Article 6(2), standalone AI systems listed in Annex III are high-risk. Annex III covers eight sectors: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration and asylum, and administration of justice.
Almost certainly yes. Annex III Point 4 covers AI systems used for recruitment, candidate selection, CV screening, task allocation, performance monitoring, and promotion or termination decisions. If your tool performs any of these functions, it falls within scope and is subject to the full high-risk requirements.
Yes. Annex III Point 5 covers AI systems used to evaluate the creditworthiness of individuals or establish their credit score. This applies whether the system is built in-house or procured from a third party.
Not automatically. Classification depends on use case, not technology. A product recommendation engine on a retail website is typically minimal risk. The same algorithmic logic applied to determining access to essential services, or to allocating workers to tasks, would be high-risk under Annex III.
Both. The Act covers AI systems regardless of whether they face customers or are used solely for internal operations such as HR, finance, or IT management. Internal employee monitoring or performance evaluation tools are explicitly within Annex III scope.
The Commission's guidance defines a significant change as one that affects the intended purpose of the system, its performance on safety-relevant tasks, or the nature of risks it poses. A model retrained on substantially different data, or repurposed for a new use case, is likely to qualify. Minor parameter updates typically do not.
