The short version. The EU has agreed to move the main high-risk deadline under the AI Act. Standalone Annex III systems now point at 2 December 2027 instead of 2 August 2026. AI built into regulated products under Annex I moves to 2 August 2028. The political agreement landed on 7 May 2026; as of late June 2026 the text is not yet formally adopted or published in the Official Journal, so 2 August 2026 stays on the books until it is final. None of the obligations changed. Only the clock did. If your plan was to clear a conformity check in August and stop, the extra time is not a reprieve. It is room to build the evidence properly instead of in a scramble.
This is how a security team should read the change; it is not legal advice. Talk to counsel for the legal position on your specific systems. What follows is what the shift does, and does not do, to the engineering you owe.
What actually changed
The change is to the timeline, delivered through the package the EU calls the Digital Omnibus. The dates that matter:
- High-risk standalone systems (Annex III): the obligations now apply from 2 December 2027, not 2 August 2026. This is the headline move, roughly sixteen extra months.
- High-risk AI embedded in regulated products (Annex I): pushed to 2 August 2028.
- Transparency duties under Article 50 (marking AI-generated content, disclosing that a user is talking to a machine): deferred a shorter distance, to 2 December 2026.
- The prohibited-use list (Article 5): unchanged in timing and, in fact, widened. The package adds new prohibitions rather than removing any.
One caveat that matters in practice: until the revised text is formally adopted and published, the original 2 August 2026 date is still the live one in law. A political agreement points a direction; it is not a signed instrument. Do not down tools on the strength of a press cycle.
What did not change
The list of obligations is the same list. Article 9 still wants a risk management process across the lifecycle. Article 12 still wants automatic logging for the life of the system. Article 14 still wants a human able to oversee and stop the system on consequential actions. Article 15 still wants accuracy, robustness, and cybersecurity that hold up under adversarial pressure. Article 17 still wants a quality management system around all of it.
None of that got easier. The bar is where it was. The regulator gave you more time to reach it. The bar itself did not drop.
The second thing that did not change is the shape of the work. These are not documents you write the week before an audit. Article 12 logging has to be running in production now to have anything to show in 2027. Article 15 robustness is measured by testing, and testing is an ongoing habit. The evidence an assessor reads is a record built over time. A record cannot be backfilled honestly.
Why the extra time exists, and why that is the real signal
The deadline moved for an unglamorous reason: the supporting machinery is not ready. The harmonised standards that tell a provider what "good enough" looks like for Article 15 are not final. The national authorities meant to supervise and certify are, in several member states, not yet designated or staffed. You were going to be asked to prove conformity against a target that had not finished being drawn.
Take it as a warning; it is not a gift. The target is still moving. A team that waits for the standards to settle and then starts will be doing a year of engineering inside a few months, against a fixed date, with auditors who have by then seen everyone else's homework. A team that starts now builds its logging, its test history, and its oversight controls while the standards harden, and shapes that evidence to match as the detail lands. The extra sixteen months are worth most to the people who treat them as build time.
The security team's reading of the four articles that land on you
Strip the legal language and four articles are engineering tickets.
- Article 9 (risk management). You need a written, living view of how each AI system can fail and what you do about it. For a model or agent, the failure modes are not the ones your application risk register already has. Prompt injection, tool misuse, training-data and retrieval poisoning, and unbounded resource use are model-layer risks. They belong in the same register, assessed on the same cadence.
- Article 12 (logging). Automatic records across the lifecycle. For an agent, that means the tool calls, the inputs that triggered them, and the decisions in between, kept in a form you can hand to an assessor. If you cannot reconstruct what the system did on a given day, you cannot show oversight of it.
- Article 14 (human oversight). A person has to be able to understand, supervise, and stop the system where its output can do harm. This is the article agentic systems break first. An agent that can write to a release pipeline or move money does a consequential thing; that path needs a human on the trigger, not a human reading a weekly summary.
- Article 15 (accuracy, robustness, cybersecurity). Robustness is proven by adversarial testing of the model and agent layer, not by a pen test of the web app in front of it. The probes that matter run injection, jailbreak, and tool-abuse payloads against the system the way an attacker would, and they run often enough to catch the week a prompt change reopens a hole.
A conventional security program does not produce this evidence. Cloud posture tools look at the infrastructure. Application scanners look at the code and the endpoints. Neither inspects the model and agent layer, which is exactly where the AI Act's high-risk obligations point. That gap is the work.
What to do with sixteen extra months
Spend them on the parts that only get harder if you wait.
- Inventory and classify first. You cannot show conformity for systems you have not listed. Find every model, agent, and retrieval pipeline in production, name an owner, and decide which ones fall in an Annex III category. Most teams underestimate the count by half once shadow deployments surface.
- Turn on the logging now. Article 12 evidence is the one thing you cannot produce retroactively. Every month it runs is a month of record you will have in 2027.
- Make testing continuous. A conformity assessment is a point in time. The system underneath it changes every sprint. Run adversarial probes on a schedule, map each finding to the article and control it touches, and keep the history. The finding history is the evidence an assessor trusts more than a snapshot.
- Put the human back on consequential actions. Walk every agent that can do something irreversible and confirm a person is on the trigger. This is cheap to fix now and expensive to explain later.
- Build the evidence trail into a framework. Tie findings to Articles 9, 12, 14, and 15, and to ISO 42001 controls where they overlap. When the harmonised standards finalise, you adjust a mapping rather than rebuild a program.
The systems that were never high-risk but still owe something in 2026
The deadline move is about high-risk systems. It is not a blanket reprieve. If you run a customer-facing assistant, the Article 50 transparency duties point at 2 December 2026, which is closer than the high-risk date by a year. Disclosing that a user is dealing with a machine, and marking AI-generated content, are small pieces of work, but they have a short clock and they apply to systems that most teams do not class as high-risk at all. Do not let the headline delay hide the date that is actually near.
Is the new deadline final?
Not yet, as of late June 2026. The political agreement is in place and the direction is clear, but the revised text still has to be formally adopted and published before the new dates are law. Plan against the new timeline, but keep the original 2 August 2026 date in view until the change is signed. The safe posture is to build as if the work is due, because the work is due regardless of which date it is due on.
Where this fits for a security team
The AI Act, read as engineering, asks for a continuous record that a model and agent estate is tested, logged, overseen, and improved. That is the job an AI security posture management program exists to do: run the adversarial tests on a schedule, map each finding to the article and framework control it touches, and keep the evidence in a form an auditor can read. Our EU AI Act conformity mapping ties scan findings to the specific obligations above, and the cross-framework view lines them up against ISO 42001 and NIST AI 600-1 so one body of evidence answers several questioners.
The deadline moved. The honest way to use the time is to stop treating conformity as a date and start treating it as a record you keep. For the detail of what the high-risk articles ask, our earlier note on EU AI Act cybersecurity requirements is the practitioner's walk-through.