Organisations are moving from AI that answers to AI that acts. An agent reads an email, consults a file, checks the conditions, drafts a decision and updates the system, all on its own. That shift raises one governance question above all others: which rules apply to an agent that acts by itself, and what do you need to put in place before it goes live?
The short answer: agentic AI governance is not a new legal regime, it is the disciplined application of rules that already exist. AI agents fall under the EU AI Act through the definition of an AI system in Article 3(1), which explicitly covers systems that operate with varying levels of autonomy. On top of that, GDPR Article 22 already limits agents that autonomously take decisions with legal effects. Governing agents therefore means answering six questions well: is it an AI system, what is the risk, who is provider and who is deployer, which controls does it need, how do you assess its risk, and who answers when it goes wrong. This page is the map to each of those questions.
Agentic AI governance in five sentences
Agents are AI systems under Article 3(1) and follow the ordinary risk ladder, with no separate agent regime. From 2 August 2026 Article 50 applies: an agent that communicates with people or generates content must make that known, and this date has not been postponed. An agent performing a high-risk task from Annex III follows the high-risk route towards 2 December 2027, while GDPR Article 22 already limits decisions with legal effects today. The governance core is six controls: scoped permissions, a deliberate choice between human in the loop and on the loop, logging, a kill switch, periodic review and a place in the AI register. Get started by inventorying your agents, classifying each one, and putting oversight around the ones that act with consequences.
What is agentic AI, and how is it different from a chatbot or a model?
An agent differs from an ordinary chatbot in three ways. It executes tasks autonomously, working out the intermediate steps from a goal. It uses tools, calling systems, APIs and databases to take those steps. And it reasons in multiple steps, planning and adjusting as it goes. A model answers a question. An agent handles a case from start to finish.
That autonomy changes nothing about the legal qualification, and that is the point where governance begins. The full treatment of the risk ladder, the value chain and the governance framework lives in our deep guide, agentic AI under the EU AI Act. The pages below break down each question in turn.
Does an AI agent fall under the EU AI Act?
Yes, fully. Article 3(1) defines an AI system as one that operates with varying levels of autonomy, so an agent that autonomously calls tools and changes its environment sits deeper inside the definition, not outside it. There is no separate category and no agent-specific exemption. Which obligations apply is decided through the ordinary risk ladder and your role in the chain. The qualification question, with examples per agent type, is covered in does an AI agent fall under the EU AI Act, and the broader governance challenge of a fast, decentralised rollout in the AI agents governance challenge.
Are you a provider or a deployer of the agent?
With agents the chain is rarely simple: a lab supplies the model, a platform supplies the agent framework, and your organisation configures the agent with its own prompts, tools and data. The party that places the system on the market is the provider, and the organisation that uses it under its own authority is the deployer, but Article 25 can shift those roles. Building an agent for your own use generally does not make you a provider, yet offering it to customers, or giving a procured agent an Annex III task its supplier never foresaw, can flip your position. The routes are set out in when do you become a provider under Article 25, when you become a deployer in when are you a deployer of an AI agent, and the distinction in general on our provider versus deployer page.
Which controls do autonomous agents need?
Six building blocks form the practical core of agent governance:
- Scoped permissions per agent, following least privilege, so an agent can only reach what its task requires.
- A deliberate, documented choice between human in the loop, where a person approves each action, and human on the loop, where a person monitors and can intervene.
- Logging that makes every agent action reconstructable after the fact.
- A tested kill switch with an incident process, so you can stop an agent that misbehaves.
- Periodic review of behaviour and risk classification, because an agent's tasks drift over time.
- Inclusion of every agent in the AI register, with purpose, model, role division, oversight model and owner.
Human oversight under Article 14 is the anchor for these controls, and it is the best design principle even where it is not yet formally mandatory. How to make oversight effective rather than ceremonial is covered in human oversight under Article 14, and the risk management system that surrounds it in the Article 9 risk management system. Agents that are rolled out without any of this are exactly the shadow AI problem described in shadow AI, the invisible governance challenge.
Who must do what: provider and deployer
The provider builds and places the agent on the market: it carries the design duties, the technical documentation, the risk management system and the transparency obligations of Article 50 at system level. The deployer uses the agent under its own authority: it carries the operational duties, meaningful human oversight under Article 14, use in line with the intended purpose, and the GDPR Article 22 boundary for decisions with legal effects. Record which party in the chain holds which duty per agent, in the contract, before an incident forces the question.
How do you assess the risk of an agent?
The task, not the autonomy, determines the classification. An agent becomes high-risk when it performs an Annex III task, such as assessing job applicants, preparing credit decisions or triaging applications for essential services. For those standalone Annex III systems the high-risk obligations apply from 2 December 2027 as a result of the Digital Omnibus, a package that was politically agreed but had not yet appeared in the Official Journal as of mid-2026, so treat the date as a planning anchor. For AI embedded in regulated products under Annex I the date is 2 August 2028.
Two assessment instruments matter for agents. A fundamental rights impact assessment under Article 27 applies to public bodies and to deployers in credit and insurance, explained in the complete guide to the Article 27 FRIA. A data protection impact assessment under the GDPR applies whenever an agent processes personal data at scale or takes automated decisions, and the difference between the two is set out in DPIA versus FRIA. Neither works without a complete inventory, which is why every agent belongs in the register described in the AI register and inventory.
Who is responsible when an agent makes a mistake?
When an agent takes a wrong step, the question of who must put it right and whom the regulator addresses follows directly from the role division you recorded. That is why the provider and deployer split matters before anything goes wrong, not after. How this plays out during real incidents, and how logging and oversight decide who answers, is covered in who is responsible when an AI agent makes mistakes. The security dimension, where an agent with broad permissions becomes an attack surface, is set out in the Dutch DPA warning covered in the regulator's warning on the security risks of AI agents.
Getting started: agent governance in three steps
Inventory every agent
List each agent in your AI register with its purpose, the model and platform it runs on, the tools and systems it can reach, and its owner. An agent that is not in the register does not exist for your governance, and agents tend to be rolled out fast and decentrally.
Classify and assess per agent
Classify each agent against the risk ladder and Annex III on the task it performs, not the vendor. Where it touches high-risk tasks, personal data at scale or automated decisions with legal effects, run the FRIA or DPIA that applies.
Put controls and oversight in place
Apply the six controls: scoped permissions, a documented in the loop or on the loop choice, logging, a kill switch, periodic review and register entry. Use Article 14 human oversight as the design principle, and make sure the people supervising have the time, information and mandate to intervene.
The full timeline and every obligation per role are in our AI Act Explorer. Organisations that want to address this structurally, from agent inventory to oversight design and chain contracts, can start with the AI Act Readiness Sprint: in two weeks you inventory your systems, classify each one against Annex III, and get a register and roadmap you can act on. Effective oversight also needs capable people, for which platforms such as LearnWize offer training with an evidence file.