EU AI Act 2026: The Deadline Moved, But Not All of It

The deadline moved

Regulation (EU) 2026/1744 — the Digital Omnibus on AI — was published in the Official Journal on 24 July 2026 and entered into force on 27 July, five days before the AI Act's high-risk obligations were due to apply. It defers them by sixteen months.

Annex III is the list that catches most enterprise software: AI used in employment and worker management, education access, creditworthiness and insurance pricing, essential public services, biometrics, critical infrastructure, law enforcement.

The Omnibus also narrowed the definition of "safety component" so systems that merely assist a human fall out of high-risk, moved machinery products from Annex I Section A to Section B, extended SME exemptions to small mid-cap enterprises, simplified registration for Article 6(3) self-assessed systems, and created an EU-level regulatory sandbox.

The deferral followed a standards failure. CEN and CENELEC missed their April 2025 deadline for the harmonised standards that specify what "appropriate data governance" or "adequate accuracy and robustness" concretely require, and the Commission's Article 6 classification guidance was outstanding too. One detail matters more than the deferral itself: the Omnibus replaced what had been a conditional trigger — obligations applying once standards became available — with fixed calendar dates. December 2027 is not contingent on anything.

What applied on 2 August 2026 anyway

Here is the part the "deadline moved" headlines buried. Article 50 — the transparency regime — was left completely untouched, and it applied on schedule. So did the AI Office's full enforcement powers.

Article 50 is short, and it's the article most likely to apply to a product you have already shipped. Four obligations, in engineering terms:

50(1) — Disclosure of AI interaction. If your system interacts directly with a natural person, that person must be informed they're dealing with an AI, unless it's obvious from context. This covers your support bot, your onboarding assistant, your in-app copilot. The disclosure has to happen at or before the first interaction.

50(2) — Machine-readable marking of synthetic output. Providers of systems generating synthetic audio, image, video, or text must mark outputs in a machine-readable format, detectable as artificially generated or manipulated. This is a provenance-metadata requirement, not a visible watermark — C2PA-style content credentials are the obvious implementation. Systems already on the market before 2 August 2026 have until 2 December 2026 to comply.

50(3) — Emotion recognition and biometric categorisation. Deployers must inform the people exposed to these systems.

50(4) — Deepfakes and public-interest text. Deployers must disclose artificially generated or manipulated image, audio, or video content. For AI-generated text published to inform the public on matters of public interest, disclosure is required unless the content underwent human review and someone holds editorial responsibility.

None of that was deferred. If you shipped a chatbot without a disclosure line, or a generative feature without provenance marking, you are late as of two weeks ago — not in December 2027.

Two more things stayed put. The Article 5 prohibited-practices regime has been enforceable since February 2025, and the Omnibus added to it: two new prohibitions covering non-consensual intimate imagery and CSAM generation apply from 2 December 2026. And the penalty ceilings are unchanged — €35M or 7% of turnover for prohibited practices, €15M or 3% for most other infringements, €7.5M or 1% for supplying incorrect information.

The trap in the grandfathering clause

Article 111 grandfathers systems placed on the market before the relevant application date. Read quickly, it sounds like a free pass for anything already shipped.

The exception eats the rule: the grandfathering falls away if the system is subject to significant changes in design.

For classic enterprise software with an eighteen-month release cadence, "significant design change" is a rare, deliberate event you can point at in a changelog. For an AI feature under continuous deployment, it isn't. You swap the base model when a cheaper one lands. You rewrite the system prompt on a Thursday because retrieval quality dipped. You add a tool call, then three more. You raise the temperature. Six months of that, and the system in production has very little in common with the one you "placed on the market."

There's no bright-line test for when accumulated changes cross into significant modification. What there is, is an evidentiary problem. If a regulator asks in 2028 what your system looked like in July 2026 and how it evolved, "we don't keep that" is the worst available answer — and it's the default answer for most teams, because model IDs, prompt versions, and parameter changes typically live nowhere durable.

This is the strongest argument for not treating the deferral as permission to stop. You can build a conformity assessment in 2027. You cannot reconstruct 2026.

What to build in the next sixteen months

Sort the deferred obligations into two buckets: paperwork you can produce on demand, and evidence that has to accumulate over time. Defer the first. Start the second now.

1. A durable record of what you actually sent

Article 10's data governance requirements and Article 12's record-keeping obligations both assume you know what flows through your AI systems. For a deployer building on OpenAI, Anthropic, or Gemini, that means knowing what left your infrastructure — not in the abstract sense of "customer support messages," but as an auditable record.

