Agentic AI governance in regulated industries: what actually binds you

For two years, every roadmap for agentic AI in a regulated industry had the same milestone on it: 2 August 2026. That was when the EU AI Act's high-risk obligations were supposed to bite, and it gave compliance teams a date to organise around.

It moved. The Digital Omnibus on AI entered into force on 27 July 2026, six days before the original deadline, and pushed high-risk obligations for standalone Annex III systems out to 2 December 2027, with product-embedded Annex I systems, which include medical devices, following on 2 August 2028.

If your programme was paced against August 2026, you now have sixteen extra months. What you do not have is a reprieve, because the obligations that actually govern an agent taking actions in your business were either never deferred or never existed in the first place.

This piece is about the EU position, and about deployers rather than model providers.

The delay was narrower than the headlines #

The Omnibus deferred a specific thing: the Chapter III regime for high-risk systems. That covers the provider requirements and conformity assessment, and also the deployer obligations that sit alongside them, including the fundamental rights impact assessment. It did not defer the Act.

It was not the only date that moved. The deadline for national regulatory sandboxes shifted to 2 August 2027, and the machine-readable marking duty for generative systems already on the market was given until 2 December 2026. The Omnibus also added obligations: two new prohibited practices, covering systems that generate non-consensual intimate imagery or child sexual abuse material, apply from 2 December 2026. And the AI literacy duty in Article 4 was softened. Providers and deployers must now take measures to support AI literacy among their staff, rather than ensure a specified level of it.

Transparency obligations landed on time

The Article 50 transparency duties took effect on schedule on 2 August 2026. They apply based on what a system does rather than which risk tier it sits in, which means a customer-facing agent falls under them regardless of whether anyone has classified it as high-risk. Providers of generative systems already on the market before that date received a four-month transition, to 2 December 2026, on the Article 50(2) machine-readable marking obligation, and nothing more. The duty to tell people they are interacting with an AI system applied from 2 August 2026 without a grace period.

What got lighter for smaller deployers

The Omnibus also brought changes that cut the other way, though most of them land on providers rather than deployers.

For deployers, the relevant change concerns the fundamental rights impact assessment. Where a data protection impact assessment already meets some of its obligations, the deployer may cross-reference those sections of the DPIA or include them in the FRIA. The original Act already required the two assessments to complement each other, so this clarifies how rather than creating a new saving. It also only matters to deployers who are required to carry out a FRIA in the first place.

For providers, the reductions are more substantial. SMEs, start-ups and small mid-caps may supply technical documentation in a simplified form the Commission will publish. Quality management obligations are explicitly proportionate to the size of the provider's organisation.

If you build and deploy your own agent, you may be the provider as well as the deployer, and both sets of changes can apply to you. In that case, check your headcount and turnover against the EU's SME and small mid-cap definitions before you budget for the old requirements.

There is no agentic AI regime #

Here is the part that changes how you should plan.

The Commission's own position is preliminary

The European Commission, through the AI Act Service Desk, states that because developments around AI agents are recent and fast evolving, its regulatory considerations remain preliminary.

The same guidance is clear on scope, though: agents are not a separate category under the Act, but they fall within its existing definitions of an AI system and a general-purpose AI model, so the rules for both apply to them. Where agency does appear in the framework, it appears indirectly. Autonomy and tool use are among the Annex XIII criteria that can push an underlying general-purpose model into the systemic-risk category, which is an obligation on the model provider, not on you.

Named in the nomenclature, defined nowhere

The Omnibus introduced a nomenclature in Annex XIV for scoping what notified bodies are competent to assess, and agentic AI is named in it. Commentators disagree on whether it holds a code of its own or appears as an example inside a residual category for emerging technologies, and the distinction matters less than what all readings share: the phrase is named and nothing is attached to it. No definition. No classification criteria. No obligation that scales with how many steps a system takes without a human involved.

So classification falls back to use case

The question "is our agent high-risk" has no agent-specific answer. It resolves the way it would for any other AI system, by use case under Annex III, or under Annex I if the agent is part of a regulated product. The obligations that follow from that classification apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I.

The practical consequence: if your governance programme is waiting for the regulator to define an agent and prescribe controls for it, you will be waiting past 2027. In the meantime you are not unregulated. You are regulated by rules written for something else, which apply anyway.

What the deferral does not change #

Three articles of the AI Act carry most of the weight for an acting system. Their deadline moved with the rest of Chapter III, to December 2027 for Annex III systems, but they describe what any acting system will have to evidence, and an agent you deploy this year will still be running when they apply.

Article 12: record-keeping

High-risk systems must log events across their lifecycle. For a model that returns an answer, this is a manageable obligation. For an agent, a log is not a transcript of what the model said. It is the sequence of tool calls, the inputs to each, the outputs returned, and the state of the system at each step. Logging an agent's actions is often assumed to be hard, but it does not have to be: tool calls are structured events and easy to capture. The hard part is explaining why the agent took a path, because runs cannot be reproduced.

Article 14: human oversight

The requirement is that oversight be effective, not that a human exists somewhere in the org chart. An approval screen a reviewer clicks through at 200 actions a day does not constitute oversight, and it will not survive a supervisor asking how many of those approvals were refused.

Article 26: deployer obligations

Most companies buying agentic AI are deployers, not providers, and deployer obligations are the ones people skip because the loudest parts of the Act are aimed at providers. They include using the system according to its instructions, assigning oversight to people with the competence and authority to exercise it, and monitoring operation.

Note the pattern across all three. None of them require you to know whether your agent is high-risk. They require you to know what it did and who was accountable.

In financial services, DORA is the live obligation #

Ask a bank's compliance team about AI regulation and they will talk about the AI Act. The rule that actually binds their agentic deployment today is DORA, which has applied since 17 January 2025.

