The EU AI Act and AI Agents: How the Act Applies to Agentic AI, Who Is Responsible and What to Do Before December 2027

The EU AI Act applies to AI agents, but not as a category of their own. An agent is an AI system under Article 3(1), usually built on a general-purpose AI model, and its obligations follow from its intended purpose: a prohibited practice, a high-risk use under Annex III or Annex I, an Article 50 transparency case, or minimal risk. Whoever puts the agent into service under its own name is its provider, and the organisation using it is the deployer. After the Digital Omnibus, Annex III high-risk duties apply from 2 December 2027.

This guide is for the people who sign off on agents in a regulated organisation. It separates what the text settles from what remains open: the Commission describes its own thinking on agents as “only preliminary at this stage”, and its high-risk classification guidelines are still a draft. Nothing here is legal advice.

How the AI Act sees an AI agent

Article 3(1) defines an AI system as a machine-based system “designed to operate with varying levels of autonomy” that infers from its input how to generate predictions, content, recommendations or decisions that can influence physical or virtual environments. An agent fits without strain: it receives a goal from a person, an application, a schedule or an event, plans steps, calls tools and acts on the results. The Commission’s guidelines on the AI system definition, adopted on 29 July 2025, treat any system designed with a reasonable degree of independence of action as meeting the autonomy element, so the real question for an agent is never whether it is in scope but which rules its use triggers.

The AI Act Service Desk answers the agent question in its FAQ: agents are not a separate category, an agent typically contains a general-purpose AI model and is itself an AI system, and the rules for both apply. The phrase “agentic AI” appears in the amended Act exactly once, in Annex XIV, a list of codes for notified bodies that the Digital Omnibus added. Every agent therefore has two layers to analyse: the model, with its own provider and duties, and the system around it (prompts, tools, memory, permissions and workflow), which is classified by purpose.

Four classification paths for an agent

The paths stack. A high-risk agent that talks to applicants carries Chapter III duties and Article 50 duties at the same time, and the Article 50 explainer for enterprise AI covers the disclosure side in detail. Banned uses are listed with examples in the guide to Article 5 prohibited practices.

Tool access changes the class

The model underneath does not decide the class; the job does. The same model can sit inside an assistant that drafts emails, which is minimal risk, or inside an agent with read access to an applicant-tracking system and a tool that moves candidates between stages, which is recruitment under Annex III point 4(a). The sector analysis in AI Act rules for HR and recruitment and the one for credit scoring and insurance pricing show where those lines fall. Every new tool, data source or permission is therefore a classification question, and the check belongs in the change process for tools.

The Article 6(3) filter lets an Annex III system escape high-risk status when it performs a narrow procedural task, improves a completed human activity, detects deviations from earlier decision patterns without replacing human review, or prepares an assessment, provided it does not profile people; the provider must document that assessment in advance. For agents the filter is fragile. The Commission’s draft guidelines on high-risk classification, published for consultation on 19 May 2026, say that split architectures are assessed as a whole and extend that principle to agentic systems whose linked actions serve a high-risk purpose together, so a component that would pass the filter alone cannot use it inside such a chain. The guidelines were due by 2 February 2026 under Article 6(5) and were still not final on 6 November 2026. A quick first pass is possible with the EU AI Act compliance checker.

The model layer: duties that stay with the model provider

The general-purpose model under an agent has its own provider, its own obligations and its own supervisor, the AI Office. Since 2 August 2025, Article 53 has required model providers to keep technical documentation, give downstream providers the information they need to understand capabilities and limits, maintain a copyright policy and publish a summary of training content. Models with systemic risk add evaluation, adversarial testing, risk mitigation, serious-incident reporting and cybersecurity under Article 55. The Service Desk notes that a model’s autonomy and the tools it can reach can be decisive when the Commission designates it as presenting systemic risk.

When does a company that adapts a model become a model provider? The Commission’s guidelines on general-purpose AI obligations, whose content was approved on 18 July 2025 and which were formally adopted on 19 November 2025 as C(2025) 7719, answer it with an indicative criterion. A downstream modifier becomes the provider of the modified model only if the change significantly alters its generality, capabilities or systemic risk, and the indicative criterion for that is modification compute above a third of the compute used to train the original. Where that figure is unknown, the benchmark is a third of 10²³ FLOP, or of 10²⁵ FLOP for a model with systemic risk, and the documentation and training-data duties that follow are limited to the modification. The Commission expects few modifications to reach the threshold today.