Article 26(6) will require deployers of high-risk systems to retain logs for at least six months. Six months of retention starting in December 2027 is trivial to configure. Six months of retention covering the period a regulator asks about is only possible if you started earlier.

The practical minimum per request: timestamp, model and version, prompt template and its version, parameters, the system that made the call, and a reference to the end user or session — without the personal data itself sitting in your log store. That last part is where most implementations go wrong, and it's why logging LLM traffic without leaking PII is its own engineering problem rather than a config flag.

2. Data minimisation at the boundary

Article 10 asks for appropriate data governance. GDPR Article 5(1)(c) already asked for minimisation, and GDPR was never deferred — a point worth repeating internally when someone proposes to pause all compliance work until 2027.

The concrete version: personal data that doesn't need to reach a model provider shouldn't. Redaction at the egress boundary satisfies both regimes at once and is far cheaper than a data processing agreement negotiation per provider. Our GDPR-compliant AI development guide covers the mechanics, and zero-retention AI processing covers the provider-side controls that pair with it.

3. Prompt versioning as a documentation artifact

Article 11 technical documentation asks providers to describe how the system works. For LLM-backed features, the system prompt is a substantial part of how it works — it encodes the constraints, the refusals, the tone, the guardrails.

If prompts live as string literals in application code, your documentation story is "read the git history of eleven files." If they're versioned as first-class artifacts with a changelog, you can answer "what were this system's instructions on 14 August 2026" in one query. That's the same infrastructure argument as separating prompts from code, arriving from a compliance direction.

4. A classification register

One table, one owner, reviewed quarterly: every AI feature you run, what it does, whether it touches an Annex III use case, whether you're provider or deployer for it, and which Article 50 disclosures apply.

Most teams discover two things filling this in. First, they have more AI surfaces than anyone thought — someone shipped a summarisation feature into the admin panel and told no one. Second, the genuinely high-risk candidates are usually one or two systems, not the whole portfolio. That converts an unbounded compliance problem into a scoped one.

5. Close out Article 50 this quarter

This is the only item with a live deadline. Audit every user-facing AI surface for disclosure, and every generative output path for machine-readable marking. If you had generative features in market before 2 August 2026, marking is due 2 December 2026.

How Grepture helps

Most of what's above is an infrastructure problem wearing a legal costume. The obligations that are hard to retrofit — durable records, minimisation at the boundary, prompt version history — are all properties of the layer between your application and the model provider. If that layer doesn't exist, every one of them becomes a per-service change.

Grepture is that layer. Requests route through the gateway, which redacts personal data before it reaches the provider, records what was sent with a reversible mapping, and attributes every call to a prompt version, model, team, and environment.

For the record-keeping side, tag calls with the system they belong to so a later export is scoped rather than a grep:

import OpenAI from "openai";
import { Grepture } from "@grepture/sdk";

const grepture = new Grepture({
  apiKey: process.env.GREPTURE_API_KEY!,
  proxyUrl: "https://proxy.grepture.com",
});

// Attribute every downstream call to a named AI system and its
// AI Act classification — these land on the request record.
grepture.setLabel("claims-triage");
grepture.setMetadata({
  system: "claims-triage",
  classification: "annex-iii-candidate",
  owner: "risk-ops",
});

const openai = new OpenAI({
  ...grepture.clientOptions({
    apiKey: process.env.OPENAI_API_KEY!,
    baseURL: "https://api.openai.com/v1",
  }),
});

Every request through that client is logged with the model, the prompt version, the redaction rules applied, and the metadata above — which is most of an Article 12 record, produced as a side effect of making the call rather than as a separate compliance project. Our compliance reporting and audit trail guide covers the export side.

The February guide to the AI Act still holds for the substance of the obligations — Articles 10, 11, and 14 didn't change. Only the dates did.

Key takeaways

• +Regulation (EU) 2026/1744 entered into force 27 July 2026, deferring Annex III high-risk obligations to 2 December 2027 and Annex I embedded systems to 2 August 2028.
• +Article 50 transparency applied on schedule. Chatbot disclosure and machine-readable marking of synthetic output are enforceable now; systems already in market have until 2 December 2026 to add marking.
• +Article 5 prohibitions, GPAI obligations, and the €35M/7% penalty ceilings are unchanged — and two new prohibitions land 2 December 2026.
• +The new dates are fixed, not conditional. The Omnibus removed the standards-availability trigger, so there is no second deferral written into the text.
• +Start the evidence now, defer the paperwork. Conformity documentation can be written in 2027. Request logs, prompt history, and redaction records covering 2026 cannot be backfilled — and Article 111's grandfathering is worth little to a system under continuous deployment.