EU AI Act Compliance

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

A practical walkthrough of the Article 6 classification test, Annex III mapping, exemption conditions, and the documentation you need to retain.

Explore Runtime Governance Talk to an Expert
Classifying an AI system under Article 6 of the EU AI Act requires a sequential test: confirm the system meets the Article 3(1) AI system definition, check whether it is a product or safety component under Annex I harmonization law, map its function against the eight Annex III use-case categories, apply the Article 6(3) exemption conditions if applicable, and document the resulting decision. Profiling of natural persons overrides any exemption and results in automatic high-risk status.

The Classification Sequence

Work through these steps in order. Classification is driven by intended function and deployment context, not model architecture, so the same underlying model can be high-risk in one deployment and outside scope in another.

  1. Definition check

    Confirm the system meets the Article 3(1) AI system definition before applying any high-risk test.

  2. Annex I test

    Check whether the system is a product or safety component under EU harmonization legislation listed in Annex I and whether third-party conformity assessment applies under that legislation.

  3. Annex III mapping

    Match the system’s actual function to one of the eight high-risk use-case categories in Annex III (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration control, and administration of justice).

  4. Exemption test

    If an Annex III category applies, assess the Article 6(3) exemption conditions against production behavior. Any system that profiles natural persons is always high-risk; this override applies even when an exemption condition would otherwise be met.

  5. Documentation and registration

    Record the classification decision and supporting reasoning. Where an exemption is relied upon, register the system in the EU database and keep evidence available for national authorities on request.

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.

Profiling override

If an Annex III system profiles natural persons, it is high-risk under Article 6. No Article 6(3) exemption condition can change that outcome. Treat profiling capability as a visible, checked attribute in design and classification records.

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.

Documentation to Produce During Classification

Retain a written trail that shows how the decision was reached and what evidence supports any exemption claim.

  • A written record of the Article 3(1) definition check and its outcome
  • A record of the Annex I product-safety assessment, where applicable
  • The Annex III category assigned, with reasoning if multiple categories were plausible
  • The Article 6(3) exemption assessment, referencing the specific condition relied upon
  • Evidence supporting the exemption claim, available to national authorities on request
  • EU database registration confirmation for systems relying on an exemption

Common Classification Questions

Is there official EU guidance with worked classification examples yet?

The European Commission is required to publish practical implementation guidelines with worked examples under Article 6(5), but the statutory deadline for these is 2 February 2026. Current classification practice therefore relies primarily on the Regulation text itself.

Does classification depend on the AI model or the deployment?

Deployment. Annex III classification is driven by intended use case and function, not model architecture, so the same model can be high-risk in one deployment context and outside scope in another.

What happens if a system is later modified after classification?

Classification should be re-run when a system’s function, deployment context, or data inputs change materially, since the classification outcome is tied to use rather than to the underlying model alone.

Does an exemption claim need to be filed with a regulator?

Providers must document the exemption assessment before market placement and make it available to national authorities on request. Providers relying on an exemption must also register the system in the EU database referenced in Article 49(2).

Turn Classification Into Enforceable Runtime Controls

A documented Article 6 classification is the starting point, not the endpoint. Once a system is classified, the harder operational question is enforcing the access, oversight, and logging controls that classification implies.

Explore Runtime Governance