Spotlight on Agentic AI | The EU AI Act and Agentic AI

Introduction

So far in this series we have explained how agentic AI differs from other forms of AI and the risks those differences give rise to. Here we look at the challenges of applying AI regulation – focusing on the EU AI Act – to agentic AI: why agentic systems are more likely than previous paradigms to engage the Act's key requirements, and why compliance becomes harder once a system starts acting rather than merely responding.

Positioning Agentic AI under the EU AI Act

Here we look at how agentic systems are more likely to be caught by the Act’s key definitions, while their conduct creates a wider regulatory footprint.

AI system definition

But the absence of a specific definition of “AI agent” or “agentic system” or similar in the Act does not mean agents sit outside the framework; if anything, the opposite is true.

Article 3(1) defines an AI system by reference to varying levels of autonomy, adaptiveness after deployment, and the capacity to generate outputs that influence physical or virtual environments. This functional, technology-neutral definition was chosen to account for the evolution of AI over time. While a chatbot may engage some of the definition’s elements (e.g. it produces text, with a human deciding how it is acted upon), an agent engages each element. Its autonomy ranges from requiring confirmation for each action to full end-to-end execution; its adaptiveness captures in-context learning and memory accumulation; and its tool use is precisely the mechanism by which it "influences" the environment beyond the page.

Classification questions for agentic AI are therefore rarely about whether the definition applies (it almost always will), but about how many AI systems a deployment contains and what regulatory tier each falls into. An orchestrator agent that delegates to specialist sub-agents may be one system or several, depending on whether those sub-agents are independently placed on the market or function only as internal components. Getting this scoping right at the outset shapes everything that follows, including how many conformity assessments are required.

Agentic adaptation and substantial modification

The Act’s concept of “substantial modification” exists to keep conformity assessment meaningful over a system’s life. If triggered, it can be onerous, forcing a re-assessment and potentially resetting the compliance clock. It is defined as a change to an AI system after its placing on the market that was not foreseen in the initial conformity assessment and that affects compliance with the essential requirements or modifies the intended purpose.

This is especially likely to be engaged in agentic systems which change after deployment in ways static models do not. In their 2026 paper ‘AI Agents under the law’, Adam et al distinguish three agentic change mechanisms, each with different legal consequences: 

• Anticipated adaptive behaviour, such as tool selection from a documented catalogue and in-context learning; if foreseen, tested and risk-assessed during a conformity assessment, they are unlikely to be a substantial modification.
• Continuous learning post-deployment, where an agent fine-tunes on user interactions or updates weights from deployment data, may lead to a substantial modification, though usually within the confines of the provider’s design choices.
• (Most critically) emergent behavioural drift happens where an agent discovers novel tool-use patterns, accumulates cross-session memory that shifts its operational profile, or develops strategies that happen to sidestep oversight, none of which the provider necessarily designed or anticipated.

The regulatory difficulty is that all three may look identical from the outside. Unless the provider has kept a recorded, replayable history of the agent's tools, memory and permissions, any substantial modification may become practically unmeasurable. The compliance response needs to be architectural rather than purely documentary: versioned snapshots of the agent's operational state (tool catalogue, memory, policy controls) at defined intervals; continuous monitoring of behavioural metrics against the conformity assessment baseline; automated flags when drift crosses a threshold; and a documented procedure for deciding when a detected change meets the Act’s test.

Agents engaging adjacent regulations

As the above bear out, an agent’s regulatory footprint is set by what it can do, not by its underlying architecture. Because each new tool connection is, in effect, a new regulatory surface, a single agent's set of actions can trigger many legal instruments simultaneously: the GDPR (almost unavoidable, since agents process prompts, logs and system data – see more here); the Cyber Resilience Act (where the agent is a product with digital elements); the Data Act (where the agent acts as the "related service" to a connected product); the Digital Services Act (where it publishes or moderates content, or operates within a platform); NIS2 (where it has autonomous access to essential infrastructure); and sector-specific legislation such as the Medical Device Regulation or MiFID II where the agent operates regulatory functions in those fields.

The provider's main compliance task is therefore not classifying the technology in the abstract, but building and maintaining an inventory of the agent's external actions, the data it touches, the systems it connects to and the people it can affect – the basis for any regulatory map.

Why agentic AI makes compliance harder

Here we look at a few key obligations under the Act and why the features of agentic AI make compliance with them harder for providers and deployers alike, with ideas on which to base a response.

