Art. 6 EU AI Act: how to classify a high-risk AI system

Updated: June 2026

Introduction: classification as the foundation of EU AI Act compliance

Everything in the EU AI Act flows from classification. Whether your organization 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-riskriskIn the EU AI Act's terms, the combination of the probability that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry →" 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 harmonization 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:

1. Biometric identification and categorization (with certain exceptions post-Omnibus)
2. Critical infrastructure management (energy, water, transport, banking)
3. Education and vocational training, AI affecting access to education
4. Employment, HR, and self-employment, CV screening, performance assessment, promotion decisions
5. Access to essential private services and public services, credit scoring, insurance, benefits assessment
6. Law enforcement, evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry → assessment, risk profilingprofilingAutomated processing of personal data to evaluate or predict aspects of a person, such as performance, behavior or location, as defined in the GDPR.Open full entry →
7. Migration, asylum, border controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry →
8. 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 harmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry → to the health, safety, or fundamental rights of natural persons.

Three conditions must be met cumulatively:

1. 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.
2. The AI system does not profile natural persons in sensitive areas.
3. 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 documentationtechnical documentationRecords a provider must compile and keep for a high-risk AI system to demonstrate conformity, covering its design, data, testing, risk management and monitoring.Open full entry → 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:

1. 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.
2. 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.
3. Document the classification rationale: For internal governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → and supervisory audit readiness, deployers should maintain written classification rationale for every AI system in their inventory.
4. 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

1. Have you inventoried all AI systems by checking them against both Annex I and Annex III?
2. For each potentially high-risk system: have you obtained and reviewed the provider's classification documentation?
3. Have you assessed whether your specific deployment context (use case, affected population, decision impact) aligns with the provider's classification?
4. Is each system's classification documented in writing with a brief rationale?
5. For systems relying on Art. 6.3: is the provider's self-assessment in writing and in your file?
6. Do you have a procedure for re-classification when a system's use case changes?