EU AI Act Article 6 Classification: A Step-by-Step Guide

What Article 6 Actually Requires

Article 6 of Regulation (EU) 2024/1689 sets the legal test for whether an AI system is classified as high-risk under the EU AI Act. The provision operates on two separate tracks. Article 6(1) covers AI systems that are products, or safety components of products, already subject to EU harmonization legislation listed in Annex I and requiring third-party conformity assessment under that legislation. Article 6(2) covers standalone AI systems whose use case falls within one of the eight categories listed in Annex III, spanning areas such as biometrics, critical infrastructure, employment, essential services, law enforcement, migration control, and the administration of justice.

Neither track is a judgment call about how sophisticated or capable a model is. Classification is driven by intended function and deployment context, not architecture. The same underlying model can be high-risk in one deployment and outside scope in another.

Annex III Categories and Where Judgment Is Required

The eight Annex III categories are broad by design, and the practical difficulty is rarely identifying the category name but rather determining whether a given system’s function actually falls within it. A system used for candidate screening, for example, may or may not fall within the employment and worker management category depending on the specific decision it automates and how much human review sits around it.

Because Annex III classification is functional rather than technical, the same model deployed for two different purposes can produce two different classification outcomes. Where a system could plausibly fall under more than one Annex III category, the classification record should state which category was assigned and why, since this reasoning is what a regulator will review if the determination is later questioned.

Exemptions Are Narrow and Function-Based

Article 6(3) exists to prevent Annex III’s broad categories from sweeping in genuinely low-impact tools, but the four exemption conditions are deliberately narrow. Each condition turns on how the system actually functions in its deployment context, such as whether it performs a narrow procedural task, improves the output of a human activity already completed, detects patterns without replacing an unreviewed human assessment, or performs preparatory work ahead of an Annex III assessment.

Providers should assess these conditions against what the system does in production, not against how it is described in product materials. Critically, any Annex III system that profiles natural persons is always high-risk. This override applies regardless of whether the system would otherwise satisfy one of the four exemption conditions, which makes profiling detection an early and explicit checkpoint in the classification workflow rather than an afterthought.

Operationalizing Classification at Enterprise Scale

• Assign cross-functional ownership: Legal, product, and engineering stakeholders should jointly own the classification decision to avoid inconsistent determinations across business units deploying similar systems.
• Build a standard exemption justification template: Since exemption claims must be documented and produced to authorities on request, a repeatable template reduces variance in how evidence is captured.
• Inventory systems with classification-relevant metadata: Capture intended purpose, deployment context, and data subject impact at the system level to support repeatable Annex III mapping over time.
• Re-run classification on material change: Because classification is tied to function and deployment context rather than the model itself, a change in either should trigger re-classification.
• Flag profiling functionality explicitly in design documentation: Given its override effect on exemption eligibility, profiling capability should be a visible, checked attribute in system documentation, not an implicit inference.

Where Classification Connects to Downstream Governance

Classification is an upstream architectural decision that determines which downstream obligations apply. Systems classified as high-risk under Article 6 carry obligations including a risk management system under Article 9, technical documentation aligned with Annex IV, and registration in the EU database under Article 49. Certain deployers of specified Annex III systems, including public bodies and entities involved in public services, credit, or insurance decisions, also face fundamental rights impact assessment obligations under Article 27.

Because classification outcomes shape record-keeping and human oversight requirements once a system is running, organizations benefit from connecting the classification decision to the runtime controls that will later need to enforce it, such as monitoring what an AI agent is actually permitted to do, logging its actions for audit, and controlling tool access according to the risk profile assigned at classification. Trussed AI provides runtime governance and enforcement capabilities, including audit logging, agent permissions, and tool approval workflows, that support the operational side of maintaining the controls a high-risk classification requires once a system is in production.