The EU AI Act deadline still landing on December 2, 2026

When the Digital Omnibus pushed the EU AI Act's high-risk obligations out to December 2027, a lot of teams filed the whole regulation under "next year's problem." Understandable reaction. Also wrong, because the same regulation kept a deadline in December 2026, and that one applies to a much wider set of products than the high-risk rules ever did.

The date is 2 December 2026. The obligation is transparency: marking AI-generated content so it can be recognized as AI-generated. If your product outputs text, images, audio, or video that a model produced, this is aimed at you, and no risk classification exercise gets you out of it.

What the Omnibus actually moved

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force three days later. It shifted four dates:

The Omnibus also added a new prohibition covering AI systems that generate child sexual abuse material or depict identifiable people's intimate parts without consent, extending to generated images, video, and audio. Providers have until 2 December 2026 on that too. Law firm summaries from White & Case and Orrick go through the full set of changes.

Notice the pattern. What got delayed is the heavy conformity-assessment machinery for a narrow band of systems. What didn't get delayed is the stuff that applies broadly and is comparatively cheap to implement. That's a fairly clear signal about where enforcement attention goes first.

Who this catches

Far more products than the high-risk rules. A rough sketch of the obligations in scope:

• Systems generating synthetic audio, image, video, or text need that output marked in a machine-readable format and detectable as artificially generated
• Systems interacting directly with people need to make it clear they're AI, unless it's obvious to a reasonably observant person
• Deepfakes need disclosure, as does AI-generated text published to inform the public on matters of public interest
• Emotion recognition and biometric categorisation systems need to inform the people exposed to them

Read that first bullet against your own product. A support chatbot generating replies. A feature that drafts marketing copy. An image tool. A voice summary. Most SaaS products shipped something in the last two years that lands in one of these buckets, usually without anyone classifying it as an AI system at all.

Why this is a QA problem and not just a legal one

Machine-readable marking is a technical control. Technical controls regress. That makes it exactly the kind of obligation that needs a test, not a policy document.

Think about how marking breaks in practice. Somebody adds a new output path that skips the marking middleware. An image pipeline gets a compression step that strips metadata. A CDN transform drops the watermark. A caching layer serves a pre-marking artifact. None of those produce a visible bug. The feature works, the output looks right, and the marking is gone.

The disclosure requirement fails just as quietly. A redesign moves the "AI-generated" label below the fold. A new entry point into the chat widget skips the disclosure screen. A translation drops the string.

Every one of those is testable, and none of them is caught by anything currently in your suite.

What to actually build before December

Start with the inventory, because you can't test a surface you haven't listed. Every place your product emits model-generated content to a user, including the ones added by a feature team that never talked to anyone about compliance. The classification questions in working out whether your AI feature is high-risk are a decent starting frame, though transparency has a much lower bar to clear than high-risk does.

Then add tests, in roughly this order:

1. Marking presence, per output path. For each generation endpoint, assert the machine-readable marker is present on the artifact the user actually receives. Assert it at the edge, after every transform, not at the point of generation.
2. Survival through the pipeline. Download the image the CDN serves and check the marker is still there. This is where most implementations will fail, and it will fail months after someone confirmed it worked.
3. Disclosure visibility in the UI. A browser test asserting the AI disclosure is present and visible on every entry point into a conversational surface. Entry points multiply. Test them as a set.
4. Localization. The disclosure has to exist in every locale you ship. Missing translation strings fall back silently in most i18n setups.
5. Regression gate on new endpoints. The useful long-term control is a check that fails when a generation endpoint exists without a corresponding marking test. Otherwise you're compliant on the paths that existed in November and unknown on everything added after.

Three months is enough time, barely

The implementation work here is small compared to a high-risk conformity assessment. The inventory is the slow part, because it means finding every feature anyone shipped with a model behind it, and in most organizations that list does not exist in written form.

That's the thing to start this week. The tests take an afternoon once you know what to point them at. Finding out what to point them at is the part that takes until November if you begin in October. And the ownership question, which we went through in who owns EU AI Act compliance, has the same answer as before: legal can tell you what the obligation is, but only engineering can tell you where the model-generated content comes out.

qtrl runs browser-level tests against what users actually receive, which is where transparency obligations live. Disclosure visible on every entry point, in every locale, on the artifact the CDN served rather than the one the service generated.

Every run is recorded with what it checked and when, so when someone asks how you know your marking held through a quarter of redesigns, you have a continuous record instead of a screenshot from the week you shipped it. See how it works.