Your model vendors are ICT third parties

DORA governs ICT third-party risk, and AI and language model providers can be captured as ICT third-party service providers. Once they are, Articles 28 to 30 apply: a register of information covering every contractual arrangement for ICT services, distinguishing those that support critical or important functions from those that do not; due diligence before contracting; mandated contractual terms including audit rights and exit provisions; and concentration risk analysis.

Now count your agent

A single deployment might call two model providers, a vector database, an email API, a CRM, and three internal services through an MCP layer. Under DORA, several of those are contractual ICT arrangements that belong in a register submitted to your national competent authority. Most agentic pilots were built by an innovation team that never saw the register, and the register is the artefact a supervisor asks for first.

The exit strategy nobody has tested

Demonstrating that you can move off a model provider is qualitatively harder than demonstrating you can move off a cloud region, because behaviour is not portable. A prompt suite tuned against one model does not transfer, and "we would rewrite the prompts" is not a tested transition plan.

The seven controls that close the gap #

No regulation will tell you how to build this. The architecture below is what fills the space between what the law requires and what an agent does.

1. Authority scoping

Least privilege expressed as configuration, not policy language: per tool, per data class, per action type. The test is whether you can produce the list of actions the agent is permitted to take without reading the prompt.

2. Where the human sits

Choose pre-approval, post-review or exception-only by reversibility and blast radius, not by how important the process feels. A reversible action affecting one record can be reviewed after the fact. An irreversible action affecting many cannot.

3. The determinism boundary

Some steps must be code. Limits, eligibility checks, mandatory disclosures and regulatory calculations do not belong in model judgment, and moving them out shrinks what you have to evaluate.

4. Audit trail as a product requirement

Tool calls, inputs, outputs, model and prompt versions, and the approver. The working test: can someone reconstruct a single decision twelve months from now, when the prompt has changed four times and the model version has rolled twice?

5. Trajectory monitoring

Agents fail as sequences, not as single bad outputs. A run in which every step looks individually reasonable can still end somewhere it should not, which means alerting on output quality misses the failure mode entirely.

6. Change control

A new tool connected to an existing agent changes what that agent can do. Treat it with the same seriousness as a model change, or your approved system quietly becomes a different system.

7. Dependency inventory

List every model, tool, API and library the agent relies on, with its version, owner and contract. DORA requires this map for relevant ICT arrangements, and it is what you reach for when a package such as LiteLLM is compromised and you have hours to find your exposure. Can you name every dependency in a given run and replace each critical one?

The failure modes are documented now #

Agent security stopped being hypothetical during 2025 and 2026.

Indirect prompt injection

The payload sits in content the agent retrieves rather than in a user's message, with disclosed findings against widely deployed enterprise assistants and coding agents. OWASP's agentic-applications risk list added categories for goal hijacking and tool misuse specifically because the generic LLM risk list did not cover the case where the output is an action.

The supply chain underneath

In March 2026 a backdoored build of LiteLLM, a gateway used by several agent frameworks, sat on PyPI for two hours and thirty-two minutes and was downloaded more than 119,000 times, according to PyPI's incident report.

The dull one that reaches a tribunal

The regulatory failure mode is older than any of these: an agent commits the organisation to something it was not authorised to commit to. A Canadian tribunal held an airline to refund terms its chatbot had stated. That is the whole problem in one sentence. The system did not need to be compromised. It needed to be believed.

This is why authority scoping and the determinism boundary are the two controls to build first. They are the only ones that constrain what an agent can do once everything else has already failed.

Staging the rollout #

Four stages, each with an exit criterion you can measure rather than a feeling of readiness.

Stage 1: Shadow

The agent runs against live inputs and writes nothing. Exit when its proposed actions match what the human actually did, at a rate and over a volume you agreed before starting rather than after seeing the results.

Stage 2: Recommend-only

The agent proposes, a human executes. Exit when the override rate has stabilised and, more importantly, when you can explain the remaining overrides. An unexplained override rate means you do not yet understand the failure distribution.

Stage 3: Bounded autonomy

The agent acts within a scope defined by value, reversibility and data class, with everything outside that scope escalated. Exit when the audit trail has survived a review conducted by someone who did not build the system.

Stage 4: Expanded scope

Widen the bounds one dimension at a time, and treat each widening as a change requiring the same approval as the original deployment.

The shortcut that costs the most

Most organisations try to jump from pilot to bounded autonomy directly, because shadow mode produces no business value and is therefore hard to fund. That is the shortcut that produces deployments which work correctly and cannot be evidenced.

Frequently asked questions #

Did the EU delay the AI Act?

Partly. High-risk obligations moved to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The Act's general application date and the Article 50 transparency duties were not moved.

What applies from August 2026?

Transparency obligations, including disclosure that a person is interacting with an AI system and marking of generated content, alongside the prohibited-practice rules already in force.

Does the AI Act define an AI agent?

No. Agentic AI is named in the Annex XIV nomenclature used to scope notified body designation, but no article defines it and no obligation is keyed to autonomy.

Is our AI vendor a DORA third party?

That depends on whether you are an in-scope financial entity and whether the service meets DORA's definition of an ICT service. Where it does, the arrangement belongs in your register of information and the contract falls under the Article 30 requirements. It is an assessment each entity has to make and document, not a question with a general answer.

What to do with the sixteen months #

The deferral is useful only if it buys something. The organisations that will be ready in December 2027 are not the ones writing longer policies. They are the ones whose controls produce evidence as a by-product of running, where the audit trail exists because the system cannot execute a tool call without writing one, not because someone remembers to export logs before a review.

That is a design decision, and it is considerably cheaper to make now than to retrofit onto a deployment that has been running for a year.

If you are working out which of the seven controls your deployment is missing, book a call.