The EU AI Act and your AI agents: what actually applies right now

What applies today

The EU AI Act is not one deadline. It is a staircase, and in July 2026 somebody moved several of the steps. Here is where each obligation actually stands, with the date each claim was last checked against the primary source.

Every date in that table carries its own stamp because this is a page about dates, and a page about dates that does not tell you when it was last checked is asking for trust it has not earned. If you are reading this long after the stamps, treat them as expiry markers and go to the primary sources linked from each row.

This is an engineering read of the text, not legal advice. Talk to counsel about your own exposure.

What the Digital Omnibus changed

The instrument is Regulation (EU) 2026/1744, adopted 8 July 2026, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. verified 1 Sep 2026 Its formal title is a mouthful — it amends Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 “as regards the simplification of the implementation of harmonised rules on artificial intelligence” — and it is generally called the Digital Omnibus on AI.

What it did, in practice, was push the high-risk obligations back: standalone Annex III systems to 2 December 2027, Annex I embedded systems to 2 August 2028. What it did not do is touch Article 50, which took effect on 2 August 2026 as originally scheduled.

That split is the whole reason this article exists. A very large amount of the guidance currently ranking in search was published between January and July 2026, when “2 August 2026” was the answer to almost every question about the AI Act. Those pages are still up, still confident, and now wrong about the high-risk timeline — while being accidentally right about transparency. Law firms publish an alert once and rarely revise it; vendors publish undated keyword bait. Nobody is maintaining the “as of today” answer, which is why we are stamping ours.

The practical consequence for anyone running agents: do not read a deferral as a reprieve. The obligations that arrive in December 2027 are largely evidentiary — they ask you to produce a record of how a system behaved over time. A record is not something you can start generating the month before an audit. Fifteen months of runway is roughly the right amount of time to have started already.

Article 50: your agent may have to say it is an agent

This is the live one, and it is the one most directly aimed at agents.

Article 50(1) requires providers to ensure that AI systems intended to interact directly with natural persons are designed so those persons are informed they are dealing with an AI system — unless that is obvious to a reasonably well-informed observer given the circumstances and context. verified 1 Sep 2026

Read that against how agents are actually deployed. An agent answering support tickets interacts directly with natural persons. An agent making outbound calls does. An agent that negotiates, schedules, chases an invoice, or handles a return does. The “obvious” carve-out is doing a lot of work in a lot of deployments that were designed, deliberately, to feel like a person.

Article 50(2) is the adjacent duty: providers of systems generating synthetic audio, image, video or text must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, with carve-outs for assistive editing that does not substantially alter the input.

The engineering point: disclosure is an action-time property, not a policy document. Whether a given message discloses its origin is decided per outbound action, which means it is enforceable at exactly the same place a governance layer already sits — between intent and execution. A rule that says every outbound message to an external natural person carries the disclosure is the kind of thing that either holds on every single action or does not really hold at all.

Articles 12, 19 and 26: what the logging duty asks for

The logging obligations are deferred, not deleted, and it is worth being precise about which article does what, because the numbering trips people up.

• Article 12

  High-risk systems must technically allow automatic recording of events over the system's lifetime — enough to identify risk situations, support post-market monitoring, and monitor operation. Article 12(3) sets enhanced minimums for certain biometric systems.

• Article 19

  Covers the automatically generated logs themselves, on the provider side.

• Article 26(6)

  Deployers must keep those logs, to the extent under their control, for a period appropriate to the purpose and at least six months, unless other Union or national law says otherwise.

verified 1 Sep 2026

Two things are worth noticing about how that is written. First, Article 12 says the system must “technically allow for” automatic recording — a design requirement, not merely an operational habit. Retrofitting it is the expensive path. Second, the retention duty in Article 26(6) lands on the deployer, and it is bounded by the words “to the extent such logs are under their control.”

That phrase deserves more attention than it gets. If your agent runs on someone else's platform and the governance decisions are recorded inside that platform, exactly how much of that record is under your control? Can you export it? For six months? After you stop paying? In a form that means anything to somebody who does not use that platform? Those are procurement questions, and they are much easier to ask before signing than after an incident.

Why “we have logs” is not the same as evidence

Here is where a lot of compliance programmes will discover a gap, and it is worth confronting before the deadline rather than during an audit.

Article 12 asks for records. It does not, on its own, tell you anything about who kept them or whether anyone outside your organisation can check them. A log satisfies a record-keeping obligation on its face. Whether it satisfies a supervisor depends on properties the article does not enumerate: which policy version evaluated a given decision, who captured the record, and whether the party that captured it had an interest in the outcome.

We wrote about that problem in detail in Who holds the evidence about your AI agents? The short version: a hash chain proves nothing was altered after capture; it cannot prove capture was faithful. If the runtime that executed the action also authored the record of having decided to allow it, you have an assertion in a tamper-evident envelope.

For AI Act purposes the practical translation is a question to ask of any system you are relying on for Article 12 compliance: can this record be re-evaluated by someone who was not there? If a decision from March is questioned in November, can you show the rule that produced it as it stood in March — or only the verdict it produced? A verdict without its policy snapshot proves that something approved an action. It proves nothing about whether the approval was right.

