The EU AI Act names agentic AI once, in a list of filing codes for notified bodies

One mention, and it is a filing code

Search the consolidated text of Regulation (EU) 2024/1689, as amended on 27 July 2026 by Regulation (EU) 2026/1744, for the phrase Agentic AI. You get one hit.

It sits in Annex XIV, an annex the July 2026 amendment added, under the heading Emerging AI technologies, as code AIH 0401: "AI systems based on other emerging AI technologies not covered by other codes, including Agentic AI". Annex XIV exists for one job, stated in its own introduction and in the amended Article 30(2): it sets the scope of the designation of conformity assessment bodies notified under Article 30. It is a filing category for notified bodies. It is not a definition, not a risk class, and it carries no duty for anyone who builds or runs an agent.

What that single mention does not establish is that agents fall outside the Act. It establishes something narrower and more interesting: that when the co-legislators reopened the AI Act in 2026 and made forty three separate amendments to it, they did not add an agent definition, an agent risk tier or an agent-specific duty. They added a code so that a notified body can say which kinds of system it is competent to assess.

Not named is not the same as not covered. An agent is an AI system, so the AI system duties apply to it in full. The honest question is not whether the Act reaches agents. It is where the Act's assumptions strain when the system it is regulating runs for four hours without anyone watching.

An agent is an AI system, on the definition already in force

Article 3(1) defines an AI system as "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments".

Read the two phrases that matter for this story. Varying levels of autonomy is in the definition, not in an annex. Influence physical or virtual environments is the outcome the definition contemplates, not merely the production of text. A system that plans, calls tools and changes the state of a ticketing system, a mailbox or a payment queue is squarely inside that sentence. It was inside it on 2 February 2025, when Chapters I and II began to apply, which is 598 days ago.

The Digital Omnibus amended Article 3 in July 2026. It changed the definition of safety component and inserted definitions of SME and of small mid-cap enterprise. It did not touch Article 3(1). The definition that catches agents is the one the legislature just declined to revisit.

The dates moved six days before they were due to bite

Regulation (EU) 2026/1744, the Digital Omnibus on AI, is dated 8 July 2026 and entered into force on 27 July 2026. The obligations it postponed were due to apply on 2 August 2026. That is six days of margin.

Article 1, point 40 of the Omnibus replaced point (c) of the third paragraph of Article 113. The new wording is: "Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5), shall apply from: (i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and (ii) 2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I".

Measured from 2 August 2026, that is 487 extra days for standalone high-risk systems in the Annex III areas, and 731 extra days for AI embedded in regulated products under Annex I. From today, 23 September 2026, the Annex III date is 435 days away.

The reason is in the Omnibus recitals, and it is not a reason about agents. The recital on Article 113 records that "the delayed availability of standards, common specifications, and alternative guidance and the delayed establishment of national competent authorities lead to challenges that jeopardise the effective entry into application of those obligations".

That is verifiable on its own terms. Article 6(5) required the Commission to issue guidelines on high-risk classification, with practical examples, "no later than 2 February 2026". The Commission published a draft of those guidelines on 19 May 2026, which is 106 days after the statutory deadline, and the draft was still a draft when the deferral was agreed. Article 6(5) is the one provision expressly carved out of the postponement, so the duty to produce the guidance applied from 2 August 2026 while the duties the guidance explains did not.

Application dates under Article 113 as amended by Regulation (EU) 2026/1744, read against what an agent operator actually has to do

Date	What applies	Reaches an agent?
2 Feb 2025	Chapters I and II: definitions, scope, Article 4 AI literacy, Article 5 prohibited practices	Yes, in force now
2 Aug 2025	Chapter V general-purpose AI model duties, Chapter VII governance, Article 99 penalties	Yes, for whoever provides the underlying model
2 Aug 2026	Article 50 transparency, Chapter IX market surveillance, Article 86 right to explanation, Article 6(5) guidelines	Yes, in force now
2 Dec 2026	Article 5(1)(ba) and (bb), the new prohibitions on non-consensual intimate and child sexual abuse material	Yes, if the agent can generate such material
2 Dec 2027	Chapter III Sections 1 to 3: Articles 6 to 27, including Articles 12, 14, 19, 25 and 26, for Annex III high-risk	Deferred
2 Aug 2028	The same Chapter III duties for Annex I product-embedded high-risk systems	Deferred

Article 14 read literally, for a system nobody is watching

Article 14(1) is one sentence: "High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use."

Read what that does and does not require. It is a design duty on the provider. It requires the capability of effective oversight, not the fact of it. It does not say a human must approve anything, it does not cap how long a system may run, and it does not say oversight must be synchronous.

Article 14(3) then scales the duty: the measures "shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system". Autonomy is already a dial in the clause. An agent that runs unattended for hours is not, on the text, automatically non-compliant. It is a system whose oversight measures have to be heavier in proportion.