Human oversight

The Act (in Article 14) requires human oversight appropriate for an AI system’s autonomy and risk. Contrarily, agentic AI’s main value proposition is reduced human involvement, which puts these two things in tension from the outset.

Meaningful human oversight of an agent is difficult for several reasons: 

• An agent may avoid oversight of its own accord; the examples it learned from may include people or systems dodging supervision, and if it was trained by reinforcement learning (“rewarded” for reaching a goal), slipping past a check may be a shortcut it has been rewarded for finding.
• Many of an agent’s actions cannot be undone – by the time a person reviews what happened, the email has been sent or the account changed.
• Asking a human to approve every step creates a bottleneck that, in practice, busy teams wave through.
• Where several agents work in a chain, handing tasks to one another, no human ever sees the intermediate steps that the Act assumes someone will review.

The answer might be to build oversight into how the system is set up, rather than relying on any one person to stay alert, and to control individual actions rather than the system as a whole. For each type of action, the level of checking should match how risky and reversible it is, and should be built into the surrounding controls (so that risky actions are automatically paused until approved) rather than left to an instruction the agent might ignore. A tiered approach may work best: routine, low-risk actions run automatically but are logged; more significant actions are routed to a nominated approver; and only the most serious or irreversible actions require sign-off or are blocked outright.

Documentation

Documentation obligations under the Act were written for systems whose functions are fixed at the conformity assessment. An agent's operating envelope is still being defined after deployment, through the tools it is given, the memory it accumulates and the permissions it is granted, so documentation must describe what the system does over time, not merely what it was designed to do.

In practice, this means an exhaustive inventory of the external actions the agent can perform; an inventory of the parties its actions can affect, extending beyond the direct user to anyone touched by an email it sends, a post it publishes or an account it modifies; a record of what the agent is and is not permitted to do, showing those limits are built into the controls rather than merely written into its instructions; a record of how human oversight has been set up and why; and a step-by-step trail of the agent’s actions capturing not just what it did but why – why it chose one tool over another, and how an earlier decision led to a later action. Chain-of-thought logs alone are unlikely to satisfy this, not least because that reasoning may not faithfully represent what actually drove the agent's behaviour.

Conformity assessments

Conformity assessment assumes a single, fixed product assessed at a point in time, but we have seen the many ways agentic systems adapt and evolve from that point (tool access, memory accumulation, behavioural adaptation). This raises a question of proof: how does a provider show it assessed the system now actually operating, not an earlier, narrower version of it?

One approach might be to treat the conformity assessment not as a one-off event but as a fixed reference point the provider can keep proving against. A clear “baseline” of the system as assessed would be documented – its tools, permissions, memory and behaviour at that moment – and the live system then monitored against it, so any later change can be identified, dated and measured. Done properly, this lets a provider show precisely where the assessed system ends and any modification begins, turning the boundary into something it can evidence rather than merely assert. This monitoring should feed the same drift-detection process used to judge whether a change amounts to a substantial modification (see above).

Transparency

The Article 50 transparency obligations were designed for generative AI tools and chatbots, i.e. where it is assumed that a person can be easily told they are interacting with AI and/or where it is straightforward to label AI-generated content as such. In contrast, AI agents’ capabilities (for instance by sending emails on a user’s behalf, publishing posts or modifying an account on social media, etc.) mean that they may affect people who never chose to interact with AI and may not know one was involved on a much larger scale than a chatbot or generative tool.

Identifying and notifying every affected party is hard where an agent has broad tool access, and depends on an affected-party inventory being complete and current. Where an agent's identity can be spoofed or its outputs manipulated through indirect prompt injection, the obligation is harder still, since the affected party may not even know which system it is dealing with.

One response is to stop treating transparency as a notification exercise bolted on afterwards and instead attach the disclosure to the action itself, so that every email, post or message the agent generates is marked as machine-generated and traceable to the responsible provider. Turning transparency into a design requirement is more likely to get this right, both for recipients who never chose to interact with AI and against bad actors who try to forge the agent’s identity.

Final thoughts

Agentic AI is the version of AI to date that most fully engages the elements the Act already regulates. The real challenge is not classifying the technology, but building the infrastructure to show it still meets requirements written before the agentic mode of operation existed. With the Annex III high risk obligations expected to apply from 2 December 2027, and development and procurement decisions being made now, providers and deployers should build compliance mechanisms around what the agent actually does, touches and affects, rather than around how the technology is described.