The 2 December 2026 Deadline Nobody Is Watching: Article 50(2) Machine-Readable Marking, C2PA, and Why One Watermark Is Not Enough
The 2 December 2026 deadline for legacy systems is the one most teams have not diarised, and the assumption underneath that gap is that a single watermark closes Article 50(2). It does not. If you ship generative AI into the EU, the practical question this autumn is not whether you have AI watermarking at all, but whether you can evidence a marking architecture that holds up when the mark is stripped, recompressed, screenshotted or paraphrased. That is where C2PA, Content Credentials and machine-readable marking stop being a procurement decision and start being a documentation problem.
Most of the compliance conversation this year has been about high-risk classification. Meanwhile the transparency obligations have quietly gone live, and the EU AI Act Article 50 regime for AI generated content labeling is the part with a hard date in eleven weeks.
What Article 50(2) actually requires
The operative text is short. Article 50(2) requires providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content to ensure that the outputs "are marked in a machine-readable format and detectable as artificially generated or manipulated."
Four qualifiers sit in the same paragraph, and they are the whole argument. The marking must be "effective, interoperable, robust and reliable as far as this is technically feasible", taking account of the specificities and limitations of content types, the costs of implementation, and "the generally acknowledged state of the art, as may be reflected in relevant technical standards."
Teams read "as far as this is technically feasible" as an escape hatch. It is not. It is a reasoning standard. The clause ties feasibility to the generally acknowledged state of the art, which means the benchmark moves as the field moves, and it means a market surveillance authority asking why you stopped where you stopped will expect an answer grounded in what was achievable at the time, not in what was convenient. If you cannot show the analysis, you have not met the qualifier, you have asserted it.
There is a scope carve-out. The obligation does not apply "to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data provided by the deployer or the semantics thereof", or where authorised by law to detect, prevent, investigate or prosecute criminal offences.
One caveat you should carry into any internal memo. The official Article 50 page carries a notice that the provision has been amended by the Digital Omnibus and that the consolidated text is not yet updated, so the wording quoted above is the 2024 original. Check the consolidated text before you quote it in a filing.
Providers mark, deployers disclose
Article 50(2) binds providers. Article 50(4) binds deployers of AI systems generating deepfakes, who must disclose that the content has been artificially generated or manipulated. Different actors, different obligations, and the Commission has closed the obvious shortcut.
The Commission's FAQ states that deployers "cannot simply rely on the machine-readable marking embedded in the content by the provider under Article 50(2)" to discharge their own Article 50(4) duty. (Commission FAQ)
That matters commercially. If you are a provider selling into enterprise deployers, your customers need a disclosure surface, not just an embedded manifest. If you are a deployer, your vendor's C2PA conformance does not transfer the duty to you.
What is out of scope
The FAQ draws the boundary usefully. Out of scope: short sequences of numbers, symbols or letters; source code; machine-to-machine outputs never exposed to humans; and outputs used only in closed-loop industrial or product-development environments, unless they are the final output. A narrow business-to-business and industrial exemption is envisaged, subject to conditions set out in the Guidelines. (Commission FAQ)
Content generated before 2 August 2026 does not need to be labelled retroactively. That is a real relief for backfills, and it is narrower than people assume: it covers the content, not the system.
On timing. Article 50 has applied since 2 August 2026. The only concession is a grace period on Article 50(2) alone: providers of AI systems placed on the market before 2 August 2026 must comply "only as from 2 December 2026." (Commission FAQ)
Worth saying plainly, because the confusion is widespread: the Digital Omnibus did not touch this. Regulation (EU) 2026/1744, the Digital Omnibus on AI, is dated 8 July 2026 and entered into force on 27 July 2026. Its headline effect is elsewhere, deferring high-risk obligations to 2 December 2027 for standalone Annex III systems and 2 August 2028 for systems embedded in regulated products. It did not defer Article 50.
The Code of Practice: voluntary, privileged, and two layers deep
The Code of Practice on Transparency of AI-generated Content was published in final form on 10 June 2026, following drafts on 17 December 2025 and 3 March 2026.
It is voluntary, but not neutral. Signatories can rely on the Code to demonstrate compliance with Article 50(2), (4) and (5), while non-signatories "will have to demonstrate compliance through alternative adequate means" and "may be subject to more requests for information." Around 190 organisations had signed by the end of July 2026. (Code text)
Here is the finding most readers will not expect. The Code never names C2PA or Content Credentials anywhere in its 38 pages. It is technology-neutral and speaks instead of "digitally signed metadata" and "imperceptible watermarking."
So if your compliance narrative is "we implemented C2PA, therefore we are aligned with the Code", you have skipped a step. The Code specifies functions. C2PA is one implementation of one of those functions. You still have to show the function is performed.
And two layers are mandatory, not recommended. Because no single marking technique can by itself meet the four statutory requirements under the state of the art, signatories "will implement a multi-layered marking approach" using "at least two layers of machine-readable marking" (Sub-measures 1.1.1 and 1.1.2).
Sub-measure 1.1.1 covers digitally signed metadata: record in metadata whether content is AI-generated or manipulated, "digitally signed and time-stamped... in a secure and tamper-evident manner", with accompanying key-handling duties. Sub-measure 1.1.2 covers imperceptible watermarking, and sets an explicit text threshold: "For free-form text longer than 200 tokens, watermarking still needs to be applied, even though it may have lower reliability." Free-form text receives a single-layer exemption because it "cannot transport metadata."
Note what that does to a chat product. Long-form text output over 200 tokens needs a watermark even where the Code concedes the watermark will be weaker. Lower reliability is not a reason to skip it.
The two mandatory layers, side by side
| Layer | What it is | What it survives | What it does not survive |
|---|---|---|---|
| Digitally signed metadata (Sub-measure 1.1.1) | A tamper-evident, cryptographically signed and time-stamped record in the asset's metadata declaring that content is AI-generated or manipulated, with key management duties attached | Passive redistribution where the container is preserved; casual copying; verification at any point the file itself is intact | Routine metadata stripping by social media and professional publishing software; screenshot and screencasting; the analogue hole, for example print-and-scan; re-encoding into a container that drops the manifest. Formal-methods analysis also found timestamp disagreement, revocation gaps and an exclusion-range weakness in the specification itself |
| Imperceptible watermarking (Sub-measure 1.1.2) | A signal embedded in the content itself, detectable by a matching detector; mandatory for free-form text over 200 tokens, with the Code conceding lower reliability there | Recompression, cropping, rescaling, rotation, screenshotting and, in principle, print-and-scan, since the signal travels with the pixels or tokens rather than the container | Demonstrated adversarial removal: MarkNull drives average bit accuracy to near chance without visible degradation. For text, paraphrasing, translation cycles and homoglyph substitution are named in the Code's own attack list. Also fails where no detector is available to the verifier |
Both "does not survive" columns come from the Code itself. Measure 3.3 on robustness names the attacks marks must survive: recompression, screenshot and screencasting, cropping, rescaling, rotation, paraphrasing, translation cycles, homoglyphs, and survival of "the analogue hole, e.g. print-and-scan", plus adversarial copying, removal, regeneration and modification attacks. (Code text)
Why one layer is not enough
This is not a theoretical hedge. There is published work on both sides of the pair.
Watermark removal is demonstrated, not speculative: the MarkNull attack reduces average watermark bit accuracy to 53.14%, where random chance is 50%, without perceptible image degradation, at 0.50 seconds per image amortised. The authors state it compromises SynthID-Image. (arXiv) A detector reading 53% against a 50% floor is, for evidentiary purposes, not reading anything.
On the metadata side, the first formal-methods analysis of C2PA, conducted against specification version 2.2, found that generators and validators fail to agree on the trusted timestamp, that inadequate certificate revocation lets conforming validators accept manifests signed with compromised certificates, and that the exclusion range enables undetectable alterations. It concluded that C2PA "does not yet provide the guarantees required for reliable deployment." Some fixes landed in C2PA version 2.3. (ePrint)
And then the mundane failure mode, which does more damage than any attack. Content delivered through social media or professional publishing software routinely has its metadata stripped. (T. Bray) We are not going to put a number on that, because none is established.
The Code's own remedy here is weaker than most people assume. Preservation of markings by platforms is only encouraged, not required: signatories operating online platforms or search engines "are encouraged to ensure that the online platform or the search engine preserves metadata markings" (Measure 1.2). Signatories must, however, ban circumvention tools and prohibit metadata tampering in their terms.
So: layer one is routinely destroyed in normal distribution, and layer two is removable by a documented attack in half a second per image. Each layer covers part of the other's blind spot. Neither alone is a defensible position, which is precisely the reasoning the Code encodes.
One vendor has published its approach in enough detail to be useful as a reference point. In May 2026, updated in July, OpenAI became a C2PA Conforming Generator Product, adopted SynthID watermarking for images from ChatGPT, Codex and the API, launched a public verification page at openai.com/verify, and extended SynthID to audio in July. (OpenAI) That shape, signed manifest plus watermark plus a public detection surface, is the architecture the Code describes, arrived at independently of it.
The standards vacuum behind the deadline
Article 50(2) points at "relevant technical standards." There is less there than the phrasing implies.
The C2PA specification is at version 2.4. It is a specification, not a standard. ISO 22144 on content credentials is under development at ISO/TC 171/SC 2, at stage 30.99. It is not a published standard. Say that out loud in any internal review where someone claims otherwise.
And the European route does not fill the gap. CEN-CENELEC JTC 21 has no watermarking or content-marking deliverable. The Commission's standardisation request covers ten areas: risk management, data governance, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, quality management and conformity assessment. Article 50 marking is not among them.
Sitting on top of that incomplete stack is a commitment with a date. Signatories "will implement an interoperability solution for their detection mechanisms by 2 February 2027." The Code itself concedes that relevant interoperability standards and best practices "are yet to be developed, except for digitally signed metadata."
Read those two sentences together. Signatories have committed to interoperable detection by February, and the Code acknowledges the standards for achieving it, outside metadata, do not exist. That is the honest state of play, and it is also why your own documented reasoning carries more weight here than it would in a mature standards environment. The Commission published Guidelines on transparency obligations for providers and deployers of AI systems on 20 July 2026.
Provider checklist
- Choose your two layers explicitly. Write down which technique performs Sub-measure 1.1.1 and which performs 1.1.2, per content type. Audio, image, video and text will not have the same answer.
- Sign and timestamp metadata with real key management. The Sub-measure 1.1.1 language is "secure and tamper-evident", with key-handling duties. That is an HSM and rotation question, not a library-import question. The formal-methods findings on revocation are directly relevant to how you handle compromised certificates.
- Watermark free-form text over 200 tokens. The Code is explicit that lower reliability does not excuse omission.
- Test against the Code's own attack list. Recompression, screenshot and screencast, crop, rescale, rotate, paraphrase, translation cycle, homoglyphs, print-and-scan, plus adversarial copying, removal, regeneration and modification. Keep the results. Failures you have measured and documented are a stronger position than successes you have assumed.
- Decide whether to sign the Code, and record the decision. Signing buys the presumption route. Not signing means demonstrating compliance by alternative adequate means and accepting more requests for information.
- Stand up a detection endpoint. You need one anyway for the 2 February 2027 interoperability commitment, and a public verification surface is what makes your marking useful to anyone downstream.
- Document your state-of-the-art reasoning. Cite the specification versions you implemented, the standards that do not yet exist, the attacks you tested and the residual risks you accepted. This turns "technically feasible" into an evidenced position rather than an assertion. It is the single highest-value artefact in this whole exercise.
For deployers
If you generate deepfakes, Article 50(4) requires you to disclose that the content has been artificially generated or manipulated. For artistic, satirical or fictional works the duty is limited to disclosure "in an appropriate manner that does not hamper the display or enjoyment of the work". AI-generated text published to inform the public on matters of public interest is also covered, with an exemption where the content underwent human review and a person holds editorial responsibility. (Article 50)
Three practical consequences. Your disclosure has to be your own, because provider marking does not discharge it. The editorial-responsibility exemption for public-interest text is a workflow claim, so name the person and keep the review record. And the artistic carve-out limits the manner of disclosure, not the fact of it.
The calendar, and the exposure
Article 50 applied from 2 August 2026. Systems placed on the market before that date must meet Article 50(2) from 2 December 2026. Signatories have committed to detection interoperability by 2 February 2027. Penalties for Article 50 breaches reach EUR 15 million or 3% of total worldwide annual turnover, whichever is higher, with enforcement sitting mainly with national market surveillance authorities. (Commission FAQ)
On enforcement, the honest position: no public enforcement action, fine or national authority statement on Article 50 has been taken. The first cases will define what "technically feasible" means in practice, and they will be decided on documentation as much as on engineering.
What to do this month
Pull the list of AI systems you had on the market before 2 August 2026. For each, name the two marking layers, identify the content types where you have only one, and start the attack testing now rather than in November, because the results feed the reasoning memo and the memo takes longer than the code. If you are a deployer, separate your Article 50(4) disclosure from whatever your provider embeds, and write down who holds editorial responsibility for public-interest text.
If you want a second pair of eyes on how your marking architecture maps against Article 50(2) and the Code's two-layer requirement before 2 December, get in touch.
Related reading

The AI Governance Operating Model: Who Owns What, Who Signs, and How to Build the Machine
Most AI governance frameworks fail not because the policy is wrong but because nobody owns anything. Here's how to build the operating model that actually works - roles, RACI, forums, inventory, and a first-90-days plan.
The Cyber Resilience Act and the EU AI Act: Reporting Went Live on 11 September 2026 - What AI Product Makers Must Do Now
Since 11 September 2026, makers of software and connected products, including most AI products, must report actively exploited vulnerabilities within 24 hours under the Cyber Resilience Act. Here is how CRA reporting works, how CRA Article 12 links to AI Act Article 15, and how to build one incident playbook for both.
EU AI Act News: What the First 60 Days of Enforcement Actually Produced (August-September 2026)
2 August 2026 was supposed to be the day the EU AI Act got teeth. Sixty days later, here is what actually happened: the AI Office's first information requests to GPAI providers, a transparency Code of Practice with 200+ signatories, a new complaints tool, and a string of GDPR decisions that show where AI enforcement is really coming from.