EU AI Act Annex III. The eight categories that determine whether your AI deployment is high-risk.

The first question in any EU AI Act compliance analysis is whether the system in question is high-risk. Article 6 of Regulation (EU) 2024/1689 provides the classification mechanism: a system is high-risk if it falls within the scope of Union harmonisation legislation listed in Annex I, or if it falls within one of the eight categories listed in Annex III. For most private sector enterprises, it is Annex III that matters. Annex I covers product safety legislation applied to sectors such as aviation and medical devices, where specialist regulatory frameworks already apply. Annex III covers general-purpose deployments across eight broadly defined functional categories that span the full range of enterprise AI use.

How the classification mechanism works

Article 6(1) and Article 6(2) set out the two routes to high-risk classification. Article 6(1) applies to AI systems that are safety components of products covered by Annex I legislation, such as machinery regulation, medical devices, or civil aviation. Article 6(2) applies to systems listed in Annex III. Most enterprise compliance analysis focuses on Article 6(2) and Annex III, because most enterprise AI is not a safety component of a regulated product.

The classification test under Article 6(2) is two-part. First, the system must fall within one of the eight Annex III categories. Second, it must not qualify for the Article 6(3) exclusion. Under Article 6(3), a system is not high-risk, notwithstanding Annex III listing, if it poses no significant risk of harm to health, safety, or fundamental rights. The regulation provides four indicators for making this assessment: the system performs a narrow procedural task; the system improves the result of a previously completed human activity; the system detects decision-making patterns but does not influence or replace human assessment; or the system performs a preparatory task relevant to the assessment. These indicators are cumulative and context-dependent. A system that performs a narrow procedural task in one deployment may not satisfy the indicator in a different deployment context.

Importantly, Article 6(3) is not self-executing. A provider who concludes their system is not high-risk under this provision must document the reasoning and notify the EU AI Office under Article 6(4). This creates a formal administrative record. If a regulator later disagrees with the assessment, the burden falls on the provider to justify the exemption claim against the documented reasoning.

For deployers, the practical consequence is that you cannot simply accept a provider's assertion that their system is not high-risk without understanding the basis for that conclusion. If the provider has not produced an Article 6(3) assessment, or if that assessment is not available for your review, you are operating without adequate visibility into the regulatory status of your deployment.

Category 1: Biometric identification and categorisation

Annex III, Category 1 covers two types of systems. The first type is real-time remote biometric identification systems used in publicly accessible spaces for law enforcement purposes. These are already subject to the prohibition in Article 5(1)(h) unless specific conditions and judicial authorisations apply, making them effectively unavailable to private sector deployers. The second type is post-remote biometric identification systems, and AI systems intended for the categorisation of natural persons on the basis of biometric data.

The categorisation subcategory is the one most relevant to enterprise deployments. It covers systems that infer or predict attributes of individuals from biometric data, including emotion recognition systems and systems that categorise persons by physical characteristics. Emotion recognition in customer service settings, employee monitoring that uses behavioural biometrics, or identity verification systems that derive secondary classifications from facial geometry are all candidates for Category 1 coverage. The boundary between biometric categorisation and ordinary biometric verification is a source of genuine legal uncertainty, and compliance teams should seek specific legal advice on any system that processes facial images beyond simple identity confirmation.

Category 2: Critical infrastructure safety components

Category 2 covers AI systems intended to be used as safety components in the management and operation of critical infrastructure within the meaning of Directive (EU) 2022/2557 on the resilience of critical entities. This directive covers eleven sectors: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration, space, and food.

The key qualifier is "safety component." A system that monitors electricity grid stability and generates automated intervention recommendations is a safety component of energy infrastructure. A system that performs financial reporting analytics on the same infrastructure is not. Compliance teams in financial services should note that the financial market infrastructure coverage in Directive 2022/2557 is narrower than it may appear: it covers stock exchanges, central counterparties, and central securities depositories, not the full range of financial institutions. General banking AI systems are more likely to come within Category 5 than Category 2.

Category 3: Education and vocational training

Category 3 covers AI systems used to determine access to educational institutions, to evaluate learning outcomes, to assess the appropriate level of education for individuals, and to monitor students during examinations. The intended purpose test applies throughout: a system that adapts learning content to individual pace is not in scope; a system that assesses whether a student passes to the next level is.

Higher education institutions deploying AI for admissions decision support, automated grading systems used in examinations, and proctoring tools that monitor student behaviour during remote assessments are the primary enterprise use cases. The person monitoring subcategory has generated significant concern because many commercial remote examination proctoring products meet its description precisely.

Deployers of educational AI should review their Article 26 obligations carefully, particularly the transparency obligations towards affected persons. Article 26(6) requires deployers of high-risk AI to notify natural persons that they are subject to a high-risk AI system when the system produces decisions with legal or similarly significant effects.

Category 4: Employment and workers management

Category 4 is among the most practically significant for private sector enterprises in Europe. It covers AI used for recruitment screening and evaluation, for making employment decisions, for task allocation and monitoring of performance and behaviour of persons in employment relationships, and for making decisions relevant to promotion, termination, and similar consequential employment matters.

The breadth of Category 4 means that many common enterprise HR technology products fall within scope. Applicant tracking systems with AI scoring, automated shortlisting tools, performance management platforms that use behavioural analytics, productivity monitoring software that generates management recommendations, and compensation calibration tools with predictive components are all candidates for Category 4 classification. Enterprises that have deployed these systems from vendors without requesting Annex III classification assessments are likely operating unreviewed high-risk AI.

