High risk or not: reasoning an Annex III classification properly
For: Teams with systems near Annex III
Updated: 2026-09
High-risk classification follows a fixed order: first the deployment area under Annex III, then whether the system plays a substantive role in the decision, then the exemption in Article 6(3). Each of those steps has to be documented with reasoning.
Classification as a high-risk system is the single most consequential decision in the whole AI Act. It triggers conformity assessment, a risk management system, data quality requirements, technical documentation and human oversight. The temptation to answer the question negatively and move on is correspondingly strong.
This checklist puts the assessment into an order that survives later review. The point is not the outcome but its traceability: a reasoned classification with documented deliberation stands far better than an unreasoned one, even where both reach the same answer.
The checklist
- 01
Describe the intended purpose precisely
Not what the system can technically do, but what it is concretely used for in your business. The same language model can classify very differently depending on purpose.
Done when: The purpose is written in two or three sentences from which an outsider can identify the use case.
- 02
Test against the Annex III areas
Work through the listed areas one by one: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and justice. Employment is the area that catches most companies unexpectedly.
Done when: Each area is marked as applicable or not — including the negatives, with a brief reason.
- 03
Check whether the system acts as a safety component
Besides Annex III, use as a safety component of a product under existing EU product law also leads to high-risk classification. This second route is frequently overlooked.
Done when: The safety component question is expressly answered rather than passed over silently.
- 04
Assess the Article 6(3) exemption
A system in an Annex III area is not high risk where it poses no significant risk to health, safety or fundamental rights — for instance because it performs a narrow procedural task or merely prepares a human assessment.
Done when: Where the exemption is relied on, the assessment it requires exists in documented form.
- 05
Consider profiling separately
The exemption does not apply where the system profiles natural persons. If it scores or categorises people, the Article 6(3) route is closed.
Done when: Whether profiling occurs is recorded, and that finding is reasoned from the intended purpose.
- 06
Write the reasoning down
Outcome, reasoning, alternatives considered, date and responsible person. Under scrutiny this memo is the actual work product.
Done when: The memo is signed off by the responsible person and linked from the system inventory.
- 07
Tie re-assessment to change
A change in intended purpose can flip the classification with no change to the technology. That is the most common way a correct classification quietly becomes invalid.
Done when: The classification carries a change trigger, not merely a date.
Common mistakes
- —The Article 6(3) exemption is relied on without documenting the assessment it requires. That removes exactly the evidence that matters.
- —Classification follows the technology rather than the purpose. The same component can be innocuous in one context and high risk in the next.
- —The employment area is underestimated. Systems for screening, ranking or performance evaluation fall under Annex III far more often than expected.
- —Only the outcome is recorded, not the route to it. Without reasoning a classification is hard to defend.
What this checklist does not cover
- —Classification at the Annex III boundary is a legal question. This checklist structures the assessment but does not replace legal advice in doubtful cases.
- —The obligations that follow a high-risk classification — risk management, data governance, technical documentation, conformity assessment — are not covered here.
- —General-purpose AI models carry their own separate obligations, which follow a different logic from Annex III classification.
- —Interpretive practice on Article 6(3) is young. A defensible assessment today may be refined by later guidance.
Parent service: EU AI Act & Compliance Advisory
Matching offers
High-risk conformity under the EU AI Act
This package brings a high-risk AI system to conformity under the EU AI Act: risk management, data governance, technical documentation to Annex IV, human oversight and logging — built as an audit-ready dossier that carries through to CE marking and registration.
FRIA & DPIA for AI systems
This package produces the impact assessments an AI system often needs simultaneously: the fundamental rights impact assessment (FRIA) under Article 27 of the AI Act and the data protection impact assessment (DPIA) under Article 35 GDPR — integrated rather than duplicated, as one audit-ready assessment with a clear approval decision.
FAQ
Is all HR-related AI automatically high risk?
Not automatically, but employment is expressly listed in Annex III. A system that screens applications or scores candidates sits very close to it. What decides is the role it plays in the decision.
What if we only use the system internally?
Internal use does not exclude classification. Annex III turns on the deployment area and the people affected, not on whether the system is externally visible.
Can we rely on the vendor’s classification?
It is a valuable starting point and should be obtained in writing. As a deployer your own assessment of the concrete purpose is still required, because the vendor does not know it.
More checklists
AI literacy under Article 4: from intention to evidence that holds
Article 4 asks for a sufficient level of AI literacy, measured against role, context and the people affected. It becomes workable in four moves: form roles, set a depth per role, train accordingly, and record attendance with date, content and the link to the role.
GDPR for SaaS: what has to stand before your first enterprise customer
Six areas are unavoidable for a SaaS product: a legal basis per processing activity, a maintained processing register, data subject rights implemented in the system, a deletion concept that actually works, clean sub-processor chains, and a demonstrable statement on data residency.
Reviewing a data processing agreement: what to look for before signing
Six points decide a DPA review: subject matter and instruction binding, the sub-processor chain and your right to object, place of processing, assistance with data subject rights, the breach notification route, and what happens to the data when the contract ends.