EU AI Act and AI agents: what deployers need to do

The EU AI Act is the world's first comprehensive regulatory framework dedicated to artificial intelligence. For anyone bringing AI agents into production — systems that don't just answer, but act: booking, buying, replying to customers, running operational workflows — this isn't abstract. It's a set of concrete obligations that, depending on your role, are already starting to apply on a staggered schedule.

In this article we look at what the EU AI Act is, how its application timeline works, the crucial difference between "provider" and "deployer," and which obligations fall on those who put an AI agent to work under their own authority.

What the EU AI Act is

The EU AI Act is Regulation (EU) 2024/1689, which entered into force on 1 August 2024. As a European regulation, it applies directly in all Member States, with no need for national transposition. Its design is risk-based: instead of treating "AI" as a single block, it distinguishes systems by the level of risk they pose to people's health, safety, and fundamental rights.

At the most critical end are prohibited practices (Art. 5): uses of AI considered unacceptable. Then come high-risk systems, subject to the strictest obligations. Next are systems with transparency obligations (such as chatbots and content generators) and, at the opposite end, minimal-risk systems that are essentially free. To this is added a chapter dedicated to general-purpose AI models (GPAI) — the large models on which many applications are built.

The application timeline

The Regulation did not come into force "all at once." Its application is staggered, and understanding the calendar is the first step to avoid being caught unprepared.

• February 2025 — The prohibitions on banned practices (Art. 5) become applicable. This is the first concrete deadline.
• August 2025 — Obligations for GPAI models and the governance provisions enter into application.
• 2026 — Much of the obligations for high-risk systems and the transparency obligations (Art. 50) become applicable.
• 2027 — Obligations apply for high-risk systems linked to regulated products.

The key point: an organization that waits for the last deadline to start arrives late. Many of the tasks — mapping systems, classifying their risk, preparing documentation and oversight — take months, not days.

Provider and deployer: who does what

The EU AI Act distinguishes two fundamental roles, with different obligations.

The provider is whoever develops an AI system (or has it developed) and places it on the market or puts it into service under their own name or trademark. It's the builder of the system.

The deployer is whoever uses an AI system under their own authority in the course of their activity. It's the organization that takes an AI agent — built in-house or by a third party — and puts it to work in its own processes.

The distinction matters because obligations are distributed differently. The bulk of technical design obligations falls on the provider. But deployers are not bystanders: they have their own responsibilities, which grow especially when the system is high-risk. And there's an added catch: under certain conditions, a deployer that substantially modifies a system, or uses it for a different purpose, may take on the obligations of a provider.

Where AI agents fit

An AI agent doesn't belong to a single category: its placement depends on what it does and the context. An agent handling low-impact recommendations may fall among minimal-risk systems; the same agent, applied to a sensitive domain, may fall among high-risk systems. And almost every conversational or generative agent crosses the transparency obligations of Art. 50. That's why a deployer's first task isn't "being compliant in general," but classifying each system: understanding which risk band it falls into determines which obligations apply.

What falls on deployers of AI agents

For those putting AI agents into production, the obligations concentrate on a few areas. It's worth looking at them one by one.

Human oversight. Art. 14 requires high-risk systems to be designed to allow effective human oversight, proportionate to the risk and context, with the aim of preventing or minimizing risks to health, safety, and fundamental rights. For a deployer this means, in practice, ensuring there's always a point where a person can understand, check, and — when needed — stop or correct the agent.

Transparency. Art. 50 requires that, when an AI system interacts with people or generates or manipulates content, users are clearly informed that they are dealing with an AI or with artificially generated content. For a conversational or generative agent, this is a direct and visible obligation.

Risk management. Art. 9 provides, for high-risk systems, a continuous and iterative risk management system throughout the lifecycle. It's not a one-off task: it's a process that accompanies the system from design to operation.

Documentation. It runs across all the other obligations. Being able to demonstrate what a system does, how it was assessed, which controls are in place, and who is responsible for oversight is what turns good intentions into verifiable compliance.

Why it's worth preparing now

There are three practical reasons not to wait.

The first is the calendar: as we've seen, some deadlines have already passed and others arrive in 2026 and 2027. Preparation takes time.

The second is complexity: mapping the AI systems in use, classifying their risk, and setting up oversight and documentation is months of work, touching multiple business functions.

The third is intrinsic value: much of what the AI Act asks — knowing what an agent decides, being able to supervise it, documenting choices — coincides with what makes a deployment robust regardless of the law. Compliance, done well, isn't an added cost: it's risk engineering done right.

Where to start

Turning all this into practice, for a deployer, means proceeding in steps. The first is the inventory: knowing which AI systems and which agents are in use, who supplied them, and for what purposes. You can't govern what you don't know.

The second is risk classification: for each system, understanding which band it falls into and which obligations follow. It's the step that determines everything else: a high-risk system triggers a range of measures that a minimal-risk system doesn't require.

The third is designing the controls: where to insert human oversight, how to show transparency to the user, how to organize risk management across the lifecycle. Here the AI Act doesn't ask for abstract formalities, but for mechanisms that actually work in the operational context.

The fourth, cutting across all of them, is documentation: keeping track of choices, assessments, and responsibilities so that, if asked, you can demonstrate what the system does and how it's kept under control. It's the thread that holds all the other steps together and turns a set of good practices into a defensible position.

None of these steps is a one-off event: they're activities that repeat as systems change, are updated, or change purpose.

DAMM as a decision-governance layer

An AI agent in production makes decisions. The challenge of oversight and documentation is exactly this: making those decisions readable, controllable, and — when needed — stoppable. This is where a decision framework like DAMM can help, as a governance layer between the agent and the action: it evaluates every at-risk decision, documents it, and routes it toward human review when it's fragile.

A word of caution to avoid misunderstanding: DAMM helps meet specific requirements — especially those tied to human oversight and decision traceability — but it does not "make" an organization compliant with the entire AI Act, which requires far broader technical, organizational, and legal measures. If you want to understand how to map these requirements, our guide to the EU AI Act for those putting AI agents into production explores the topic further, while the page dedicated to AI agents shows how to integrate the decision layer into the agent's loop.

*This article is for informational purposes only and does not constitute legal advice.*