In July a lot of product teams read one headline: “EU AI Act delayed.” Some of them moved the AI Act ticket to next year and went back to the roadmap.
The delay is real, but only for high-risk systems. It did not touch EU AI Act Article 50, the transparency rules that hit chatbots, image generators and anything else that produces synthetic content. Those have applied since 2 August 2026. And one Article 50 date still lands this year: 2 December 2026, when generative products that were already on the EU market have to mark their output in a machine-readable way.
This post is the build list we would work from: what applies when, who it applies to, and what has to ship in the 44 days between today (19 October) and 2 December.
This is an engineering view of what to build, not legal advice. Check scope and dates for your product with qualified EU counsel.
What actually moved, and what did not
The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk rules: Annex III systems (hiring, credit, education and similar) to 2 December 2027, and Annex I systems (AI inside EU-regulated products) to 2 August 2028. Article 50 kept its date of 2 August 2026. The only Article 50 relief is a four-month grace for output marking, and it ends on 2 December 2026.
The dates that matter for generative products
| Date | What applies | Source |
|---|---|---|
| 2 Aug 2026 | Article 50 transparency duties: AI disclosure, output marking, deepfake and public-interest text labels | AI Act Art. 50, Art. 113 |
| 2 Dec 2026 | End of the marking grace for generative systems placed on the market before 2 Aug 2026 | Art. 111(4), inserted by 2026/1744 |
| 2 Dec 2026 | New bans on AI that generates non-consensual intimate imagery of real people, or CSAM | Art. 5(1)(ba), (bb), 5(1a), 5(1b) |
| 2 Feb 2027 | Interoperable watermark detection, for Code of Practice signatories only (a code commitment, not a legal deadline) | Code of Practice, Measure 3.4(c) |
| 2 Dec 2027 | High-risk rules for Annex III systems | Amended Art. 113(c)(i) |
| 2 Aug 2028 | High-risk rules for Annex I systems | Amended Art. 113(c)(ii) |
The Commission keeps its own implementation timeline if you want a second reference.
Why “delayed” stuck
The high-risk move was the big news, so it became the headline. Two other things kept the confusion going. Early coverage of the Commission’s proposal described high-risk dates tied to when standards became available; the adopted text uses fixed dates. And proposal-stage material talked about a six-month marking grace. The adopted regulation says four months (Recital 38), ending 2 December 2026. If a page you are reading still says six months, it is quoting the proposal.

