What the EU AI Act Means for AI Agents

The EU AI Act was written before autonomous agents became common, so it never names them as a category. That does not put agents outside its scope. An agent is an AI system, and the Act regulates AI systems by what they do and the risk they pose. If your agent operates in the EU or affects people in the EU, it falls under the same rules as any other AI system, plus a few obligations that get sharper once an agent can act on its own.

This post covers how the Act applies to agents specifically: where they land in the risk tiers, why autonomy makes classification harder, and how the high-risk obligations read differently when the system reasons and takes actions. For the full breakdown of the Act's compliance obligations, penalties, and GPAI model rules, see the companion post on EU AI Act compliance for AI agents. This one stays focused on the agent-specific angle.

The Act regulates uses, not "agents" as a category

The EU AI Act is risk-based. It does not assign obligations to a technology label like "agent" or "LLM." It assigns them to the use case and the risk that use creates for health, safety, and fundamental rights. A chatbot answering product questions and an agent approving loan applications are both AI systems, but they sit in very different places under the Act because they do different things.

For agents this has a practical consequence. A single agent can span more than one risk tier depending on the tasks it performs. An agent that both drafts marketing copy (minimal risk) and screens job applicants (high risk) has to be classified by its highest-risk function. You classify the behavior, not the deployment.

Where agents land in the four risk tiers

The Act sorts AI systems into four tiers. Here is how agents typically map.

Unacceptable risk (prohibited). Practices banned outright, such as social scoring by public authorities, manipulative systems that exploit vulnerabilities, and most real-time remote biometric identification in public spaces. An agent built to do any of these is prohibited regardless of how well it performs.

High risk. Systems used in sensitive domains: credit and creditworthiness, employment and worker management, essential private and public services, critical infrastructure, education, law enforcement, and more. Most enterprise agents that make or materially influence consequential decisions land here. A collections agent, a hiring-screen agent, or an agent that determines benefit eligibility carries the full weight of the high-risk obligations.

Limited risk (transparency). Systems that interact with people or generate content have transparency duties: users must be told they are dealing with an AI, and synthetic content should be marked. Most customer-facing conversational agents live here at minimum, and some also carry high-risk obligations depending on what they decide.

Minimal risk. Everything else, such as an internal agent that summarizes meeting notes or triages tickets with no consequential downstream effect. These carry no mandatory obligations under the Act, though good governance still applies.

Why autonomy complicates classification

Classifying a static model is a one-time exercise: you assess what it outputs and where it is used. Agents make this harder in three ways.

Tool use expands what the system actually does. An agent classified on its language output may quietly cross into high-risk territory once you give it a tool that moves money, changes records, or sends communications. The risk lives in the action, not the text.

Chained actions produce behavior nobody classified. An agent that plans and executes multi-step workflows can combine individually low-risk steps into a high-risk outcome. Classification has to account for what the agent can do end to end, not just its first step.

Multi-agent delegation blurs the boundary. When one agent calls another, the risk profile of the whole system depends on the most consequential thing any agent in the chain can do. A benign orchestrator that delegates to an agent with database write access inherits that risk.

The takeaway: agent classification is not a label you set once at deployment. It has to reflect the agent's full reach, including its tools, its sub-agents, and the actions it can chain together.

Reading the high-risk obligations for agents

If your agent is high-risk, the Act's core obligations still apply, but each one takes on a sharper meaning when the system acts autonomously. The full obligation list is in the companion compliance post linked above; here is how four of them read for agents.

Human oversight. The Act requires that high-risk systems can be effectively overseen by people. For an agent, oversight is not a dashboard someone glances at. It means approval gates on consequential, irreversible actions (moving money, deleting data, sending external communications) and a way to intervene or stop the agent mid-execution. Oversight has to sit in the action path, not beside it.

Logging and traceability. High-risk systems must keep records that allow their operation to be traced. For an agent, input-output logging is not enough. You need the full execution trace: the prompts, the tool calls, the data retrieved, the reasoning steps, and the decisions made, so anyone reviewing an outcome can reconstruct why the agent did what it did.

Accuracy and robustness. The Act expects appropriate levels of accuracy and consistent performance. Agents are non-deterministic and their behavior drifts as inputs, prompts, and models change. Point-in-time validation does not satisfy this for a system that behaves differently tomorrow. Accuracy for agents means ongoing measurement against real production behavior, not a single pre-deployment test.