Prompting, retrieval, tool wiring and agent configuration leave the weights untouched, so they do not create model-provider duties. For fine-tuning through a vendor’s interface, the guidelines treat the question case by case, with control over the weights an important factor. Staying below the threshold settles only the model question: the company remains the provider of the agent system it builds.

Roles in an agent stack

Article 25: when a deployer becomes the provider

A distributor, importer, deployer or other third party becomes the provider of a high-risk system if it puts its name or trademark on it, makes a substantial modification to it, or changes the intended purpose of a system that was not high-risk, including a general-purpose AI system, so that it becomes high-risk. The last case is the usual agent trap: configuring a general-purpose assistant as an agent that ranks applicants makes the organisation that did it the provider of a high-risk system. The original provider then stops being the provider of that specific system but must cooperate, with technical documentation, known limitations and failure modes and targeted technical access, unless it clearly specified that the system must not be turned into a high-risk one. The Omnibus inserted Article 99(4)(da), so breaches of these Article 25(2) and (4) duties can now draw fines of up to EUR 15 million or 3% of worldwide turnover; the AI Act penalty tiers explain how those caps work.

What deployers must do under Article 26

For Annex III agents these duties apply from 2 December 2027:

• Instructions for use (26(1)): run the agent only within the provider’s documented purpose and conditions.
• Human oversight (26(2)): assign it to people with the necessary competence, training and authority, and support them. For an agent that means reviewers who can stop or reverse an action, not observers; the human oversight requirements and approval patterns for agents show how to design them.
• Input data (26(4)): where the deployer controls the input, keep it relevant and sufficiently representative for the purpose.
• Monitoring (26(5)): watch the system against the instructions; if it may present a risk, inform the provider or distributor and the market surveillance authority and suspend use, and report serious incidents to the provider first. Financial institutions meet the monitoring duty through their internal-governance rules under financial services law.
• Logs (26(6)): keep the logs the system generates, to the extent they are under the deployer’s control, for at least six months. The design of an AI agent audit trail covers what to capture.
• Workers (26(7)): before a high-risk system is put into service or used at the workplace, employers inform workers’ representatives and the workers affected.
• People affected (26(11)): tell people when an Annex III system makes or assists decisions about them.

The fundamental rights impact assessment

Article 27 requires a fundamental rights impact assessment before first use from deployers that are bodies governed by public law or private entities providing public services, and from deployers of credit-scoring or life and health insurance pricing systems. Critical infrastructure uses are excluded. The assessment describes the processes, the period and frequency of use, the people affected, the specific risks of harm, the human oversight measures and the response if those risks materialise; the results go to the market surveillance authority, and an existing data protection impact assessment can be cross-referenced. For an agent, the assessment should name its tools and show where the human checkpoint sits. A worked structure is in the FRIA template.

Questions the Act leaves open for agents

Dynamic behaviour and substantial modification

A substantial modification is a change after placing on the market that the initial conformity assessment did not foresee and that affects compliance with the Chapter III requirements or alters the intended purpose. A high-risk system needs a new conformity assessment after one, although changes pre-determined and documented at the initial assessment do not count for systems that keep learning (Article 43(4)). Agents change in ways the drafters only partly anticipated: new tools, a new model version, an edited system prompt, a higher autonomy level. No guidance yet says which of these is substantial, so list the changes planned and tested in advance in the technical documentation and send every other change through change control with a fresh classification check. A deployer that makes a substantial modification becomes the provider.

Who is responsible in a multi-agent chain

The Act assigns duties per AI system, not per agent. Under the Commission’s draft view, agents that together prepare or take a high-risk decision form one configuration for classification, and the organisation that assembles it and puts it into service under its own name is the provider of the whole. Agents bought from others become components whose suppliers owe information under Article 25(4) when the result is high-risk. The cumulative risk of such chains is covered in the companion guide to agentic AI risk management.

