Art. 6 EU AI Act: how to classify a high-risk AI system
Art. 6 sets out how to classify a high-risk AI system: a system is high-risk if it is a safety component of a product under Annex I, or falls within one of the Annex III use cases. Misclassification is itself a violation, and the responsibility rests with the organisation, not the supplier.
Updated: June 2026
Introduction: classification as the foundation of EU AI Act compliance
Everything in the EU AI Act flows from classification. Whether your organisation faces the full weight of Art. 26 deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → obligations, human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry →, log retention, registration, FRIAFRIAFundamental Rights Impact Assessment — required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry →, or merely the transparencytransparencyOpenness about the fact that AI is used and how it operates in general: disclosures, documentation, notices. Pairs with explainability, which addresses individual outcomes.Open full entry → requirements of Art. 50 depends on whether your AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → qualifies as "high-risk" under Art. 6.
Getting classification right is not optional: an incorrect classification in either direction creates legal exposure. Classifying a high-risk system as minimal risk means you are in breach of the entire Art. 26 obligation set. Conversely, over-classifying creates unnecessary compliance burden and competitive disadvantage.
This article explains the two-track classification system, the critical Art. 6.3 exception, the impact of the 2026 Omnibus agreement, and the deployer's documentation obligations.
The two classification tracks
Track 1: Annex i, AI in safety-critical products
Art. 6.1 classifies as high-risk any AI system that is a safety component of a product covered by EU harmonisation legislation listed in Annex I, where that product is required to undergo third-party conformity assessmentconformity assessmentThe pre-market process demonstrating a high-risk AI system meets the EU AI Act's requirements, leading to CE marking and registration.Open full entry →.
Annex I products include: machinery, toys, lifts, pressure equipment, personal protective equipment, gas appliances, radio equipment, in-vitro diagnostic medical devices, medical devices, civil aviation, motor vehicles, maritime equipment, rail systems, agricultural tractors, and explosives.
For deployers, Track 1 is most relevant when purchasing or operating AI systems embedded in physical products. An AI-powered predictive maintenance system integrated in factory machinery may qualify as a safety component under the Machinery Directive, making it high-risk regardless of its deployment context.
Track 2: Annex III, AI in high-impact domains
Art. 6.2 classifies as high-risk any AI system listed in Annex IIIAnnex IIIThe EU AI Act's list of high-risk use-case areas — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.Open full entry →, regardless of whether it is embedded in a physical product. Annex III contains eight categories:
- Biometric identification and categorisation (with certain exceptions post-Omnibus)
- Critical infrastructure management (energy, water, transport, banking)
- Education and vocational training, AI affecting access to education
- Employment, HR, and self-employment, CV screening, performance assessment, promotion decisions
- Access to essential private services and public services, credit scoring, insurance, benefits assessment
- Law enforcement, evidence assessment, risk profiling
- Migration, asylum, border control
- Administration of justice and democratic processes
The Art. 6.3 exception: provider self-assessment route
Art. 6.3, introduced in the final legislative text, provides a significant escape valve. An AI system that would otherwise qualify as high-risk under Annex III may be classified as non-high-risk if the providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → can demonstrate that it poses no significant risk of harm to the health, safety, or fundamental rights of natural persons.
Three conditions must be met cumulatively:
- The AI system does not make decisions with significant impact on natural persons, or supports human decision-making where the human can easily override the AI output.
- The AI system does not profile natural persons in sensitive areas.
- The potential harm from the system is limited in scope and probability.
Critically: the Art. 6.3 assessment must be made by the provider, not the deployer. And the provider must document and register this assessment. A deployer relying on a provider's Art. 6.3 determination should request written evidence of that assessment.
Post-omnibus changes (May 2026)
The 2026 AI Omnibus agreement introduced several changes to the classification framework:
- Biometric identification systems used for access control in the workplace were removed from the mandatory high-risk list (Annex III, point 1). This is a significant change for deployers using facial recognition for building access.
- The Art. 6.3 self-assessment route was clarified and expanded. Providers now have a more explicit pathway to document non-high-risk determinations.
- SME-specific proportionalityproportionalityMatching the weight of governance to the risk of the use case — heavy gates for high stakes, light touch for low stakes — which keeps controls credible and followed.Open full entry → was strengthened: micro-enterprises and SMEs have access to simplified technical documentation requirements.
Deployer responsibilities in classification
A critical misunderstanding: deployers do not formally classify AI systems under the EU AI Act, that is the provider's obligation under Art. 9-28. However, deployers have four distinct classification-related obligations:
- Verify the provider's classification: Deployers must not use a system as if it were non-high-risk without verifying the provider's classification rationale. Art. 26.1 requires using the system in accordance with the instructions, which implies understanding the classification.
- Conduct own use-case analysis: Even if a provider classifies a system as non-high-risk, a deployer who deploys it in a use case that would make it high-risk is responsible. Context matters: deploying a general-purpose language model as the sole basis for credit decisions makes it high-risk under Art. 6.
- Document the classification rationale: For internal governance and supervisory audit readiness, deployers should maintain written classification rationale for every AI system in their inventory.
- Apply conservative defaults: When classification is genuinely uncertain, best practice (and the spirit of Art. 9.4) is to apply the higher risk classification until the lower classification can be substantiated.
Compliance checklist
- Have you inventoried all AI systems by checking them against both Annex I and Annex III?
- For each potentially high-risk system: have you obtained and reviewed the provider's classification documentation?
- Have you assessed whether your specific deployment context (use case, affected population, decision impact) aligns with the provider's classification?
- Is each system's classification documented in writing with a brief rationale?
- For systems relying on Art. 6.3: is the provider's self-assessment in writing and in your file?
- Do you have a procedure for re-classification when a system's use case changes?