Art. 6 EU AI Act: How to Classify a High-Risk AI System

Updated: June 2026 — full revision to Validai quality standard

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 deployer obligations — human oversight, log retention, registration, FRIA — or merely the transparency requirements of Art. 50 depends on whether your AI system 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 assessment.

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 III, regardless of whether it is embedded in a physical product. Annex III contains eight categories:

1. Biometric identification and categorisation (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 — evidence assessment, risk profiling
7. Migration, asylum, border control
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 provider 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:

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 proportionality 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:

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 governance 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?