We know that technology moves much faster than regulation. By the time a regulation has been drafted, debated, approved, and has entered into force, months have gone by and the technology has already advanced in ways that may require substantial regulatory changes.

Nothing provides a better example than the regulation of AI Agents under the EU AI Act. Exactly how and where Agentic AI fits within the wider EU Regulation may cause companies headaches and require clearer guidance from the EU down the line.

What the EU says

Currently, the main piece of official guidance from the EU is set out in a FAQ on the EU AI Act.

First, the EU clarifies that, whilst not explicitly mentioned in the Regulation, AI Agents qualifies as an AI system as per Art. 3(1), because they typically contain a general-purpose AI (GPAI) model and “have some form of interface” (which may be considered a system component). The FAQ acknowledges that

a more precise statement than ‘typically’ is difficult to make as the term AI agent is not legally defined and is used colloquially for different kinds of artefacts.

In light of this, rules applicable to AI systems can therefore also apply to agentic AI, including:

• any prohibited use (Art. 5)
• transparency requirements (Art. 50)
• GPAI requirements (Chapter V)
• obligations for high-risk AI systems and components applicable from 2 December 2027 and 2 August 2028, respectively (Chapter III)

The FAQ further recognises that these considerations remain preliminary, and the AI Office will consider issuing more targeted strategies to address Agentic AI risks.

The “AI Agents Under EU Law” regulatory architecture

In a nutshell, the EU guidance tells you that if you develop or deploy Agentic AI, you must treat it as any other AI system. But at present, it remains rather brief, cursory at best.

Luckily, EU policy expert Luca Nannini and eight co-authors published in April 2026 a paper titled AI Agents Under EU Law: A Compliance Architecture for AI Providers, outlining a comprehensive framework for Agentic AI compliance with the EU AI Act.

Echoing the EU’s official guidance, the paper restates that AI Agents are not a separate legal category under the AI Act. Rather, they are assessed under the same framework as other AI systems, despite the fact that their distinctive features (autonomy, tool use, delegation, adaptation) will arguably make existing requirements harder to implement. The paper aims to clarify how to translate these requirements into practical engineering and governance measures.

Taxonomy

Firstly, the paper proposes a taxonomy of nine categories of Agentic AI use, spanning customer service, recruitment, coding, finance, marketing, research, IT operations, healthcare and personal assistants. The distinction in use case is highly consequential in terms of regulatory obligations: a recruitment assistant may trigger high-risk requirements, while a research agent may primarily raise transparency, privacy and copyright questions.

Compliance challenges

The greater regulatory compliance efforts demanded by Agentic AI stems from the distinctive risks - and related obligations under the AI regulations – posed by Agents. In particular, the authors emphasise:

• Cybersecurity. Tellin an Agent what it may or may not do is not a sufficient or viable security measure. Permissions must be enforced through external controls, comprising restricted credentials, API authorisation and limits on accessible tools.
• Human Oversight. As the latest Agentic AI incidents illustrated, Agents may bypass monitoring, inaccurately report results or behave unexpectedly. Hence, independent technical controls become even more important to ensure effective human oversight.
• Transparency. Because of the autonomy granted to them, Agents can affect people beyond the direct user (e.g., email recipients, customers, individuals whose records are changed). As such, transparency design must account for these wider interactions and preserve traceability.
• Runtime Behavioural Drift. The paper distinguishes: a) anticipated adaptation (behaviour already tested, documented and assessed); b) post-deployment learning (changes that may require reassessment if unanticipated); c) emergent drift (unexpected changes arising from memory, novel tool combinations or evolving strategies). Authors argue that compliance cannot be demonstrated where behavioural changes cannot be detected and characterised.

The wider EU regulatory environment

The EU digital regulation environment is anything but siloed: multiple EU regulations will apply to your AI system(s), beyond the EU AI Act. Ensuring compliance with the AI Act will not be enough, and you’ll need to comply with the wider EU regulatory ecosystem, comprising:

• General Data Protection Regulation (GDPR). It may apply whenever personal data is used to train AI agents, or agents process it to achieve the objective.
  • Example: a customer service agent receiving personal data in query, querying a CRM system, logging conversations, or sending confirmation emails may trigger GDPR’s Art. 6 (Lawfulness of Processing).
• Data Act. It governs the access to, sharing of, and portability of data generated by connected IoT devices and their “related services.”
  • Example: smart home agents monitoring IoT sensors, compiling an energy usage report, or recommending improvements will need to respect users’ data-access rights and applicable requirements to share data with third parties at users’ request.