Are you a provider or a deployer?
This question decides your backlog. A provider puts an AI system on the market under its own name. A deployer uses an AI system under its own authority in a professional setting. Providers disclose and mark. Deployers label.
Being outside the EU does not take you out of scope. Article 2(1)(a) covers providers placing systems on the EU market “irrespective of whether those providers are established or located within the Union or in a third country”, and Article 2(1)(c) covers third-country providers and deployers where the system’s output is used in the Union.
Most SaaS teams are both
Here is a common pattern (an example, not a client story). You wrap a model API inside your product and sell it to EU customers under your brand. You also use the same model to write articles and make images for your own marketing site. On the product side you probably look like a provider. On the marketing side you are a deployer.
Where exactly an API wrapper sits is a question for counsel, and the Commission’s guidelines are the place to start. For planning, assume you hold both roles until someone qualified tells you otherwise. It is cheaper to drop work than to discover it in November.
The 2 December 2026 grace, read carefully
Here is the full rule, from new Article 111(4):
“Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, that have been placed on the market before 2 August 2026 shall take the necessary steps in order to comply with Article 50(2) by 2 December 2026.”
Who gets it
Three conditions, all at once: you are a provider, your system generates synthetic audio, image, video or text, and it was placed on the market before 2 August 2026. The text says “placed on the market”. Some earlier Commission material also said “put into service”, so if your system was only ever used in-house, do not assume the grace applies. Ask counsel.
What it does not cover
- Article 50(1): telling people they are talking to an AI. Due since 2 August 2026.
- Article 50(3): informing people exposed to emotion recognition or biometric categorisation. Due since 2 August 2026.
- Article 50(4): deepfake labels and labels on AI-written public-interest text. Due since 2 August 2026.
- Anything you launched on or after 2 August 2026. Those systems needed marking from day one.
It is not retroactive
The Commission’s Article 50 FAQ says content generated before 2 August 2026 does not need to be labelled retroactively. You do not have to go back through your archive. You do have to mark what your system generates from now on.
Build item 1: tell people they are talking to AI (Art. 50(1) and 50(5))
If people interact with your AI system, they need to know, clearly, at the latest at their first interaction. This has been due since August.
The patterns we would ship:
- A persistent label in the chat header, not just a line in the first message that scrolls away.
- A first-message notice that names the assistant as AI.
- A spoken prefix for voice agents, before anything else is said.
- Real text for screen readers, not an icon with no accessible name.
There is an exception when it is obvious from context that you are dealing with an AI, but the Commission FAQ reads it narrowly. Show the notice anyway. The same applies to AI agents that act for users, which the FAQ names as interactive systems. If you run agents that email or message people on a customer’s behalf, the disclosure question follows them (we covered agent containment in our MXC sandboxing post).
For evidence, log that the notice rendered: notice version, session ID, timestamp. That one log line answers “can you show users were told?”
Build item 2: machine-readable marking (Art. 50(2))
This is the December item. Providers of generative systems have to mark output in a machine-readable format so it can be detected as AI-generated. The Act does not name a technique. The Commission’s Code of Practice on transparency of AI-generated content does get specific.
Two layers, per the Code of Practice
For audio, image, video and containerised text, the code asks signatories for at least two layers of machine-readable marking: digitally signed metadata and an imperceptible watermark. Fingerprinting or logging can be added, but they are not enough on their own. Free-form text cannot carry metadata, so for plain text a watermark alone is accepted.
The code is voluntary. The Commission has assessed it as adequate for Article 50(2), (4) and (5). If you do not sign it, you have to show “alternative adequate means”, and the Commission FAQ says you may get more information requests.
Signed metadata: our pick is C2PA
Neither the Act nor the code names a metadata standard. Our engineering recommendation for the signed metadata layer is C2PA Content Credentials, because it is an open spec with signed manifests and tooling already in many media pipelines.
In practice: write a C2PA manifest at generation time that asserts the content was AI-generated, and sign it with your key. That signing key is now a production secret. Treat it the way we described in agent tool access without the keys: a managed store, no keys in code, and rotation planned before you need it.
Watermarking
You can watermark at the model level or after generation. If you use a third-party model, find out what your upstream provider already embeds and what detection it offers. The code is clear that you stay responsible for your own system’s output, whatever the upstream does.
Where these marks fall short
Metadata gets stripped. Screenshots, re-encoding and plenty of upload pipelines drop it. Watermarks on short text are weak. Detection only helps if other people can actually run it, which is why the code asks for detection that others can reach. No single layer holds up on its own, which is why the code asks for two.
Do not strip your own marks
Before you blame social platforms, check your own pipeline. Image resizing, thumbnail jobs, CDN optimisation and export features often drop metadata. The code asks signatories not to remove marks, and a product that signs an image and then strips it in the resize step has done the work twice for nothing. Add a test that generates an asset, runs it through every path to the user, and checks the manifest and watermark survive.
Build item 3: deepfake and public-interest text labels (Art. 50(4))
Deployers who publish deepfakes have to say so. Under Article 3(60), a deepfake is AI-generated or manipulated image, audio or video that “resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful”. The label has to be perceivable without tools: a visible or audible label, not just metadata. The Commission FAQ says deployers cannot simply rely on the provider’s machine-readable marking for this. The EU has published icons for labelling AI-generated content you can use.
For clearly artistic, satirical or fictional work, the disclosure can be lighter, in a way that does not spoil the work.
AI-written text published to inform the public on matters of public interest needs a label too, unless it “has undergone a process of human review or editorial control” and a person or company holds editorial responsibility. The Commission FAQ says a spell-check or grammar pass does not count as review.
The build here is a workflow state. Add a “reviewed by” step with an approver record (who, when, which version) before AI-written public-interest content can publish without a label. If you already have a human review step for agent actions, the same pattern works here.
Build item 4: the evidence trail
Whether or not you sign the code, assume someone will ask you to show your work. The list we would keep, per product:
- Marking configuration per model and content type (which layers, which tool, which version).
- Robustness test results for the marks, re-run when the pipeline changes.
- Disclosure render logs from build item 1.
- Label decisions and reviewer IDs from build item 3.
- A register of each generative product with its first EU placement date, because that date decides whether the grace ever applied.
This is the same discipline as the proof packs we wrote about for a different law: dated artefacts, an owner, a manifest. Keep the logging here to Article 50 evidence. Deeper audit-trail design for AI decisions is its own topic.
The new December bans are a product-safety check
From 2 December 2026, Article 5 also prohibits AI systems that generate non-consensual intimate imagery of identifiable people, or child sexual abuse material. Article 5(1a) reaches systems where that output is “a reasonably foreseeable and reproducible outcome” and adequate safeguards are missing.
If you ship image or video generation, red-team for exactly this, fix what you find, and write down the safeguards you have in place. Breaches of Article 5 sit in the highest penalty tier, up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher. Article 50 breaches sit in the tier of up to EUR 15 million or 3% (Article 99(4)(g)). For SMEs, and now small mid-caps, the lower of the two figures applies.
The India angle: you may already be building half of this
If you are an Indian SaaS company selling generative features to EU customers, Article 2 puts you in scope. India’s own rules already point the same way.
MeitY’s IT Amendment Rules, 2026, in force since 20 February 2026 (MeitY FAQ), require intermediaries that enable synthetically generated information to label it prominently and embed permanent metadata or another technical provenance mechanism, including a unique identifier, where technically feasible. A further amendment that would keep labels visible for the whole duration of the content is still a draft.
One provenance pipeline (a signed manifest, a watermark and a visible label) can serve both regimes. The legal triggers differ, though. MeitY’s rule binds intermediaries; Article 50(2) binds providers of generative systems. You can be one, the other, or both, so map each product separately. If you already followed the DPDP build roadmap, the logging and ownership habits carry straight over.
A 44-day plan if you paused in August
From 19 October to 2 December is 44 days. That is enough if you start this week.
| When | What to do |
|---|---|
| Week 1 | Inventory every generative feature. Record its first EU placement date and your role (provider, deployer, both). |
| Weeks 2 to 4 | Add signed metadata and a watermark to the generation path. Find and fix every place your own pipeline strips them. |
| In parallel, now | Ship disclosure UI and the label workflow. These were due on 2 August, so they are already late. |
| Final week | Assemble the evidence pack, decide whether to sign the Code of Practice, and get counsel to review scope and dates. |
If the inventory shows a product launched after 2 August without marking, move it to the top. It never had a grace.
What the delay did buy you
The Omnibus did give you time, just not for Article 50. If anything you build is high-risk under Annex III (hiring, credit, education), you have until 2 December 2027. AI inside regulated products under Annex I has until 2 August 2028. That is enough time to build risk management, data governance, logging and human oversight in from the start, instead of adding them in the last quarter. Use it. A year passes quickly when the ticket sits in the backlog.
Where Bluelupin fits
Bluelupin builds the plumbing this post describes into AI products: disclosure UI, C2PA signing and watermarking in the generation path, label and review workflows, and the evidence logs behind them. If you want an engineering read of your generative features against these dates, we can walk your stack with your team and show you what is missing before 2 December.
Again: this is an engineering view of what to build, not legal advice. Check scope and dates for your product with qualified EU counsel.