Article 50 of the EU AI Act — the transparency obligations covering AI systems that interact with people, generate synthetic content, produce deepfakes, or perform emotion recognition and biometric categorisation — became applicable on 2 August 2026.

Most of it applied on that date. One obligation did not, for one class of systems.

The AI Omnibus provisional agreement reached in May 2026 gave generative AI systems already placed on the market before 2 August 2026 until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2). That is a four-month transitional window for legacy deployments, and it closes in fourteen weeks.

This site covered the Code of Practice on marking and labelling when the Commission published it in June, and what actually applied on 2 August at the start of this month. This piece is about the narrower and harder problem: retrofitting marking into systems that are already in production, which is a materially different engineering exercise from building it into something new.

What is actually deferred, and what is not

The distinction matters, because organisations have read the December date as a general Article 50 deferral. It is not.

Deferred to 2 December 2026 (for pre-existing systems only): the Article 50(2) obligation on providers of AI systems generating synthetic audio, image, video or text to ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated.

Applicable since 2 August 2026, with no extension:

  • Article 50(1) — providers must ensure systems intended to interact directly with natural persons are designed so that persons are informed they are interacting with an AI system, unless obvious from context.
  • Article 50(4) — deployers of a system generating or manipulating content constituting a deepfake must disclose that the content has been artificially generated or manipulated. Deployers of text published to inform the public on matters of public interest have a parallel disclosure duty.
  • Article 50(3) — deployers of emotion recognition or biometric categorisation systems must inform exposed persons.

So the chatbot disclosure, the deepfake labelling and the emotion-recognition notice are all already live. What is deferred is the technical marking of synthetic output by providers, and only for systems that were already on the market.

This has an awkward consequence worth stating plainly: a deployer’s Article 50(4) disclosure duty is already in force even where the provider’s Article 50(2) marking obligation is still in its grace period. A deployer cannot wait for December. Disclosure is a deployer act — a label, a notice, a visible indication — and it does not depend on the provider having implemented watermarking.

Why retrofit is the hard case

Building marking into a new system is a design decision. Adding it to a deployed one is a distribution problem, and the difficulty scales with how the system was built.

The output path is usually not one path. A generative feature that shipped eighteen months ago typically emits content through several routes: the primary API, a batch or asynchronous job, a webhook or callback, a cached or CDN-served variant, an export or download function, and one or more internal services that consume raw output. Marking applied at the primary path leaves the others unmarked. Enumerating every egress point is the first task, and in most organisations it takes longer than implementing the marking itself.

Metadata does not survive the pipeline. Signed C2PA-style metadata is the cleaner of the two mechanisms in the Code of Practice, and it is also the more fragile in practice. Image resizing, format conversion, social platform re-encoding, screenshotting and many CDN transformations strip or invalidate it. This is precisely why the Code of Practice pairs signed metadata with imperceptible watermarking: the watermark survives transformations that destroy the metadata. A retrofit that implements only metadata will be technically compliant at the point of generation and functionally useless downstream.

Text is genuinely harder than media. Watermarking images, audio and video is a solved-enough problem with available techniques. Robust, machine-readable marking of generated text that survives editing, truncation, paraphrase and copy-paste remains an open technical question. Article 50(2) covers text, and the honest position for most providers is that the state of the art constrains what is achievable. Article 50(2) does contain a proportionality reference to technical feasibility and the state of the art — but relying on it requires a documented technical assessment, not an assumption. Producing that assessment is itself a December deliverable.

Retrospective content is ambiguous. The obligation attaches to systems on the market, and the marking requirement operates on output. Content generated and distributed before implementation cannot practically be recalled and marked. Organisations should form a documented position on the boundary — new output marked from a stated date, with a record of the reasoning — rather than leaving the question open for a regulator to raise first.

Determine whether you are the provider. Article 50(2) is a provider obligation. An organisation deploying a third-party model through an API is generally a deployer, and the marking duty sits with the model provider — but an organisation that fine-tunes, white-labels, or places a generative system on the market under its own name may be a provider for that system. Article 25’s rules on when a deployer becomes a provider are the relevant test, and getting this wrong in either direction is expensive: assuming you are a deployer when you are a provider means missing an obligation entirely.

The February 2027 tail

There is a further date that the December deadline tends to eclipse.

Signatories to the Code of Practice must implement an interoperability solution for watermark detection mechanisms by 2 February 2027.

This is the provision that makes the regime work as a system rather than as a set of isolated implementations. A watermark only serves the AI Act’s transparency purpose if something other than the originating provider’s own tooling can detect it. Interoperable detection is what turns marking into a public capability, and it is what the Code’s commitment to free public detection and standardised EU labelling icons rests on.

For providers planning a December implementation, the practical implication is that choosing a proprietary watermarking scheme with no interoperability path buys eight weeks and then requires a second implementation. Selecting an approach aligned with emerging standards — C2PA Content Credentials for signed metadata, and watermarking schemes with published or standardising detection interfaces — is the decision that avoids doing this twice.

A fourteen-week plan

Weeks 1–3: establish role and perimeter. For every generative capability, determine whether your organisation is provider, deployer or both, and record the Article 25 reasoning. List every system that was on the market before 2 August 2026 — those are the ones in the grace period. Then map every output egress path for each: API, batch, webhook, cache, CDN, export, download, internal consumer. This list is the specification for everything that follows.

Weeks 4–6: choose the mechanisms and document feasibility. Select signed metadata plus imperceptible watermarking for audio, image and video, with an interoperable detection path. For text, produce a documented technical assessment of what is achievable given the state of the art, and what you will implement. Write it now — it is the artefact you will rely on.

Weeks 7–11: implement and verify at every egress point. The verification step is the one that gets cut and should not be. For each path, generate output and confirm the marking is present after the transformations that path applies. Test metadata survival through your own CDN and image pipeline specifically. Where it does not survive, the watermark is doing the work and must be verified independently.

Weeks 12–13: deployer-side disclosure, which is already overdue. Confirm that deepfake disclosure under Article 50(4), chatbot disclosure under 50(1), and emotion-recognition notice under 50(3) are live across every surface. These have been in force since August. If any are missing, that is a current non-compliance, not a December one.

Week 14: documentation and the February path. Assemble the compliance file: role determination, system inventory, egress map, mechanism selection, feasibility assessment for text, verification evidence per path, and the plan for interoperable detection by 2 February 2027.

The framing that helps

The December deadline is often described as a watermarking project. It is more accurately a content provenance capability, and the same capability satisfies a growing set of obligations: EU AI Act Article 50, California’s AI Transparency Act which became operative this month, and Connecticut’s CART Act provenance requirement from 1 October 2026.

Three jurisdictions, three statutes, one technical answer. Organisations building this as a Brussels compliance task will build it again for Sacramento and again for Hartford.

Fourteen weeks is enough to retrofit marking into a production system. It is not enough to first discover that the output leaves through six paths and only one of them was instrumented.

This article is provided for informational purposes only and does not constitute legal advice.