TL;DR: The EU AI Act has no category for AI agents, so EU AI Act compliance for AI agents depends on the agent's intended purpose, your role as provider or deployer, and what the agent does to people. This guide follows one recruiting agent through the five questions the Act forces you to answer, turns the answers into operational controls and evidence, and closes with a six-step AI compliance framework. The high-risk requirements apply from 2 December 2027 for Annex III uses, while the Article 50(1) duty to tell people they are interacting with an AI system already applies from 2 August 2026 to agents that interact with them. Prediction Guard, a sovereign AI control plane, supplies the operational controls and evidence behind several of those duties. Nothing here is legal advice.
The EU AI Act has no category for AI agents. That is the first thing to understand about it, and it cuts both ways. Nothing exempts an agent for being autonomous, and nothing makes it high-risk for being an agent. What decides your duties is the agent's intended purpose, your role in relation to it, and what it does to people. Prediction Guard, a sovereign AI control plane that runs inside your boundary, supplies the runtime controls and records behind several of those duties, though it does not classify the agent or prepare the conformity assessment.
This guide is for regulated enterprise AI teams working out EU AI Act compliance for AI agents. It follows one example, a recruiting agent, through the five questions the Act forces you to answer, and then turns the answers into operational controls for AI agent governance and a short AI compliance framework. It covers the main AI Act requirements that bite on agents, how risk assessment works when the thing being assessed acts on its own, and what regulatory compliance looks like as evidence and not as intent. In practice that comes down to operational control of agents: knowing what each one may do, being able to stop it, and being able to prove both. A disclosure: Prediction Guard publishes this guide and builds a sovereign AI control plane, which appears in one section. The Act's text and the Commission's guidance are sourced to their own pages, and none of this is legal advice.
What the Act Says About Agents, and What It Leaves Out
The Commission's AI Act FAQ is direct: AI agents are not a separate category of AI under the Act. Its definitions of an AI system and of a general-purpose AI model are broad enough to cover them, so the rules for both apply. Typically an agent contains at least a general-purpose AI model and counts as an AI system because it has an interface. The FAQ also notes that "AI agent" is used inconsistently in public debate.
Which rules apply, and from when, depends on what the agent does:
| Rule | Applies to | Status as of November 2026 |
|---|---|---|
| Prohibited practices (Article 5), original list | Any system | In force since 2 February 2025 |
| New prohibitions on generating non-consensual intimate content and child sexual abuse material, added by Regulation (EU) 2026/1744 | Systems used to generate that content | Apply from 2 December 2026 |
| General-purpose AI model obligations | The provider of the underlying model | In force since 2 August 2025 |
| Article 50(1): informing people they are interacting with an AI system | Providers of systems intended to interact directly with people, including agents | Applies from 2 August 2026 |
| Article 50(2): marking synthetic audio, image, video, or text output in a machine-readable format that enables its detection | Providers of systems that generate that content | Applies from 2 August 2026, with until 2 December 2026 for generative systems already on the market before that date |
| Article 50(4): disclosing deepfakes and certain published AI-generated text | Deployers | Applies from 2 August 2026 |
| High-risk requirements (Chapter III) | Systems in Annex III uses | From 2 December 2027, and from 2 August 2028 for Annex I products, under Regulation (EU) 2026/1744 |
The 2 December 2026 date is a grace period for marking by generative systems already on the market. It is not a general deadline for conversational or autonomous agents.
The Commission's AI Act page tracks these dates, which moved once already. The practical consequence is that high-risk duties are a year away and the work behind them takes months, while the duty to tell people they are interacting with an AI system already applies to agents that interact with them.
EU AI Act Compliance for AI Agents: One Example, Five Questions
The example is a recruiting agent at a regulated bank in the EU. It reads CVs, ranks candidates, schedules interviews, and drafts rejection emails. It calls three tools, an applicant tracking system, a calendar, and email, and it runs on a third-party general-purpose model through an API. Every agent has its own version of these five questions.
Question 1: What Is the Intended Purpose, and Is the Agent High-Risk?
Classification under the Act starts with intended purpose, not with technology, and it is a different step from risk management. Article 6 decides whether a system is high-risk. Article 9 then requires the provider of a high-risk system to run a continuous risk management process. Classification is the first risk assessment an agent gets, and everything else depends on it. Annex III point 4 lists AI systems intended for the recruitment or selection of natural persons, including analysing and filtering applications and evaluating candidates. Ranking CVs is squarely inside that. The recruiting agent is high-risk, and because ranking people is profiling, the Article 6(3) exemption for narrow or preparatory tasks does not rescue it.
The Commission's draft guidelines on classification, published 19 May 2026 and still non-binding, matter here for agents specifically. As summarized by Covington, they say that complex systems made of several AI components, including agentic AI systems, must be assessed as a whole. They also say human involvement does not by itself take a system out of the high-risk category, and that broadly marketed general-purpose systems may be treated as intended for foreseeable high-risk uses unless the provider consistently excludes them. A boilerplate disclaimer in the terms of service is not enough if the product's positioning promotes the use. As of late October, no final version had been published in the sources reviewed, so treat the drafts as the Commission's current thinking and not as settled law.
Two consequences follow. A scheduling-only agent would generally sit outside high-risk, and adding ranking changes that. And "we only recommend, a human decides" is not a safe harbor.
Question 2: What Is Your Role?
The Act assigns duties by role, and an agent can put you in a different one than you expect:
| Role | When it applies to an agent | What it carries |
|---|---|---|
| Provider of the agent system | You develop the agent, or have it developed, and place it on the market or put it into service under your own name or trademark | The high-risk requirements, a quality management system, conformity assessment, registration, post-market monitoring, and incident reporting |
| Deployer | You use an agent under your authority | The deployer duties in Article 26 |
| General-purpose model provider | You supply the underlying model | The model-level duties, which do not cover the agent built on it |
Putting into service includes using the system yourself, so a bank that develops a recruiting agent and uses it internally under its own name is both its provider and its deployer. Building an internal component does not by itself make an organization the provider of the whole system. Article 25 can also move you from deployer to provider. A deployer is treated as the provider of a high-risk system if it puts its own name or trademark on it, makes a substantial modification that leaves it high-risk, or changes the intended purpose of a system that was not high-risk so that it becomes high-risk. If the bank repoints a general assistant at ranking CVs, it has done the last of these. Procurement approval for one purpose does not cover a team that repurposes the tool afterward.
Question 3: Which AI Act Requirements Follow?
For a high-risk agent, the requirements split by role. Duties for the general-purpose model sit with its provider and are separate from these system-level duties. These are the main system-level ones, and the first column is where agent-specific questions arise:
| Duty | Provider of the high-risk agent | Deployer |
|---|---|---|
| Risk management (Article 9) | A continuous process across the lifecycle | Use within the provider's intended purpose |
| Data governance, documentation, and quality management (Articles 10, 11, 17) | Required | Not applicable |
| Record-keeping (Article 12) | Design the system to record events automatically | Keep the logs under your control for at least six months, subject to exceptions |
| Human oversight (Article 14) | Design for effective oversight | Assign it to people with the competence, training, and authority |
| Accuracy, robustness, and cybersecurity (Article 15) | Required | Monitor operation against the instructions |
| Information and transparency | Instructions for use that give deployers the information they need to interpret and operate the system, which is one part of the Act's transparency duties | Inform workers' representatives before workplace use, and inform individuals subject to the decisions |
| Monitoring and incidents (Articles 72 and 73) | Post-market monitoring and serious incident reporting | Report and cooperate |
Some deployers carry more. Article 27 requires a fundamental rights impact assessment from public bodies, private entities providing public services, and certain deployers of creditworthiness and life or health insurance risk-assessment systems. The point for agents is that the provider's column assumes you can design for oversight and logging, and an agent that calls tools and hands work to other agents makes both harder than they are for a single model call.
Question 4: What Must Be True of the Agent Itself?
Three requirements change character when the system acts:
- Oversight has to be able to stop it. Article 14 asks for effective human oversight, including the ability to disregard or override an output and to interrupt the system through a stop button or similar procedure. For the recruiting agent, that means a recruiter can override a ranking and halt the agent mid-run, and that someone has the competence and authority to do so.
- Logging has to follow the actions. Article 12 requires automatic recording of events over the system's lifetime. For an agent, the events that matter are tool calls, data access, and handoffs, not just model inputs and outputs. Prediction Guard's guide to audit log expectations under the Act goes deeper.
- Robustness has to include manipulation. A CV is untrusted input that an agent reads and acts on. Text hidden in a CV that instructs the agent to rank it first is a goal hijack, the first entry in the OWASP list that Prediction Guard's overview of key OWASP agentic risks covers. The Act does not name prompt injection. It is an implementation risk that bears on robustness, because Article 15 expects high-risk systems to be resilient against attempts to alter their use, outputs, or performance by exploiting system vulnerabilities.
Change is the other agent-specific issue. A swap of model, a new tool, a revised prompt, or a widened scope can change what the agent does. The Act's concept of substantial modification, a change not foreseen in the original conformity assessment that affects compliance or the intended purpose, is the test to apply, so treat these as events that trigger reassessment.
Question 5: What Applies Even if the Agent Is Not High-Risk?
Article 50 applies to agents whether or not they are high-risk, but it is narrower than it is often read, so take the paragraphs one at a time. Article 50(1) requires providers of systems intended to interact directly with natural persons to design them so that those people are informed they are interacting with an AI system, unless that is obvious. Article 50(2) is a different duty: marking synthetic audio, image, video, or text output in a machine-readable format so that it is detectable as artificially generated or manipulated. Article 50(4) concerns deployers who publish deepfakes, or AI-generated text meant to inform the public on matters of public interest.
For agents, the Commission's final transparency guidelines, published on 20 July 2026 and non-binding, provide further interpretation. They add something that is not in the Article's wording. The guidelines interpret the Article 50(1) obligation to mean that an agent should disclose both its artificial nature and the person on whose behalf it is acting, and that where a provider cannot determine in advance whether an agent will interact with a person, it should be designed to disclose itself in every situation where that is reasonably likely. The guidelines also say that a line buried in the terms of service does not satisfy the duty, and they address multi-agent architectures too.
How this applies to the recruiting agent depends on what it actually does. If it communicates directly with candidates, the provider has to assess Article 50(1) and the Commission's guidance on agent identity. If it only prepares drafts for a recruiter to review and send, those drafts do not necessarily trigger Article 50(1), because it concerns systems that interact directly with people. Article 50(4) is aimed at text published to inform the public on matters of public interest, not ordinary recruitment correspondence.
How Prediction Guard Turns Obligations into Controls: AI Agent Governance in Practice
The Act states outcomes and does not prescribe a technical architecture. The following controls are recommended implementation approaches for translating the Act's requirements into verifiable operational practices. They should not be interpreted as a prescribed technical architecture under the regulation. The table uses Prediction Guard's vocabulary for control layers, defined where each term first appears:
| Requirement | What it asks of the agent | Recommended control |
|---|---|---|
| Human oversight (Article 14) | An overseer can understand, override, and stop the agent | Agent Behavior Controls (what an agent may do, in what sequence, against which systems) with approval points, plus containment that pauses, scopes down, or revokes the agent, and a recorded intervention each time it is used |
| Record-keeping (Article 12) | Automatic recording of events across tool calls and handoffs | Immutable Audit Logs (tamper-resistant records of each action and control decision) tied to each agent's identity, with an Evidence bundle (what was attempted, which control acted, and what was contained) for each intervention |
| Robustness (Article 15) | Resilience against manipulation, including injected instructions | Component Input/Output Controls (what passes into and out of a model or tool), tested against attack scenarios |
| Risk management (Article 9) | Risks identified, assessed, and reviewed across the lifecycle | A registry with a named owner, purpose, data scope, and review date for each agent, and a blast radius assessment (how much damage one agent's failure could cause) before deployment |
| Deployer duties (Article 26) | Use per instructions, assigned oversight, retained logs | Delegated authority (the scoped, time-bound authority an action runs under, traceable to an accountable human) and log retention under your control |
| Transparency (Article 50(1)) | Inform people they are interacting with an AI system, and, under the Commission's guidance for agents, on whose behalf the agent acts | A unique agent identity, disclosed at the interface at first interaction |
A sovereign AI control plane is the architecture that identifies, authorizes, enforces, meters, records, and contains agent actions, running inside your boundary. It supplies controls and records for several of these rows. It does not classify the agent, prepare the conformity assessment, or write the technical file, so the Article 9 and 17 work still needs an assessment process. Prediction Guard's published limits apply too: it enforces on routed traffic, per-invocation authorization at the tool server is not yet generally available, and human approval gates are on the roadmap, as its blast radius guide states. For the Article 14 row, ask what exists today. The principle behind the authority row is least agency: the minimum authority a task needs.
An AI Compliance Framework for Agents in Six Steps
Regulatory compliance for enterprise AI agents is easier as a repeatable routine than as a one-off project:
- Inventory every agent, including ones teams adopted without central purchasing, with its purpose, owner, model, tools, data, and the people affected.
- Classify by intended purpose, and document the Article 6 assessment, including why an exemption does or does not apply.
- Assign the role for each agent and each supplier, and put the allocation of responsibilities in contracts.
- Derive the duties for that role and risk tier, using the tables above, including, for a provider of a high-risk agent, the technical documentation and the conformity assessment.
- Build the controls and the evidence together, so each requirement has a control and a record, as in this AI compliance evidence framework.
- Treat changes as triggers. A new tool, model, prompt, or purpose reopens steps 2 through 5.
What Is Still Unsettled
Several things can still move. The classification guidelines are drafts. EN 18286:2026, whose reference the Commission published in the Official Journal in October 2026 and announced on 19 October, is now an adopted harmonised standard, and a quality management system built on it carries a presumption of conformity with the Article 17 requirements it covers. It does not establish conformity with the rest of the Act, and most other requirement areas still lack a harmonised standard. The Commission's own FAQ calls the vocabulary around agents inconsistent. Build on the Act's text, check developments before relying on any date, and confirm interpretations with counsel.
Regulatory Compliance for Agents Is Evidence, Not Intent
Plan around the question an examiner will ask of any agent: what was it allowed to do, who gave it that authority, and what record shows what happened. An agent that can be stopped, that leaves a record of its actions, and that has a named owner has several important foundations for compliance, and that is the shape of operational control of agents. But those controls are only part of the picture. The wider task is to establish that the system meets its requirements throughout its lifecycle, with evidence to support every claim.
How Prediction Guard Solves This
Prediction Guard gives regulated enterprises operational control of their AI agents: one sovereign AI control plane that identifies, authorizes, enforces, meters, records, and contains every action an agent takes, running inside the customer's own boundary. For the duties in this guide, that means three things.
- Human oversight. Agent Behavior Controls with approval points, plus containment that pauses, scopes down, or revokes an agent in one action, support the oversight Article 14 asks for.
- Record-keeping. Immutable Audit Logs tied to each agent's identity, with an Evidence bundle for each intervention, support the automatic recording Article 12 requires across tool calls and handoffs.
- Robustness. Component Input/Output Controls screen what passes into and out of a model or tool, which supports the resilience against manipulation that Article 15 expects.
Because the control plane runs inside your boundary, the records stay in your own estate. It does not classify the agent, prepare the conformity assessment, or write the technical file, and it enforces on traffic routed through it, so the Article 9 and 17 work still needs your own assessment process.
Questions About EU AI Act Compliance for AI Agents
1. Does the EU AI Act regulate AI agents?
Yes, but not as a separate category. The Commission's AI Act FAQ says AI agents are not a separate category of AI under the Act. An agent typically contains at least a general-purpose AI model and counts as an AI system because it has an interface, so the rules for both apply. What decides your duties is the agent's intended purpose, your role in relation to it, and what it does to people.
2. When do the EU AI Act requirements apply to AI agents?
High-risk requirements apply from 2 December 2027 for Annex III uses, and from 2 August 2028 for Annex I products, under Regulation (EU) 2026/1744. The Article 50(1) duty to inform people they are interacting with an AI system applies from 2 August 2026 to systems intended to interact directly with people, including agents. The 2 December 2026 date is a grace period for marking by generative systems already on the market, not a general deadline for agents.
3. Is an AI agent high-risk if a human reviews its output?
Not necessarily on that basis. The Commission's draft guidelines, which are still non-binding, say human involvement does not by itself take a system out of the high-risk category. Classification starts with intended purpose: an agent that ranks CVs falls under Annex III point 4, while a scheduling-only agent would generally sit outside high-risk.
4. What does the EU AI Act require for logging and human oversight of AI agents?
Article 12 requires automatic recording of events over the system's lifetime, and for an agent the events that matter are tool calls, data access, and handoffs, not just model inputs and outputs. Article 14 asks for effective human oversight, including the ability to disregard or override an output and to interrupt the system through a stop button or similar procedure.
5. Does an AI agent have to tell people it is an AI?
Article 50(1) requires providers of systems intended to interact directly with natural persons to design them so those people are informed they are interacting with an AI system, unless that is obvious. The Commission's final transparency guidelines, which are non-binding, interpret this to mean an agent should disclose both its artificial nature and the person on whose behalf it is acting. A line buried in the terms of service does not satisfy the duty.