The EU AI Act never mentions AI agents, yet every agent built or used in the EU falls under it, and the tools you connect to an agent can decide whether you are its deployer or its provider. The European Commission's AI Act Service Desk states that AI agents are not a separate category under the Act and that the definitions of an AI system and a general-purpose AI model are enough to cover them. What changes with agents is how the existing roles are allocated: a stack of model providers, framework suppliers, agent builders and deploying organisations, with tool use and autonomy shifting obligations between them. This map takes the agent architecture layer by layer and shows which articles apply, who holds them and what evidence they need. It is for AI platform owners, security architects and compliance leads. Status checked on 12 November 2026 against the Service Desk's consolidated text (as at 27 July 2026, including the AI Omnibus amendments). The general role rules are in the EU AI Act Provider vs Deployer Obligations Guide; this page does not repeat them.
Source note: this map summarises Regulation (EU) 2024/1689 as consolidated, the Commission's AI Act Service Desk and Commission policy pages, with status as of 12 November 2026. The Commission describes its views on agents as preliminary. It is not legal advice. Confirm against the official text before relying on it.
Key takeaways
- No agent category, no agent exemption. An agent is normally an AI system built on at least one general-purpose AI model, so AI system rules and GPAI model rules both reach it, depending on who you are in the stack.
- Tools change the intended purpose. Connecting an agent to a tool that acts in an Annex III area (for example ranking job candidates) can make it high-risk and, under Article 25(1)(c), make the organisation that did so its provider.
- Autonomy raises the oversight bar. Article 14(3) ties oversight measures to the system's "level of autonomy", and Article 14(4)(e) requires a way to interrupt it safely; for agents that means a working stop and suspension path per agent.
- Chains need contracts. Article 25(4) requires written agreements between a high-risk system's provider and third parties supplying models, tools, services or components, with a free and open-source exception that does not cover GPAI models.
- Transparency already applies. From 2 August 2026 an agent that interacts with people or generates content is subject to Article 50, whatever its risk class. The Digital Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026) adds Article 111(4), which gives systems placed on the market before that date until 2 December 2026 for the Article 50(2) marking duty; it does not move the Article 50(1) interaction duty. High-risk duties follow on 2 December 2027 (Annex III) and 2 August 2028 (Annex I).
Regulations and frameworks at a glance
| Provision | What it says | Why it bites for agents | Holder | Applies from |
|---|---|---|---|---|
| Art. 3(1), 3(63), 3(66), 3(68) | AI system "designed to operate with varying levels of autonomy"; GPAI model; GPAI system; downstream provider integrating a model into its AI system | Agent builders that integrate a third-party model are downstream providers of the agent as an AI system | Agent builder | In force |
| Art. 3(13) | Reasonably foreseeable misuse includes misuse arising from foreseeable human behaviour or interaction with other systems | Multi-agent and tool interactions are part of the foreseeable misuse analysis | Provider | With the relevant obligation |
| Art. 5(1)(a), (b) | Bans harmful manipulation and exploitation of vulnerabilities | The Service Desk notes these may require safeguards in agent design | Provider and deployer | 2 February 2025 |
| Art. 6(2), 6(3) | Annex III systems are high-risk unless a derogation applies; profiling is always high-risk | An agent's tools and tasks decide whether it is an Annex III system | Provider (documents the assessment) | 2 December 2027 |
| Art. 12 | Automatic logging over the system's lifetime | Agent traces of tool calls and decisions become a design requirement | Provider builds; deployer keeps | 2 December 2027 (Annex III) |
| Art. 14 | Oversight commensurate with risks, autonomy and context; stop control | Autonomy is a named factor | Provider designs; deployer staffs | 2 December 2027 (Annex III) |
| Art. 25 | Third parties become providers; cooperation; written agreements | Tool use and repurposing; layered suppliers | All operators in the chain | With Chapter III |
| Art. 26 | Deployer duties, including oversight staff, monitoring, suspension and logs kept at least six months | The organisation running the agent | Deployer | 2 December 2027 (Annex III) |
| Art. 50 | Disclosure of AI interaction, marking of synthetic content, deployer disclosures | Agents that email, chat, call or publish | Provider (50(1), (2)); deployer (50(3), (4)) | 2 August 2026 |
| Arts. 53 and 55 | GPAI provider duties; extra duties for models with systemic risk | The Service Desk names autonomy and tool use as possibly decisive for systemic-risk designation | Model provider | 2 August 2025 |
Who holds what in an agent stack
Map roles per system and per layer. The same organisation can hold several roles at once.
| Layer | Typical party | Likely role | Main obligations |
|---|---|---|---|
| Foundation model | Model developer | GPAI model provider | Art. 53: technical documentation, information for downstream providers (Annex XII), copyright policy, training content summary; Art. 55 if systemic risk |
| Agent framework, tool gateway, MCP servers | Platform or open-source project | Supplier of tools, services or components (and provider if it places an AI system on the market) | Art. 25(4) written agreement with the provider of a high-risk system, unless free and open-source |
| Packaged agent product | Software vendor | Provider of the AI system (downstream provider of the model) | Art. 50(1), (2); Chapter III if high-risk, including Arts. 12 and 14 by design |
| Agent built in-house | Enterprise AI team | Provider (putting into service for own use) and deployer | Both sets: design duties and operational duties |
| Agent configured from a vendor product | Enterprise business unit | Deployer, or provider if Art. 25(1) triggers | Art. 26 and Art. 50(3), (4); provider duties if it changes intended purpose |
| Peer agent or external API called by the agent | Third party | Depends on what it is; a plain API is not an AI system | Contract terms; Art. 25(4) if it is a component of a high-risk system |
The most common surprise is the in-house agent. Building an agent on a vendor model and putting it into service for your own staff or customers makes you the provider of that agent as an AI system, even though you never sell it. Whether the agent is high-risk then depends on its tasks, which is where tool use comes in.
How tool use and autonomy move the roles
Tools and intended purpose
Intended purpose (Art. 3(12)) is the use the provider intends, including context and conditions of use stated in its materials. A general-purpose agent is usually not high-risk. Give it a tool that filters CVs, scores credit applications or decides access to essential services, and the agent now performs an Annex III use. Article 25(1)(c) makes whoever changed the intended purpose of an AI system, including a general-purpose AI system, so that it becomes high-risk the provider of that high-risk system.
- Adding a tool is a classification event: treat every new tool or connector that touches an Annex III area as a trigger for an Article 6 assessment.
- The Article 6(3) derogation is narrow: an agent that only performs a narrow procedural task, improves a completed human activity, detects patterns without replacing human assessment, or performs a preparatory task may fall outside high-risk, but an agent that profiles natural persons is always high-risk, and the provider must document the assessment before use (Art. 6(4)).
- The initial provider's position: under amended Article 25(2) the original vendor must cooperate with the new provider (documentation, known limitations and failure modes, targeted technical access), unless it clearly specified that its system is not to be changed into a high-risk system. Check the vendor's terms before repurposing.
Autonomy and change after deployment
- Substantial modification: Article 3(23) covers changes after placing on the market that were not foreseen in the initial conformity assessment and affect compliance or intended purpose. New tools, broader permissions or a new model can qualify. Pre-declare the change envelope (allowed model versions, tool families, autonomy levels) in the technical documentation so routine updates stay inside it.
- Oversight scaled to autonomy: Article 14(3) allows oversight built in by the provider, identified by the provider for the deployer to implement, or both. For agents the practical split is: provider builds approval gates, action limits and a stop control; deployer assigns named people with competence, training and authority (Art. 26(2)). See the EU AI Act Article 14 Guide.
- Interrupt and suspend: Article 14(4)(e) requires the ability to intervene or stop the system safely, and Article 26(5) requires the deployer to suspend use where it has reason to believe the system presents a risk. Both assume you can stop one agent quickly. See the AI Agent Kill Switch and Containment Guide.
Chained models and multi-agent systems
- One system or several: an orchestrator calling sub-agents may be one AI system with several model components, or several systems with different providers. Decide and document the boundary, because it decides who signs the conformity assessment.
- Information flows down the chain: Article 53(1)(b) requires GPAI model providers to give downstream providers enough information about capabilities and limitations to meet their own obligations. Ask for it per model in the chain.
- Foreseeable interaction: because reasonably foreseeable misuse includes interaction with other systems (Art. 3(13)), risk management must cover what happens when a peer agent sends manipulated output. See the Multi-Agent and A2A Security Guide.
Transparency obligations for agents
| Agent behaviour | Article | Holder | What to do |
|---|---|---|---|
| Chats, emails, messages or calls people directly | 50(1) | Provider | Design so people are informed they are dealing with an AI system, unless obvious to a reasonably well-informed person |
| Generates text, images, audio or video | 50(2) | Provider | Machine-readable marking that output is artificially generated, where technically feasible |
| Uses emotion recognition or biometric categorisation | 50(3) | Deployer | Inform the people exposed |
| Publishes text to inform the public on matters of public interest, or produces deep fakes | 50(4) | Deployer | Disclose; text exception where a person holds editorial responsibility after human review |
Information must be given clearly at the latest at the first interaction (Art. 50(5)). For agents acting on someone's behalf, such as an agent that negotiates or books with a third party, the third party is the person interacting with it, so the disclosure has to reach them, not only the user who launched the agent. See the EU AI Act Article 50 Transparency Obligations Guide.
GPAI models with systemic risk and agentic capability
The Service Desk FAQ states that autonomy and tool use can be decisive when designating a GPAI model as having systemic risk (Art. 51(1)(b) and Annex XIII), and that providers of such models must manage risks including autonomous capabilities and agentic use, as described in the Safety and Security chapter of the GPAI Code of Practice. Article 55 adds model evaluation with adversarial testing, systemic risk assessment and mitigation, serious incident reporting to the AI Office and cybersecurity protection. Enterprises fine-tuning models for agents should note the Commission guidelines: only significant modifications make a modifier a GPAI model provider. See the EU General-Purpose AI (GPAI) Code of Practice Guide.
Where identity fits
Several obligations assume you can tell one agent from another. Logs under Article 12 must trace the system's functioning, deployers must keep them at least six months (Art. 26(6)), and suspension under Article 26(5) must be targeted. A shared service account across agents defeats all three.
| Obligation | Identity control that evidences it |
|---|---|
| Art. 12 logging; Art. 26(6) retention | Distinct identity per agent and version; tool calls logged with agent ID, delegating user and task ID |
| Art. 14(4)(e) stop; Art. 26(5) suspension | Revocable credentials per agent, so one agent can be cut off without stopping others |
| Art. 26(2) oversight by competent people | Approver roles bound to named, trained staff; approvals logged |
| Art. 25(1)(c) classification trigger | Tool and permission grants recorded, so new Annex III capabilities are visible |
See the AI Agent Audit Trails for Regulators Guide and the Agentic AI Identity Guide.
Penalties by role
| Breach | Maximum fine (Art. 99) |
|---|---|
| Prohibited practices (Art. 5) | EUR 35 million or 7% of worldwide annual turnover, whichever is higher |
| Provider (Art. 16), deployer (Art. 26), Art. 25(2) and (4) cooperation and agreements, transparency (Art. 50) | EUR 15 million or 3%, whichever is higher |
| Incorrect or misleading information to authorities | EUR 7.5 million or 1%, whichever is higher |
For SMEs, including start-ups, the lower of the amount or percentage applies (Art. 99(6)); the AI Omnibus added a similar rule for small mid-caps for the 15 million and 7.5 million bands (Art. 99(6a)).
Compliance steps
- Inventory agents with their stack: for each agent record the models, framework, tools, autonomy level and the people it interacts with. See the Audit Readiness for AI Agents and NHIs guide.
- Assign roles per agent and layer: provider, downstream provider, deployer or supplier, with the reasoning written down.
- Run an Article 6 assessment per agent: list tools that touch Annex III areas, check the Article 6(3) conditions and the profiling exception, and document the result before use.
- Put tool onboarding through a gate: any new tool or connector triggers a classification check and a substantial modification check; roll back by disabling the tool, not the agent.
- Close Article 50 gaps now: add AI disclosure to every agent channel facing people and marking for generated content; these duties already apply.
- Review supplier contracts: for agents that are or may become high-risk, put Article 25(4) terms in place with model and tool suppliers, and check vendor terms that forbid high-risk repurposing.
- Build oversight and stop paths: named overseers, approval gates for high-impact actions, per-agent suspension; test them in a pilot before 2 December 2027.
- Measure: track share of agents with a documented role and classification (target 100%), tools onboarded without a classification check (target zero), agents with Article 50 disclosure live, and time to suspend a single agent in a drill.
Common failure patterns
- "We only use the model": an in-house agent is treated as vendor responsibility, when the organisation is its provider.
- Silent repurposing: a business unit adds an HR or credit tool to a general assistant, triggering Article 25(1)(c) without compliance knowing.
- Disclosure only to the user: the person who launched the agent knows it is AI; the customer or supplier it contacts does not.
- Shared agent identities: logs and suspension cannot isolate one agent, undermining Articles 12, 14 and 26.
- Waiting for agent-specific rules: the Commission's view is preliminary, but the existing articles already apply.
Framework mapping
| Theme | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Legal and regulatory requirements understood | GV.OC-03 | PM-9 | 5.31 |
| Roles and responsibilities, including suppliers | GV.RR-02, GV.SC-02 | SA-9 | 5.2, 5.20 |
| Logging of agent activity | DE.CM-09 | AU-2, AU-12 | 8.15 |
| Least privilege for agent tools | PR.AA-05 | AC-6 | 8.2 |
Practitioner checklist
- Record every agent's models, tools, autonomy level and audiences.
- Write down your role per agent and per layer of its stack.
- Run and document an Article 6 assessment whenever a tool touches an Annex III area.
- Gate new tools with a classification and substantial modification check.
- Deploy Article 50 disclosure on every agent channel that reaches people.
- Put Article 25(4) agreements in place for high-risk agent components.
- Give each agent its own revocable identity and keep its logs at least six months.
- Drill single-agent suspension and record the time taken.
Standards and references
- European Commission AI Act Service Desk: How are AI agents addressed within the AI Act?
- European Commission AI Act Service Desk: Article 25 Responsibilities along the AI value chain
- European Commission AI Act Service Desk: Article 6 Classification rules for high-risk AI systems
- European Commission AI Act Service Desk: Article 14 Human oversight
- European Commission AI Act Service Desk: Article 26 Obligations of deployers of high-risk AI systems
- European Commission AI Act Service Desk: Article 50 Transparency obligations
- European Commission AI Act Service Desk: Article 113 Entry into force and application
- European Commission: AI Act regulatory framework
This guide summarises the EU AI Act as it applies to AI agents, as of 12 November 2026, and is not legal advice. Related NHI Mgmt Group resources: EU AI Act Provider vs Deployer Obligations Guide · EU AI Act High-Risk AI Systems Guide · Agentic AI Compliance Guide · EU AI Act Implementation Timeline Tracker