Article 14, automation bias, and approval fatigue

Article 14 is the human-oversight requirement, and it is unusually specific about what the humans must actually be able to do. Under Article 14(4), the people assigned oversight must be enabled to understand the system's capacities and limitations and detect anomalies; to correctly interpret its output; to decide not to use it or to disregard, override or reverse the output; and to intervene or interrupt it through a stop button or similar procedure that brings the system to a halt in a safe state. verified 1 Sep 2026

And then there is Article 14(4)(b), which names the failure mode directly. Oversight staff must be enabled:

It is striking that the legislation anticipates this, because it is precisely where well-intentioned agent oversight goes to die. The pattern is familiar to anyone who has run an approvals queue: a team, nervous about autonomy, routes everything to a human. Volume climbs. The reviewer sees four hundred approvals a day, of which three hundred and ninety-eight are routine. By week three they are clicking approve at a glance. The organisation now has a documented human-in-the-loop process and, functionally, no oversight at all — which is worse than none, because it produces an audit trail of approvals that nobody meaningfully gave.

Article 26(2) points the same way from the other side: deployers must assign oversight to natural persons with the necessary competence, training and authority, as well as the necessary support. Authority and support are not satisfied by a queue.

Designing escalation so it stays meaningful

The way out is not more approvals. It is fewer, better-targeted ones — which means the system must be able to resolve most actions without a human at all, and reserve the human for cases where judgement is genuinely required.

1. Approve what is unambiguously fine. If a rule can decide it, a rule should decide it. Every routine action sent to a human is a withdrawal from the same attention budget you will need for the hard case.
2. Modify what is fixable. A large share of risky actions are risky in a specific, repairable way — a missing disclosure, an out-of-policy field. Correcting and proceeding removes the action from the queue without removing the control.
3. Escalate what is genuinely ambiguous — and measure the rate. If the escalation rate is not low, the human is not exercising judgement; they are rubber-stamping. Treat a rising escalation rate as a defect in the policy, not as evidence of diligence.
4. Block what is out of bounds. An action that would always be refused should never reach a person. Sending it is not caution; it is noise that trains the reviewer to click through.

The compliance argument for keeping escalation rare is the same as the operational one. Article 14 asks for oversight that is real. A queue nobody can actually read produces the paperwork of oversight and none of the substance, and the record will show exactly that: hundreds of approvals, seconds apart.

The other December deadline: product liability

While attention is on the AI Act, a second instrument arrives sooner and gets a fraction of the coverage.

Directive (EU) 2024/2853, the revised Product Liability Directive, applies to products placed on the market after 9 December 2026. verified 1 Sep 2026 Its definition of “product” expressly includes software, and its recitals make clear that software covers operating systems, firmware, applications and AI systems — and that a developer or producer of software, including AI system providers, is to be treated as a manufacturer.

This matters because it is a different kind of exposure from a regulatory fine. It is a strict-liability regime for defective products, and it lands considerably earlier than December 2027. The AI Act asks whether you followed a process. Product liability asks whether the thing you shipped was defective and caused harm — and in that argument, contemporaneous evidence of what your system did and why is not a compliance artifact. It is your defence.

What to build now, deferral notwithstanding

If you run agents and you are wondering what the deferral changes about your roadmap: not much, and here is the honest reasoning. Two of the three things worth building are already required, and the third takes longer to accumulate than the time remaining.

1. Disclosure, enforced per action. Article 50 is live now. Decide it at the point of action rather than trusting every prompt and template to carry it.
2. A decision record with the policy snapshot attached. Not just what the agent did — what rule evaluated it, in what version, and what the verdict was. This is the piece that cannot be backfilled, and it is what turns a log into something re-evaluable.
3. Oversight that stays meaningful at volume. Design the escalation rate down deliberately, and monitor it as a health metric. Article 14(4)(b) has already told you the failure mode to watch for.

None of that is exotic, and none of it is wasted if your systems turn out not to be high-risk. It is the same record you would want for an incident review, a customer security questionnaire, an insurer, or an acquirer's diligence.

How GaaS maps to these obligations

This section describes our own product. The obligations above are the law's; how you meet them is your choice, and plenty of architectures can.

GaaS sits between an agent's intent and its execution. Every action is declared before it happens, evaluated against policy, and returned with one of four verdicts — approve, modify, escalate, block — along with a record of the decision. The mechanics are on How It Works and specified on Tech Specs.

Against the obligations in this article, three properties are relevant. Disclosure is a policy rule like any other, evaluated per action, so an outbound message either carries what it must or does not go. The decision record is produced at decision time with the evaluating policy bound to it, which is what makes a decision re-evaluable later rather than merely logged. And because the governance layer is not the runtime executing the action, the record is authored outside the process being described — the distinction we argue in Who holds the evidence.

What we will not tell you is that any product makes you compliant. Compliance is a property of your organisation, your risk classification and your processes. A governance layer can produce the evidence and enforce the rule at the point of action; it cannot classify your system, train your staff, or take responsibility for your deployment.

Frequently Asked Questions