Data governance. Training and operational data must be relevant, representative, and appropriately handled. For agents that retrieve context at runtime (RAG, tool outputs, external sources), data governance extends to what the agent pulls in during execution, not just what it was built on.

Timelines that matter for agent builders

The Act phases in over several years. The dates that matter most:

• August 2024: the Act entered into force.
• February 2025: prohibitions on unacceptable-risk practices apply.
• August 2025: obligations for general-purpose AI (GPAI) models apply, relevant if your agent is built on a foundation model.
• August 2026: the bulk of the high-risk obligations apply.

If you are building agents for high-risk use cases, the August 2026 obligations are the ones to design for now. Retrofitting oversight, logging, and continuous accuracy measurement into a live agent is far harder than building them in from the start.

The part most guidance skips: proving it continuously

Most EU AI Act guidance treats compliance as a point-in-time exercise: classify the system, document it, complete a conformity assessment, ship. That model was built for static software and static models. Agents break it, because an agent's behavior is not fixed at deployment. It changes as prompts, models, tools, and inputs change. A conformity assessment that was accurate in June can be stale by September.

For agents, compliance is a continuous obligation. You have to be able to show, at any point, that the agent is still classified correctly, still overseen, still logged, and still performing within its stated accuracy. That requires the same runtime layer that makes agents reliable in the first place.

Arthur's Agent Security and Governance approach maps directly to the agent-specific reading of the Act.

Discovery produces the inventory an assessment depends on. Arthur finds agents across environments through telemetry, MCP monitoring, network analysis, and API-driven methods, so shadow agents that were never classified surface instead of hiding from your risk assessment.

Observability satisfies the traceability requirement. End-to-end tracing captures every prompt, tool call, retrieval, and decision, so an outcome can be reconstructed and explained on demand.

Continuous evaluations address accuracy and robustness as an ongoing duty. Automated evals run against real production traffic, turning "we validated it once" into a live measurement you can report against.

Guardrails operationalize human oversight and data governance. Pre- and post-LLM guardrails validate actions before they execute, block sensitive data from leaving the environment, and can route high-impact actions to a human.

Governance ties it to accountability: a named owner for every agent, policy enforcement, and an audit trail across the agents a team builds and the agents it buys.

That is the bridge from "we assessed the agent once" to "here is continuous evidence it still meets its obligations."

Frequently asked questions

Are AI agents high-risk under the EU AI Act? Some are, some are not. The Act classifies by use, so an agent is high-risk if it operates in a sensitive domain like credit, employment, or essential services, or makes decisions that materially affect people's rights. An internal agent with no consequential effect is usually minimal risk. Classify the agent by its highest-risk function.

Does the EU AI Act mention AI agents specifically? No. The Act was drafted around AI systems generally and does not carve out agents as a distinct category. Agents fall under the same risk-based rules as any other AI system, with autonomy and tool use affecting how they are classified.

How does the Act apply to multi-agent systems? A multi-agent system is classified by the most consequential action any agent in the chain can take. If an orchestrator delegates to a sub-agent with high-risk capabilities, the system inherits that risk tier. You have to assess the full delegation chain, not each agent in isolation.

What if my agent is built on a GPAI model? GPAI model obligations (which took effect in August 2025) apply to the model provider, but building on a GPAI model does not exempt your agent from its own classification. You are responsible for the agent's use-case risk tier and obligations on top of whatever the model provider handles.

Is a one-time conformity assessment enough for an agent? It is a starting point, not a finish line. Because agent behavior changes at runtime, meeting obligations like human oversight, logging, and accuracy is a continuous exercise. You need ongoing observability and evaluation to show the agent still meets its obligations after deployment.

Key takeaways

• The EU AI Act does not name agents, but it regulates them by use and risk like any other AI system.
• Classify agents by their highest-risk function, and account for tools, chained actions, and sub-agents, not just the first output.
• High-risk obligations read differently for agents: oversight belongs in the action path, logging means full traces, and accuracy is a continuous measurement.
• Design for the August 2026 high-risk obligations now; retrofitting oversight and logging into a live agent is far harder.
• Compliance for agents is continuous, not point-in-time. Discovery, observability, continuous evals, guardrails, and governance are how you keep proving it.

Get started

See how Arthur helps teams discover, secure, and govern their agents with the continuous evidence the EU AI Act expects. Book a demo or explore the Agent Development Toolkit.

‍