GovCompass
Knowledge base

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

By Michel Venniker· · Aligned with the consolidated EU AI Act, including the 2026 Omnibus amendments.

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:

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

  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 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?
Legal referencesArt. 6

More on Accountability

Art. 10 EU AI Act: data and data governance for high-risk AI

Reference

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 12 EU AI Act: record-keeping and logging for high-risk AI

Reference

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 19 EU AI Act: keeping the automatically generated logs

Reference

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Art. 26.1 EU AI Act: following provider instructions as a deployer

Reference

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.

More on Safety & reliability

Art. 14 EU AI Act: designing high-risk AI for human oversight

Reference

Art. 14 requires providers to design and build high-risk AI systems so that they can be effectively overseen by humans during use. The system must let an overseer understand its capabilities and limits, watch for anomalies, resist automation bias, correctly interpret outputs, decide not to use the system, and intervene or stop it through a kill switch (Art. 14(4)(e)). It is the design obligation that makes the deployer oversight duty of Art. 26.2 possible.

Art. 26.4 EU AI Act: input data quality for deployers

Reference

Art. 26.4 requires deployers of high-risk AI to ensure that input data is relevant and sufficiently representative for the system's intended purpose. The deployer is responsible for data quality in operation, even though the provider sets the specifications under Art. 10.

Art. 26.5 EU AI Act: post-market monitoring for deployers

Reference

Art. 26.5 requires deployers of high-risk AI to monitor the system's operation against the provider's instructions and to report risks and serious incidents. Monitoring is the early-warning mechanism that connects to incident reporting under Art. 73.

Art. 5 EU AI Act: all 8 prohibited AI practices explained

Reference

Art. 5 lists the eight prohibited AI practices, including subliminal manipulation, exploitation of vulnerable groups, social scoring, and untargeted facial-recognition scraping. These prohibitions are absolute, apply to every organisation regardless of size, and have been in force since 2 February 2025.