Deploying Agentic AI Under EU & UK Regulations

Organisations deploying agents face a challenge: the predominant AI frameworks most organisations rely on do not explicitly address agentic AI. This is true for the big three: ISO 42001, NIST's AI Risk Management Framework (RMF), and the EU AI Act.

This is beginning to shift, albeit slowly. For example, cross-economy bodies are beginning to look more closely at agentic systems; the Model AI Governance Framework, released by the Infocomm Media Development Authority (IMDA) in Singapore, is the first of its kind. In the UK, the Digital Regulation Cooperation Forum (DRCF) has made agentic AI the first focus of its Thematic Innovation Hub. The DRCF coordinates across four of the main cross-cutting layers in the UK digital economy: the Competition and Markets Authority (CMA), the Financial Conduct Authority (FCA), the Information Commissioner’s Office (ICO), and the Office of Communications (Ofcom).

However, the EU AI Act is a binding law rather than an optional framework of emerging best practices. Organisations in scope of the AI Act must consider carefully how those requirements apply to their agentic AI initiatives. In this blog post, we will demystify some of the overlaps, as well as provide practical guidance for how to build, whilst agentic-specific requirements develop.

Understanding the Current Overlaps

On the surface, the overlap may appear limited because the EU AI Act does not regulate agentic AI as a category in its own right. But that does not mean agentic systems fall outside its scope. For example:

The Commission’s guidance frames an “AI system” around autonomy, meaning some degree of independence from direct human involvement, and outputs that influence physical or virtual environments. That already covers much of what people mean when they talk about agents: systems that plan, act, and use tools autonomously.
Given that agentic systems frequently rely on General Purpose AI (GPAI) models for orchestration, reasoning, and natural language processing, important parts of the stack are already in scope through existing GPAI-related obligations.
The AI Act regulates by role, risk, and use case, not by architecture. In other words, if the system is in scope of those elements, the fact that it’s "agentic" is irrelevant.

Apart from the EU AI Act, there are other parallel regulatory overlaps, too:

The EU Cyber Resilience Act addresses remote data-processing solutions, which can impact SaaS solutions generally, and agentic capabilities specifically, depending on where those capabilities are embedded.
In financial services, both NIS2 and DORA address board-level accountability for cybersecurity risk management, incident management and reporting, resilience testing, and third-party risk controls, all of which are relevant to agentic.
GDPR is also a consideration. While the primary focus has been on the use of personal data in AI model training (e.g., Ireland DPC's inquiry into xAI/Grok's use of publicly accessible X posts by EU/EEA users), agentic use cases are also relevant because they can blur the boundary between transient use, retained memory, model improvement, and vendor-controlled processing. This can make deletion, explainability, and accountability more difficult, unless the architecture is explicitly designed to address these requirements.
Outside of the EU, country-specific regulatory bodies are also increasingly addressing agentic. In March 2026, the UK's Competition and Markets Authority (CMA) explicitly clarified that business use of agentic AI must comply with existing consumer and competition law. CMA also highlighted concerns around agentic interoperability, permissions, logging, data mobility, and closed vendor ecosystems.
In February 2026, the Bank of England explicitly called out the inevitable failure of literal “human-in-the-loop” approaches, as agentic systems proliferate. While the Bank of England is not a regulator like the CMA or FCA, it provides clear indicators of where the conversation is heading.

So while today's regulations do not explicitly address agentic AI as a standalone category, that does not make them irrelevant. Quite the opposite; glimpses of the controls that are likely to matter most are already visible in current law, adjacent regulation, and emerging supervisory guidance.

12 Practical Priorities for Safely Deploying Agentic AI

When we look at the current direction of travel, there are two key questions that need answers.

First, how can UK and EU organisations operate agentic systems safely under today’s overlapping requirements? And second, how can they set themselves up for success, as agent-specific expectations begin to emerge?

This translates into a set of 12 practical priorities:

1. Treat every agent as a dynamic, fully-governed digital actor, not a static chatbot.

Every agent should have:

a first-class identity
a clear owner
a defined purpose
a known toolset
a bounded system reach
an approved data-access scope
explicit rules for which actions it can take without human approval

The organisation must also have visibility of the agent's interactions, end-to-end. Regulators are increasingly focused on accountability, not just model capability. You can't answer those questions convincingly if you don't start here.

2. Classify use cases before deployment.

Is your agent customer-facing, employment-related, safety-relevant, handling sensitive data, or likely to fall into an EU AI Act high-risk or transparency bucket? The EU AI Office has already said that 2026 guidance will focus on high-risk classification, provider/deployer obligations, substantial modification, value-chain responsibilities, post-market monitoring, and Article 50 transparency. Build your agents with the unique requirements of those items in mind.

3. Govern and constrain autonomy.

The fastest way to create risk is to give an agent broad tools and broad authority simply because the platform allows it. Keep permissions and scope as narrow as possible, and push SaaS vendors to give you the granularity you need. Leverage deterministic hard boundaries to constrain the possibility space within which action can occur.