• Digital Services Act (DSA). It regulates online intermediaries, hosting services, and online platforms, mandating content moderation transparency and accountability.
  • Example: content moderation agents flagging posts, reducing their visibility in a feed and sending notifications, as well as marketing agent publishing AI-generated reviews must meet applicable requirements concerning statements of reasons, transparency and risk assessments.
• Cyber Resilience Act (CRA). It prescribes mandatory, lifecycle cybersecurity requirements for “products with digital elements” (hardware and standalone software placed on the EU market with network connectivity)
  • Example: coding agents sold as standalone software with network connection need to be applicable secure-by-design, Software Bill of Materials (SBOM), vulnerability-reporting (from September 2026), and conformity (by October 2027) requirements.
• Revised Product Liability Directive (PLD). Taking effect in late 2026, the revised PLD will expand strict liability to digital products, holding economic operators liable for damage caused by defective AI systems.
  • Example: a financial advisory agent recommending selling based on outdated data (RAG caching bug) and causing significant loss to a client may expose its provider to liability; where Article 15 applies, non-compliance may also be relevant evidence of a defect.
• NIS2 Directive. It imposes strict cyber risk-management obligations on critical infrastructure sectors (e.g., energy, transport, healthcare).
  • Example: IT operations agents deployed by an energy utility to monitor SCADA or autonomously remediating via OT API access must report any incident within 24 hours, guarantee supply chain security and demonstrate that appropriate cybersecurity risk management measures are in place.
• Data Governance Act. It regulates “data intermediation services” and promotes voluntary data sharing across the EU.
  • Example: an agentic platform operating a data marketplace on which users contribute interaction data for training other agents must comply with notification, structural separation and neutrality obligations.

The paper argues that conformity with CRA directly support the corresponding AI Act cybersecurity assessment, where the statutory conditions are satisfied. Simultaneously, it acknowledges that conventional product-security standards may not fully address agent-specific threats.

Agentic AI compliance in practice

Given these considerations and regulatory interdependencies, the ideal compliance journey for Agentic AI developers and deployers may entail the following steps:

1. Scope the system: establish what constitutes the regulated system, including sub-agents. Depending on their functions and how they are supplied, sub-agents may require separate conformity assessments or be subjected to different regulatory requirements.
2. Map the GPAI layer: identify model providers, determine who bears GAPI obligations and obtain relevant documentation.
3. Classify the system: document its intended purpose, implement contractual and technical restrictions where developers cannot predict how deployers will use the platform, and define risk classification.
4. Establish a quality management system (QMS): identify applicable lifecycle requirements, including post-deployment behavioural monitoring, or integrate requirements sector-specific QMSs where they already exist (ISO 13485 for medical devices, IATF 16949 for automotive).
5. Establish risk management: assess safety, fundamental rights and autonomy risks.
6. Implement data governance: manage datasets, operational feedback and bias.
7. Design for trustworthiness: implement oversight, transparency and traceability with a focus on automation boundary (which action the agent can execute autonomously and which require human oversight).
8. Implement AI-specific cybersecurity: enforce permissions outside the model and build “non-human identity governance infrastructure” (comprising just-in-time credential provisioning, per-action authorisation, and credential rotation policies that account for the agent’s autonomous operation cycle).
9. Assess CRA applicability: address product cybersecurity where relevant.
10. Map adjacent legislation: inventory all external actions the agent can perform, all data it can access or generate, all systems it connects to, and all natural persons whose rights it can affect.
11. Conduct the applicable conformity assessment: prepare evidence and complete relevant formalities.
12. Monitor after deployment: detect incidents and drift and reassess changes.

Open Issues

The authors concluded the paper with several key observations:

• Immature standards create uncertainty and call for legislative reform or further guidance.
• Agentic AI is only partially addressed, especially in regard to multi-agent protocol threats, interface exploitation, and governance-level autonomy concerns.
• Conformity-assessment methods remain under development.
• Fundamental-rights expertise must be part of risk management.
• Overlapping cybersecurity standards create coordination problems.
• Liability remains fragmented, with the revised product-liability legislation deemed to not properly address AI liability risks.
• Agent-specific guidance is limited, particularly on behavioural change.
• Agentic governance tooling is insufficient for recording who authorised individual consequential actions.

In the paper, authors also discussed the uncertainty over the delayed timelines as envisaged by the Digital Omnibus and the lack of enforcement. However, the regulatory landscape had changed since the paper was published in April 2026: the Digital Omnibus has been adopted (July-August 2026) and the AI Office has launched its first enforcement action (October 2026). Obviously, authors could not know at the time.

Regardless, this framework remains a very valuable and rigorous instrument organisations should follow while awaiting official guidance.

Holweg and Hacker’s interpretation