Article 26(7) requires deployers of high-risk AI in employment contexts to inform workers that they are subject to AI systems, to the extent this is required by Union or national employment law. This notification obligation overlaps with GDPR Article 22 rights for automated decision-making. Compliance teams should ensure that the GDPR and AI Act notification regimes are coordinated rather than handled separately, as a gap between the two creates regulatory exposure on both fronts.

Category 5: Access to essential services

Category 5 covers AI systems used to evaluate the creditworthiness of natural persons or establish credit scores, except for narrow fraud detection purposes. It also covers AI used in life and health insurance risk assessment, in the administration and allocation of social benefits including eligibility assessments, and in emergency service dispatch prioritisation.

Financial services firms are the primary enterprise sector affected by the creditworthiness subcategory. Any AI system that feeds into a lending or credit scoring decision, even if it is a component of a larger process rather than the final decision-maker, is within scope if it has a material influence on the outcome. The insurance subcategory applies to life and health insurance risk categorisation, which is distinct from property and casualty insurance. Insurers using AI for health risk scoring or life expectancy modelling for premium calculation are in Category 5.

The social benefits subcategory applies primarily to public sector deployers but is relevant to private organisations that administer benefits on behalf of public bodies. Government contracting in this space carries Category 5 obligations as a contractual and regulatory condition.

Category 6: Law enforcement

Category 6 covers AI systems used by law enforcement for individual risk assessments in the context of crime prevention, for polygraphs and similar tools, for evaluation of evidence reliability, for criminal profiling, and for predicting the occurrence or recurrence of crime. This category is addressed almost entirely to public sector law enforcement bodies and is unlikely to apply to private enterprise deployments except where a business is providing AI tools to law enforcement agencies.

Category 7: Migration, asylum, and border control

Category 7 covers AI systems used as polygraphs in the context of migration, for assessing migration, asylum, and visa applications, and for detecting security or health risks at border crossings. Like Category 6, this primarily applies to government bodies. Private sector travel technology companies whose systems are used by border agencies in an integrated capacity should review their supply contracts to understand whether they bear provider obligations under the AI Act.

Category 8: Administration of justice and democratic processes

Category 8 covers AI systems used to assist judicial authorities in researching and interpreting facts and law, and applying law to specific facts. It also covers AI used to influence elections by targeting voters with tailored political messaging. Legal technology companies whose products are used within court systems should review Category 8 carefully. The election influence subcategory has direct implications for political advertising technology and voter targeting AI.

What Annex III classification means for deployers in practice

When a deployer determines that a system they operate falls within an Annex III category, the following obligations under Article 26 of Regulation (EU) 2024/1689 are triggered. First, the deployer must implement appropriate technical and organisational measures to ensure the system is used in accordance with the provider's instructions for use. Second, the deployer must assign human oversight to qualified natural persons with the competence and authority to understand the system's outputs and intervene as necessary. Third, where the deployer has sufficient control over the input data, they bear responsibility for the relevance and representativeness of that data for their deployment context.

For deployers in the public sector, or deployers using high-risk AI to assess natural persons, Article 27 additionally requires a Fundamental Rights Impact Assessment before deployment. The Article 27 FRIA guide on this site provides a detailed walkthrough of what that assessment must cover. The FRIA is not optional for in-scope deployers. It must be carried out before the system goes into service, updated when material changes occur, and made available to the national market surveillance authority on request.

On the insurance side, Annex III classification matters because AI liability products from Armilla, Munich Re aiSure, and the emerging AIUC-based coverage market all treat high-risk AI classification as a material underwriting factor. A deployer who cannot confirm their system's Annex III status at underwriting submission stage is likely to face higher premiums, coverage exclusions, or an outright decline. The certification framework at agentcertified.eu maps directly to these underwriting requirements and provides a structured approach to building the documentation that insurers need.

Building your Annex III inventory

The first practical step for any compliance team is to build an inventory of all AI systems currently in operation and assess each against the eight Annex III categories. This exercise is not trivial. Many enterprise AI deployments are not procured through a formal software acquisition process but are adopted organically through team-level subscriptions, API integrations embedded in existing tools, or bespoke fine-tuning arrangements with foundation model providers.

A reliable inventory requires the active participation of HR, finance, legal, IT, and operations teams, not just the compliance function. Each team should be asked to list all AI-assisted tools they currently use, including tools where AI is a secondary feature of a primary software product. For each tool, the compliance team should then assess the intended purpose and the deployment context against the Annex III categories.

Where a system falls within a category, the next step is to request the provider's Article 6(3) assessment and the instructions for use produced under Article 13. If the provider cannot supply these documents, the deployer faces a choice: engage the provider to produce them, accept the compliance risk of operating without them, or discontinue use of the system. The liability framework analysis on this site provides a fuller treatment of how the provider-deployer responsibility chain operates across the compliance documentation obligation.

The Omnibus variable and what it changes

The Digital Omnibus package on AI, which entered trilogue in April 2026, proposes to give enterprises a grace period of up to 16 to 24 months before the Annex III high-risk obligations become enforceable. If enacted, this would push the effective compliance deadline for most Annex III categories from August 2026 to late 2027. However, two important qualifications apply.

The first is legal. Until the Omnibus is formally adopted and published in the Official Journal, the original timeline is the binding law. Compliance teams who suspend preparation based on an anticipated delay are operating on an assumption, not a legal fact. If the trilogue fails, or if the agreed text is narrower than anticipated, those teams will face a compressed preparation window.

The second is practical. Annex III inventory work, provider documentation requests, and human oversight assignments are medium-term projects. The enterprises that will be best positioned to comply on any eventual deadline are those that started the groundwork in 2026, regardless of when enforcement formally begins. The window for orderly preparation, before compliance teams face competitive demand for qualified AI governance resources, is open now.