Remember: if an agent can reason about obeying a constraint, it isn't one.

4. Use Human-in-the-Loop (HitL) judiciously, and where it matters most.

Regulators are beginning to acknowledge that HitL is neither realistic nor sustainable for everything; “human oversight” will be reinterpreted as bounded autonomy plus accountable humans, not literal constant human intervention.

But that doesn't mean it won't have a place.

Reserve mandatory human approval for actions that are irreversible, regulated, high-impact, or externally binding, such as payments, contracts, certain HR actions, sensitive record deletion, or public communications. This is more defensible than vague claims of “human oversight” because it helps to evidence where agent autonomy ends, and accountable human decision-making begins.

5. Build logging as if you will need to explain an incident to a regulator.

Be prepared to evidence not just what the agent was designed to do, but what it actually can do, what it actually did do, and what it is currently doing.

Observability is not just about execution; it's also about intent. Be prepared to evidence Execution Observability (EO) and Intent Observability (IO). How would you know if the agent's output was safe, but it went about it in an unsafe way? How would you know if agent behaviour is deviating from intent, as it runs?

6. Design private data retrieval, processing, and storage architecture with GDPR requirements in mind.

Prefer retrieval over retention architectures, i.e., the agent retrieves governed data from source systems rather than absorbing it into durable model memory or vendor-side improvement pipelines. ICO and other regulators have already established that agentic systems do not weaken data-protection obligations, and once personal data has influenced model weights, there is currently no practical way to identify, isolate, and remove it, as there is with embeddings, vector stores, and other traditional data storage.

7. Ask the hard provider/deployer accountability questions up front.

If the agent is partly or mostly operated in the vendor’s environment (as with declarative agents, see special note below), ask the hard questions early:

who controls instructions?
who stores logs?
who can disable memory?
who can halt actions?
who supports deletion and rights requests?
who investigates incidents?
what evidence will you receive for the above, as a customer?

The EU AI Office has explicitly identified value-chain responsibility and provider/deployer obligations as guidance priorities for this year.

A special note on declarative agents: Declarative agents are not inherently untenable from a regulatory perspective. Unbounded declarative agents are. Beyond the items mentioned above, the key is to constrain the agent’s reachable surface, since you don't control the runtime; you're shifting from “I control the whole runtime” to “I control what the runtime is allowed to know, invoke, and expose.” Regulators are more likely to accept that the orchestration layer is provider-managed, as long as the deployment and operations lifecycle is enterprise-governed.

8. Continuous red teaming is the new normal.

For agentic systems, prompt injection and related attacks are not just a model-quality issue. They are workflow integrity issues, because a manipulated instruction path can lead to tool misuse, data leakage, or unsafe downstream actions. That means security review must include indirect-instruction attacks, malicious documents, hostile webpages, poisoned context, and unsafe tool invocation patterns. EU and UK guidance is clearly moving toward this kind of system-level testing mindset. Red teaming applications “once-then-production” has never been safe; it is even less safe with agentic.

9. Test workflows, not just models.

Don’t rely on benchmark scores, vendor demos, or one-step prompt evaluations. Test the full chain: tool selection, escalation logic, exception handling, retries, memory behaviour, bad inputs, hallucinated actions, broken connectors, and failure-to-stop scenarios. This is consistent with growing guidance (from the Government Digital Service in the UK, for example) that testing must cover the workflow and control plane, not just the underlying model.

10. Create kill switches and degraded modes of operation.

You should be able to shut off a single agent, a single tool, a single connector, or all autonomous write actions without shutting down the entire platform. This matters, both from an operational and a regulatory perspective. If something goes wrong, organisations need to show they can contain harm, preserve evidence, and revert to safer operating modes. That expectation fits squarely with the AI Office’s emphasis on practical implementation, monitoring, and serious-incident handling, even if their focus is not agentic-specific.

11. Make this an executive governance issue now.

In many organisations, agentic AI is already beyond the scope of a technical pilot, and it impacts many types of risk: security, legal, procurement, privacy, operations, and customer. Don't wait for a new UK AI law or full standards reconciliation from the EU AI Office; put clear executive ownership around deployment standards, exceptions, and risk acceptance today.

12. Buy for evidence, not for promises.

The right procurement question is not, “Does this vendor have responsible AI principles?” It is, “What evidence can they produce?” Ask for specifics on retention, sensitive/private data handling, subprocessors, logging visibility, deletion support, incident response, tenant isolation, model update notice, and contractual support for customer compliance obligations. As implementation matures in the EU and UK, the organisations in the best position will be those that can produce documentary evidence showing who controlled what, and what safeguards were actually in place.

Using the information available today, we can identify many of the items that are likely to be the focus of any agentic-specific requirements that emerge in the near future. The organisations that will be best prepared are not the ones that avoid agents altogether; they are the ones that can prove what each agent was allowed to do, what it actually did, what data it touched, and who could intervene when it went wrong.

All Articles