Around the same time the paper was released, Professors Matthias Holweg (Saïd Business School, University of Oxford) and Philipp Hacker (European New School of Digital Studies, European University Viadrina) published A pragmatic approach to regulating AI agents, which reaches many of the same conclusions but offers some different interpretations.

The question of GPAI models status

Holweg and Hacker argue that “agents are typically not GPAI models”, in that they are not “mere mathematical artefacts”, but “systems built on top of foundation models and connected to them through scaffolding architecture”. As such, they cannot be reduced to “the underlying model weights and parameters that constitute a GPAI model within the meaning of Article 3(63) of the AI Act”.

This distinction is important, because the GPAI system status does not itself trigger Chapter V model obligations or automatic high-risk classification. High-risk status depends on the relevant intended purpose and legal conditions.

Value chain considerations

Authors also highlight the EU AI Act’s Art. 25, which says that a deployer, distributor, importer or other third-party become subjected to the same high-risk AI system obligations of a high-risk AI system provider if they:

• substantially modify a high-risk AI system already placed on the market becomes a new provider.
• modify the intended purpose of an AI system (including GPAI systems) that has not classified as high-risk and has been placed on the market or put into service in such a way that the AI system concerned becomes a high-risk AI system in accordance with Art. 6.

Regarding the first point, authors suggest that an entity modifying a GPAI model through agentic scaffolding may “become a new GPAI model provider if the scaffolding alters the model itself (and not only the system) in a substantial manner”. As for the second, Holweg and Hacker believe that the provision is central when an agent built on a GPAI model is “deployed in a high-risk domain such as medical diagnostics, employment, or critical infrastructure management”.

Blurred obligations boundaries

In addition, the authors note a certain doctrinal tension between Art. 6 and Art. 25. Some product-safety regimes classify products by the original manufacturer’s intended purpose, which can conflict with Article 25’s treatment of downstream repurposing. Not all applicable regulations recognise a change of purpose by a downstream actor as an activity that gives the entity manufacturer status. For example, an organisation might redirect generic software into a safety-critical application even though the original supplier never designated that purpose. What happens in that case? Does the original provider also acquire obligations when a customer changes the system’s intended use?

Recent amendments have partly resolved this tension by requiring original providers to make the necessary documentation available to the new providers, so that they have enough information to comply with high-risk AI system obligations (conformity assessment). The authors, however, deem such provisions insufficient in practice, given the extent of access to proprietary information that downstream providers may need to comply with the Regulation (and that original providers might be reluctant to provide).

Rethinking Agentic AI categorisation

Does a very basic AI agent qualify as GPAI (and therefore become subject to the relevant obligations)? Starting from this question, Holweg and Hacker consider whether a new regulatory categorisation for foundational might be warranted:

• person evaluator. This is an Agentic AI system built with novel scaffolding, memory structures, and tool-use capabilities designed to assess individuals across high-risk use cases such as employment screening, educational admissions, and medical triage, and act on the resulting assessment. The person evaluator agent is designed as a general-purpose evaluation module that “can be plugged into different domains”.

• coding agent. It combines a foundation model with specialised scaffolding for code generation and execution. Agents coding, testing, and deploying IT security updates autonomously pose significant risks, particularly because of their capacity for autonomous real-world action.

• orchestration platforms. As Agentic AI is increasingly used as an orchestration layer, agents can coordinate networks of specialised subagents, supervising their work and collecting results. As such, the orchestration agent has greater capacity “to propagate risk into a system or agentic network than a single agent”.

The authors then assess the pros and cons of a GPAI-specific regulatory regime, including increased efficiency on the one hand (proposing to address risks at the source instead of replicating assessments downstream), and the risk of duplicating existing rules and additional compliance burdens on the other, especially for smaller players. As such, they advocate targeted clarifications instead of building additional regulatory layers.

Few but clear AI rules

Holweg and Hacker’s conclusions are sensible: what is needed is not additional regulation layers, but rather targeted guidance and clarifications to integrate the new Agentic AI risk horizon into existing frameworks. The work of Nannini and his co-authors highlights that most provisions are there, and what’s needed is, if anything, some light regulatory amendments to bridge the gaps.

This reinforces the idea that a few, but clear rules may be the way to go for effective AI regulation. AI is unlikely to remain unregulated indefinitely: some rules are needed, and going forward, rules will arrive. Hence, to avoid the mantra of “regulation slowing down innovation” – an argument I have consistently pushed back against – it would be far more helpful to have clear, specific and flexible normative frameworks that guide tech firms instead of leaving them uncertain about their obligations. Few things keep startup executives up at night more than the prospect of hitting barriers to growth along the way or the fear of regulatory scrutiny.

A regulation built around cooperation may perhaps ease the tensions over AI risks. In the current political and social climate, this is easier said than done, but it is worth a try nonetheless.