Classifying an AI Agent Under the EU AI Act's Risk Tiers

Classifying an AI agent under the EU AI Act answers one practical question: which set of legal obligations attaches to this specific agent, given what it actually does. Get the classification wrong and you either build compliance infrastructure you didn't need or ship an agent without the oversight, logging, and documentation a regulator will expect it to have. This post is the decision workflow — nothing else.

What classification decides, and who owes it

Classification determines which of four obligation tiers an AI agent falls into, and that determination is owed by whoever is responsible for the agent's deployment — the provider if you build and place the system on the market, the deployer if you configure a third-party system for your own use. Both roles carry classification-dependent obligations, and neither is exempt from doing the classification exercise itself.

The decision is driven by the agent's intended purpose and function, not by its underlying model or technical architecture. A workflow-automation agent that drafts marketing copy is a different classification question from the same underlying model repurposed to screen job applicants — the model can be identical; the classification is not. Run this workflow per agent, and re-run it whenever an agent's function changes.

Step 1 — is it a prohibited practice?

The first check is whether the agent's function falls into the Act's unacceptable-risk category, which is an outright prohibition rather than a compliance obligation. This tier covers practices like social scoring by public authorities and certain forms of biometric surveillance, and almost no commercial agent deployment lands here. If your agent's function resembles anything in this category, the answer is not "add controls" — it is "the deployment is not permitted," and that determination should involve legal review before anything else in this workflow matters.

For the large majority of enterprise agents, this step resolves quickly: the agent does not perform social scoring, does not conduct the kind of biometric surveillance the Act prohibits, and moves to Step 2.

Step 2 — does it fall in an Annex III high-risk category?

High-risk classification under Annex III brings the Act's heaviest obligation set: conformity assessment, technical documentation, human oversight, logging, and accuracy and robustness requirements. The categories most relevant to enterprise agent deployments are systems that assess individuals for access to employment or benefits, systems that evaluate creditworthiness, systems used in law enforcement or judicial decision-making, and systems that function as safety components of otherwise-regulated products.

Ask specifically what decision the agent informs or makes, not what department deployed it. An agent that summarizes resumes for a recruiter to read is a different question from an agent that scores candidates and filters who a recruiter sees — the second is far more likely to land in Annex III because it is making or materially shaping a consequential decision about a person, not merely surfacing information a human then evaluates independently.

If your agent lands here, the heavier obligation set applies regardless of the underlying model's general capability level — a narrow, purpose-built classifier used for credit scoring is just as much an Annex III system as a general-purpose agent repurposed for the same task, though the specific conformity path (self-assessment versus notified-body review) still depends on the category.

Step 3 — does Article 50 transparency apply?

Article 50's transparency obligations are the step most teams skip because they assume transparency only matters for agents that failed Step 2, and that assumption is wrong. Article 50 applies to providers and deployers of AI systems that interact with people or generate content, and it applies regardless of which risk tier the system otherwise falls into — a minimal-risk agent that would never appear in Annex III still owes disclosure if it interacts directly with people.

Two obligations to check independently: does the agent interact directly with a person in a way that is not obvious from context (if so, it must disclose that the person is interacting with AI), and does the agent generate synthetic content — text, audio, image, or video — that must be marked as AI-generated in a machine-readable way. An agent can clear Step 2 as non-high-risk and still owe both of these obligations under Step 3, because the two checks answer different questions. The full engineering detail of what Article 50 requires — disclosure UX, content-marking pipelines, and the "obvious from context" exemption — is covered in Article 50 transparency obligations for engineers; this workflow only establishes whether the trigger applies to your agent.

Step 4 — minimal risk, and what still applies

If an agent clears all three prior steps — not prohibited, not Annex III high-risk, and does not trigger Article 50's interaction or content-generation disclosure duties — it falls into minimal risk, which is effectively unregulated under the Act. Most internal tooling and back-office automation agents land here.

"Minimal risk" is not the same as "no obligations ever." If the agent's function changes to add a people-facing interaction surface or content generation, Step 3 can trigger even though the agent's overall risk classification stays minimal. Treat minimal risk as the current answer for the agent's current function, not a permanent exemption from re-checking.

Numbered decision procedure

Run this sequence for every agent, and record the outcome and reasoning at each step:

1. Describe the agent's function in one sentence — what decision does it make or inform, and about whom.
2. Check Step 1: does the function match a prohibited practice (social scoring by a public authority, prohibited biometric surveillance)? If yes, stop — the deployment requires legal review, not further classification.
3. Check Step 2: does the function match an Annex III high-risk category (employment/benefits access, creditworthiness, law enforcement/judicial decisions, safety components of a regulated product)? If yes, the agent is high-risk; proceed to build the conformity, documentation, logging, and human-oversight obligations that tier requires.
4. Check Step 3 independently of the Step 2 outcome: does the agent interact directly with people, or generate synthetic content? If yes to either, Article 50 disclosure or content-marking obligations apply — these stack on top of any high-risk obligations from Step 2 rather than replacing them.
5. If none of Steps 1–3 apply, classify the agent as minimal risk and record the reasoning.
6. Record the classification, the date it was determined, and the specific facts about the agent's function that drove the answer — not just the resulting tier — so a later review can tell whether drift has occurred.
7. Set a review trigger, not just a review date (see reclassification triggers below).

Reclassification triggers: when an agent's function changes

Classification is not a one-time exercise, because an agent's intended purpose can drift without anyone deciding to reclassify it. The Act itself only says to re-evaluate when scope changes; the specific trigger list below is practitioner guidance we recommend for turning that principle into a mandatory re-run of this workflow, not a taxonomy the regulation itself specifies:

• The agent gains a new capability that changes what decision it makes or informs (a summarization agent that starts scoring or ranking).
• The agent's output starts being used for a different downstream purpose than the one it was originally classified against, even if the agent's code did not change.
• The agent gains a new people-facing surface (a back-office agent that starts sending messages directly to customers) — this specifically re-triggers Step 3 even if Steps 1 and 2 are unaffected.
• The agent's scope expands to a new jurisdiction, business unit, or use case that was not part of the original classification review.

An inventory that records classification reasoning per agent, not just the resulting tier, is what makes this re-run practical rather than a full re-investigation every time. The AI agent compliance checklist for 2026 is a reasonable structure for maintaining that inventory across an agent fleet, and the complete AI governance guide covers how classification fits into the broader oversight, audit, and documentation program this workflow feeds into. For the underlying regulation in full engineering detail — including what the 2026 Digital Omnibus changed to the Annex III timeline — see the EU AI Act explained for engineering teams and what the Digital Omnibus changed; this post assumes that background rather than repeating it.