Article 14(4) sets out what the assigned person must be enabled to do, "as appropriate and proportionate": to understand capacities and limitations and monitor operation, including "detecting and addressing anomalies, dysfunctions and unexpected performance"; to remain aware of automation bias; to interpret the output correctly; "to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output"; and "to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state".

Two of those five strain against an agent, and the strain is in the verbs.

Reverse the output. For a classifier the output is a score and reversing it is a decision not to act on it. For an agent the output is an action already taken: the email is sent, the refund is issued, the record is deleted. Article 14(4)(d) gives the overseer a power over outputs that, for a tool-using system, may have already been consumed by the world. The Act does not distinguish an output that can be disregarded from one that cannot.

A safe state. Article 14(4)(e) is the only place the Act uses the phrase, and the Act nowhere defines it. For a system that classifies, halting is the safe state. For an agent five calls into a seven-call sequence, halting may be the least safe state available: a half-migrated record, an open transaction, a partially revoked permission. There is no clause on rollback, no clause on compensating actions, no clause on what a halt must leave behind.

The deployer's side is Article 26(2), and it is a single sentence with four requirements: "Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support." That is the clause that turns human in the loop from a slide into an obligation, because authority is named. A named overseer who cannot stop the run without a change ticket does not have authority in the sense Article 26(2) uses.

That is the friendly-name problem in this story. Human in the loop is a label. Article 14(4) and Article 26(2) are a list of capabilities that a specific person has to hold, with a name attached. If the loop is a monitoring dashboard nobody is rostered to watch, the label is satisfied and the clause is not.

Who is the provider when you build on somebody else's model

The Act's central split is between a provider, defined in Article 3(3), and a deployer, defined in Article 3(4). It assumes those are two different parties. For an organisation that takes a vendor's general-purpose model, wraps it in a scaffold, hands it tools and points it at its own operations, both roles land on the same legal entity at once.

Article 3(3) covers anyone who "develops an AI system ... or that has an AI system ... developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge". The trigger is not selling anything. Article 3(11) defines putting into service as "the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose". Internal deployment is putting into service. Free of charge is expressly included.

So the bank that assembles an agent from a licensed model, its own orchestration code and a set of internal tools, and runs it on its own staff in an EU establishment, is the provider of that agent. The model vendor is the provider of the general-purpose AI model, which is a different object with a different chapter of duties, Chapter V, applying since 2 August 2025. Article 53(1)(b) requires that model provider to give downstream integrators documentation sufficient to "have a good understanding of the capabilities and limitations" of the model and to comply with their own obligations. That is the hinge. If your vendor's model card will not carry your Article 11 technical documentation, you have an Article 25(4) problem, not a procurement preference.

Article 25 is the clause that moves the provider label around, and it has three triggers in paragraph 1. You become the provider of a high-risk system if you (a) put your name or trademark on it, (b) make a substantial modification to it, or (c) "modify the intended purpose of an AI system, including a general-purpose AI system, which has not been classified as high-risk ... in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6".

When that happens, Article 25(2) says the original provider "shall no longer be considered to be a provider of that specific AI system". The Omnibus strengthened what the original provider then owes you: technical documentation sufficient to assess compliance with Article 16, information about "known limitations and failure modes", and "targeted technical access, including for testing and validation". Article 25(4) separately requires a written agreement with any third party supplying a system, model, tools, services, components or processes integrated into a high-risk system, with an exemption for free and open-source components other than general-purpose AI models.

Those two paragraphs now carry their own penalty. The Omnibus inserted Article 99(4)(da), so failing on Article 25(2) or 25(4) attracts fines of up to EUR 15 000 000 or 3 per cent of total worldwide annual turnover, whichever is higher.

Classification is per purpose, and tools move the purpose

Article 6(2) is brief: "In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk." Annex III lists areas and, within them, use cases. The classification therefore turns on what the system is for.

Article 3(12) tells you who decides that. Intended purpose means "the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation". Your own documentation, including your sales copy, sets your classification. If you are the provider of your internal agent, the documentation is whatever you wrote down, and if you wrote nothing down the assessment will be made from what you said about it.

Article 6(3) offers a derogation. An Annex III system is not high-risk where it "does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making", and where any of four conditions holds: a narrow procedural task, improving the result of a previously completed human activity, detecting decision patterns without replacing human assessment, or performing a preparatory task. The final subparagraph closes it again: a system that performs profiling of natural persons "shall always be considered to be high-risk".

Article 6(4) puts the burden on you. A provider who considers an Annex III system not to be high-risk "shall document its assessment before that system is placed on the market or put into service", register it under Article 49(2), and produce the documentation on request.