Third-party tools and MCP servers

The Act never mentions MCP or tool protocols. A tool server, connector or API that a high-risk agent depends on counts as a tool, service, component or process under Article 25(4), so provider and supplier need a written agreement on information, capabilities and technical access, except for tools made public under a free and open-source licence. Article 15(5) also requires high-risk systems to resist attempts to alter their use, outputs or performance by exploiting vulnerabilities, including poisoned data and inputs crafted to cause mistakes, and a compromised tool returning manipulated text is one such route. Treat each MCP server as a supplier with a named owner, a pinned version and an approved scope, and log every call.

What the Commission has said about agents

As of 6 November 2026 there are no agent-specific guidelines, codes or implementing acts. Three Commission texts address agents directly:

• The Service Desk FAQ confirms that the existing rules apply, highlights the bans on harmful manipulation and exploitation of vulnerabilities in Article 5(1)(a) and (b), and says the AI Office is monitoring agents, with a tender lot on evaluating their safety and security.
• The Article 50 guidelines, whose content was approved on 20 July 2026 and which were formally adopted on 5 November 2026 as C(2026) 7702, cover agents that interact with the people instructing them or with others while booking, corresponding, negotiating contracts or purchasing. Such agents must “disclose both their artificial nature and the person on whose behalf they are acting”, inside multi-agent architectures too, at key steps such as authorisation and at every new interaction. Machine-to-machine calls whose output never reaches a person fall outside Article 50(1), and Article 50(2) marking applies only when an agent’s action produces synthetic content that people perceive.
• The draft classification guidelines of May 2026, described above, which treat agentic chains serving a high-risk purpose as one system.

The dates that matter after the Digital Omnibus

Regulation (EU) 2026/1744 of 8 July 2026 was published on 24 July and entered into force on 27 July 2026. The schedule for agent programmes is now:

• 2 February 2025: prohibitions and AI literacy, which the Omnibus recast as measures to support staff literacy.
• 2 August 2025: general-purpose AI model obligations.
• 2 August 2026: general application, Article 50 transparency and enforcement by national authorities and the AI Office.
• 2 December 2026: bans on systems that generate non-consensual intimate imagery or child sexual abuse material, and the Article 50(2) marking deadline for generative systems placed on the market before 2 August 2026.
• 2 December 2027: high-risk obligations for Annex III systems, including Articles 25 to 27.
• 2 August 2028: high-risk obligations for AI in Annex I products.

The full sequence, back to entry into force, is in the EU AI Act timeline. Banks and insurers also face ICT rules that overlap with these duties, set out in DORA and AI.

EU AI Act checklist for AI agents

The evidence column is what an authority or auditor will ask for; the evidence pack approach for on-premises AI shows how to assemble it, and the on-premises architecture for AI Act readiness shows where each record is produced. For a programme view across use cases, see the EU AI Act compliance roadmap and the governance agents for the Act.

How VDF AI fits

VDF AI gives providers and deployers many of the controls this checklist assumes, on the infrastructure they choose: VDF AI Cloud, their own data centre, a private cloud or VPC, a sovereign cloud or a fully air-gapped site. The duties remain with the organisation; the platform makes them operable and produces the evidence.

The AI governance platform keeps a registry of every agent, Network and model with an owner, a purpose, a risk class and a version, which is where classification and monitoring start. In VDF AI Agents, tools are assigned from an MCP-powered registry with tool-level least-privilege access scoped per agent, and each run leaves an audit log and execution trace covering the input and identity, retrieval hits, tool calls and arguments, the model’s response and the final output. Autonomy levels set what an agent may do alone, and consequential actions wait at an approval gate for a named person, with the review, the reviewer and the elapsed time stored with the run.

In VDF AI Networks, Human Approval and Verification nodes put oversight and evidence checks inside multi-agent workflows, and execution history keeps the provenance of each run. The Vault keeps a cryptographically durable record of each execution, decision receipts bind the prompt, sources, model, tools and outcome together, an evidence pack for the AI Act is assembled from those records, and a kill switch stops an agent, a Network or a model. These controls are mapped to the AI Act; deciding the classification and owning the oversight remain the organisation’s job.