Now hold that against an agent. The derogation limbs are written around a fixed capability. A narrow procedural task is a property of a system. An agent's capability set is a property of its tool list, and its tool list is a configuration file. Add a scheduling tool and the draft assistant becomes a system that allocates tasks. Add a candidate database and it becomes Annex III point 4(a), recruitment and selection. Add an arrears ledger and it approaches point 5(b), creditworthiness.

The Act's answer is Article 25(1)(c), and it is a real answer: modify the intended purpose so the system becomes high-risk and you become its provider. But Article 25(1)(c) is drafted for a deliberate, documented act of modification by a distributor or deployer. It is not drafted for a capability that appears because a connector was enabled in a configuration change nobody classified as a design decision. No clause in the Act names a tool grant. That is a real gap, and it is a gap in the mechanism rather than in the coverage.

What the Act clearly covers, against what it does not name

Agent behaviours mapped to the AI Act as amended. Every row carries a clause number or an explicit no clause.

Behaviour	What the Act clearly covers	What it does not name
Autonomy itself	Art 3(1): varying levels of autonomy is inside the definition of an AI system	No clause grades autonomy or sets a threshold above which extra duties attach
Running unattended	Art 14(3): oversight commensurate with the level of autonomy	No clause: no maximum unattended run, no per action approval
Stopping mid sequence	Art 14(4)(e): a stop button or similar procedure halting in a safe state	No clause defines a safe state, rollback or compensating action
Reversing what it did	Art 14(4)(d): disregard, override or reverse the output	No clause distinguishes an output that can be reversed from an act already taken
Building on a vendor model	Art 3(3), Art 3(11), Art 25(4), Art 53(1)(b) documentation to downstream builders	No clause names the assembly of a model, a scaffold and tools into one system
Gaining a capability by tool	Art 25(1)(c): modifying intended purpose so it becomes high-risk makes you the provider	No clause treats enabling a connector as a modification or a substantial change
Purpose drift	Art 3(12), Art 6(2) to (4): classification per intended purpose, with a documented assessment	No clause requires reclassification on a schedule or on a configuration change
Agent to agent delegation	Art 3(13): reasonably foreseeable misuse includes interaction with other AI systems	No clause on sub agents, delegation chains or who is provider of a composed system
Logging what it did	Art 12(1) and (2): automatic recording of events over the lifetime, for three stated purposes	No clause requires tool calls, prompts or permissions in force to be recorded
Keeping the record	Art 19(1) providers and Art 26(6) deployers: at least six months	No clause sets a longer floor for systems that act, rather than advise
Telling people	Art 50(1) interacting with an AI system, Art 50(2) marking synthetic output, both from 2 Aug 2026	No clause requires disclosure that an action, rather than a text, was taken by a machine
Prompt injection	Art 15 accuracy, robustness and cybersecurity, deferred to 2 Dec 2027	No clause names prompt injection, tool poisoning or untrusted content in the loop

What has to be logged, and for how long

This is the duty most teams assume is heavier than it is.

Article 12(1): "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 12(2) says the logging capability must enable recording of events relevant for three things, and only three: identifying situations that may result in the system presenting a risk within Article 79(1) or in a substantial modification; facilitating post-market monitoring under Article 72; and monitoring operation under Article 26(5).

Article 12(3) is the only place the Act prescribes log content, and it applies to exactly one category: remote biometric identification systems under Annex III point 1(a). For those, the minimum is the start and end date and time of each use, the reference database, the input data that produced a match, and the identity of the natural persons who verified the result. For every other high-risk system, including any agent, the Act specifies no fields.

Retention is a floor, twice stated. Article 19(1) requires providers to keep the logs "to the extent such logs are under their control" for "a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in the applicable Union or national law". Article 26(6) imposes the same floor, in almost identical words, on deployers. Financial institutions keep them under their financial services law instead.

Six months is short for a system that acts. A refund decision surfaces as a complaint in nine months; a recruitment decision surfaces as a tribunal claim later than that. The Act's own phrase, appropriate to the intended purpose, is the operative words, and six months is the floor beneath them.

Which UK organisations are caught, and on what basis

The UK has no equivalent Act. Parliament's own bills service lists one live artificial intelligence regulation bill, the Artificial Intelligence (Regulation) Bill in the Lords, a private member's bill that has had a first reading and no further stage, last updated on 30 April 2026. The operative UK framework is still the principles-based approach set out in the March 2023 white paper and applied through existing regulators. Nothing in it obliges you to classify an agent.

The EU Act reaches UK organisations anyway, by three separate routes in Article 2(1).

The three routes into scope for a UK organisation, from Article 2(1) of Regulation (EU) 2024/1689

Route	Clause and trigger	What it catches
Provider route	Art 2(1)(a): placing on the market or putting into service in the Union, "irrespective of whether those providers are established or located within the Union or in a third country"	A UK vendor selling an agent to EU customers, and a UK group putting one into service for own use inside an EU entity
Deployer route	Art 2(1)(b): deployers "that have their place of establishment or are located within the Union"	Any EU subsidiary, branch or shared service centre running the agent
Output route	Art 2(1)(c): providers and deployers located in a third country "where the output produced by the AI system is used in the Union"	A UK-run agent whose outputs are acted on in the EU, with no EU entity and no EU sale

The output route is the one UK teams miss, because it requires no establishment, no contract and no sale. If a UK shared service runs an agent that screens candidates and the hiring decisions land in Dublin or Amsterdam, the output is used in the Union.

The carve-outs are narrow. Article 2(3) excludes systems used exclusively for military, defence or national security purposes. Article 2(6) excludes systems developed and put into service solely for scientific research and development. Article 2(8) excludes research, testing and development before placing on the market, but expressly not testing in real-world conditions. A pilot with live customers is not a research exclusion.

The exposure is Article 99. Breaching the Article 5 prohibitions attracts up to EUR 35 000 000 or 7 per cent of total worldwide annual turnover, whichever is higher. Breaching provider duties under Article 16, deployer duties under Article 26, the new Article 25(2) and (4) duties or the Article 50 transparency duties attracts up to EUR 15 000 000 or 3 per cent, whichever is higher.

What to record now so a 2027 classification can be defended

The postponement moved the duty. It did not move the evidence. When the Annex III duties apply on 2 December 2027, the question a market surveillance authority asks under Article 6(4) is what assessment you made and when you made it. If your agent went live in 2026 and its tool list has changed eleven times since, the assessment you can defend is the one with a dated trail behind it.

None of the following is required today. All of it is the record that makes an Article 6(3) or Article 6(4) position arguable later, and every item maps to a clause.

If you already run an ISO/IEC 42001 management system, most of that list has a home. The AI risk assessment and treatment clauses, 6.1.2 and 6.1.3, are where the Article 6(3) reasoning belongs. Operational planning and control at 8.1 and impact assessment in operation at 8.4 are where the tool inventory and the reassessment trigger belong. In Annex A, the control objective on assessing impacts of AI systems, A.5, carries the classification record; the AI system life cycle objective, A.6, carries the change control that a tool grant should pass through; responsible use, A.9, carries the oversight authority; and third-party and customer relationships, A.10, carries the Article 25(4) agreements.

The point of the mapping is not certification. It is that 42001 gives you a register with dates on it, and the AI Act's classification duties are decided on dated records. Our ISO 42001 readiness assessment walks the clauses at control-objective level, the regulatory scope checker works out which regimes reach a UK organisation, the AI policy generator produces the policy the record hangs off, and the AI Act timeline tracks the dates. All four are free and run in the browser.

The secondary argument, and where we part from it

Two pieces frame the public debate, and both are secondary for our purposes. Kathrin Gardhouse and Amin Oueslati argued in Tech Policy Press on 5 May 2026 that the Act is not ready for agents, identifying accuracy metrics, misuse safeguards, privacy, fundamental rights impact assessments and the stop button as the five weak points. A paper by Luca Nannini and nine co-authors, posted to arXiv in April 2026, proposes a compliance architecture for agent providers and records that the AI Office had published no guidance specifically addressing AI agents as of early 2026.

We agree on the stop button and on the absence of guidance. We part company on the framing. Most of what is described as a gap is a gap in guidance, standards and enforcement practice, not in the text. The text already catches agents through Article 3(1), already scales oversight to autonomy through Article 14(3), and already moves the provider label when purpose changes through Article 25(1)(c). What it lacks is any mechanism that fires when capability arrives through configuration rather than through a release.

One note on interests. The AI Act Explorer used here as the text of record is run by the Future of Life Institute, an organisation that campaigns for stricter AI regulation. We used it because it reproduces the Official Journal text and EUR-Lex was unreachable from this machine, and we checked the dates against the Commission's own page. Tech Policy Press publishes advocacy and analysis rather than legal advice. None of that makes any of them wrong; it is a reason to read the clause, which is what this piece does.

The question that exposes the gap

On 2 December 2027 the high-risk duties apply to Annex III systems. If your agent is in scope, someone will ask the Article 6(4) question: what assessment did you make, and when.

The question worth asking inside your own organisation before then is smaller and harder. Who signed off the last tool you gave the agent, and did anyone ask whether the tool changed what the agent is for? If the answer is that a connector was enabled in a configuration change, by someone who had no reason to think of it as a classification decision, then the Act's mechanism has never fired, and the record you will need in December 2027 does not exist. That is not a failure of the legislation to name agentic AI. It is a failure to treat a configuration file as a design document.