C2PA and AI watermarking for EU AI Act Article 50

Article 50(2) of the EU AI Act requires providers of generative AI systems to mark outputs in a machine-readable, detectable way, and the Code of Practice of June 2026 asks for at least two techniques. This guide explains the two layers most teams combine, C2PA Content Credentials and an AI watermark, what each one survives and where each one breaks, and how they fit into a generation pipeline. It reviews the research on image and text watermarking and on removal attacks, gives a reference architecture and a test plan, and separates the provider's marking duty from the deployer's labelling duty.

Keywords C2PA · AI watermarking · Content Credentials · Article 50 AI Act · SynthID · provenance · deepfake labels

Article 50(2) of the EU AI Act requires providers of generative AI systems to mark their outputs in a machine-readable format, so that it can be detected that the content was artificially generated or manipulated^[1]. The Code of Practice published in June 2026 makes this concrete: at least two marking techniques, for example signed metadata together with an imperceptible watermark, and one technique for free-form text^[2].

For generative systems that were on the market before 2 August 2026, the deadline is 2 December 2026^[3]. In practice most teams will combine the same two layers: C2PA Content Credentials for metadata and an AI watermark in the content itself. This guide explains why both are needed and how to build them in.

C2PA is an open technical standard for content provenance. A C2PA manifest holds assertions about an asset, a claim that references them, and a claim signature; a hard binding ties the manifest to the exact bytes with a hash, and a soft binding, a fingerprint or an invisible watermark, lets an asset be matched to its manifest in a provenance store when the manifest itself has been removed^[4].

Watermarking research gives the second layer. For text, a watermark can be embedded during sampling with negligible effect on quality and detected from a short span of tokens without access to the model^[5]; SynthID-Text runs such a scheme in production with minimal latency overhead, changing only the sampling procedure^[6]. For images, a watermark can be rooted in the decoder of a latent diffusion model so that every output carries it, and it still works after the image is modified^[7].

The attacks are just as well documented. Recursive paraphrasing significantly reduces detection rates for a range of text detectors, including watermark-based ones^[8]. Pixel-level invisible image watermarks are provably removable by regenerating the image with a generative model^[9]. No single layer is robust on its own, which is the reasoning behind the Code's two-layer requirement.

The layers fail in different ways, so together they cover more of the real paths content takes. The manifest gives a verifier the full story when it survives; the watermark still says "AI-generated" when it does not.

Three parts matter for Article 50^[4]:

• Assertions and a signed claim. The generator records that the asset was created or edited by an AI system, and signs the claim with your organisation's certificate. Use your own signing identity: the provider in Article 50(2) is the company that puts the system on the market, not necessarily the model vendor.
• Hard binding. A hash over the asset makes any later change detectable.
• Soft binding. A fingerprint or watermark identifier lets a stripped asset be matched back to its manifest in a provenance store. This is how the two layers connect.

C2PA is designed for images, video, audio and documents. It does not help free-form text that is copied and pasted, which is why the Code allows a single technique there^[2].

• Images. Watermark at generation time, in the model or its decoder, rather than stamping pixels afterwards^[7]. Test against regeneration, crops, compression and screenshots, because pixel-level marks can be removed by regenerating the image^[9].
• Audio and video. Use a watermark designed to survive compression and resampling, and keep the C2PA manifest on the file. For audio-only content, the deployer's label has to be audible.
• Text. Watermark in the sampling step^{[5, 6]}. Expect detection to be unreliable on short or heavily edited text: the Code exempts text under about 200 tokens from watermarking, and paraphrasing remains the main weakness^{[8, 2]}.

If you call a hosted model, check what the vendor already marks. You may still need your own manifest, and your own detector access, for what your product publishes.

1. Generate. The model produces output with the watermark applied in the sampling or decoding step.
2. Sign. The service attaches a C2PA manifest: AI-generated, system name and version, time, signed with your organisation's key.
3. Record. Store the manifest, the content hash and the watermark or fingerprint identifier in a provenance log you control.
4. Deliver. Every export path keeps the manifest, or re-attaches it: downloads, APIs, CMS publishing, e-mail, social uploads.
5. Detect. Offer a detection endpoint that checks the watermark and looks up the provenance log. The Code expects detection free of charge in principle, and interoperable across providers by 2 February 2027^[2].
6. Log. Record which marking version ran for which output, so you can show it in an audit.

This is ordinary pipeline engineering: a signing service, a store and an API. The hard part is covering every export path, not the cryptography.

Before 2 December, run the paths your content actually takes and measure what survives:

• upload to the platforms your users post to, then download again;
• re-encode, resize, crop and screenshot images and video;
• paraphrase and lightly edit text, at the lengths your product produces;
• strip metadata with common tools and check the soft-binding lookup still works.

Record detection rates per path and per marking version. That table is your evidence that the marking is "effective, interoperable, robust and reliable as far as technically feasible", the standard Article 50(2) sets.

Marking under Article 50(2) is the provider's job and is machine-readable. Labelling under Article 50(4) is the deployer's job and is for people: a visible label on deepfakes, recognisable at first exposure, with the EU icons from the Code where there is a visual channel and an audible disclaimer where there is not^[2]. A C2PA manifest alone does not meet the labelling duty. If you both generate and publish, you do both.

1. Two marking layers per media type, one for free-form text.
2. Manifests signed with your own organisation's credentials.
3. A provenance log with content hash, manifest and watermark identifier.
4. Every export path keeps or re-attaches the manifest.
5. A detection endpoint, free in principle, planned for interoperability by February 2027.
6. Measured survival rates per export path, kept with the system version.
7. Visible labels for deepfakes where you are also the deployer.

Is C2PA enough on its own for Article 50?

Not under the Code of Practice for images, audio and video, which asks for at least two techniques. C2PA metadata is easy to strip, so it is paired with a watermark that stays in the content.

Is a watermark enough on its own?

Only for free-form text, where the Code accepts a single technique. Elsewhere a watermark alone carries too little information and can be removed by regeneration attacks, so it is paired with signed metadata.

Do we need to watermark short chatbot answers?

The Code exempts text under about 200 tokens from watermarking, because detection on short text is unreliable. Interaction disclosure under Article 50(1) still applies to the chatbot itself.

Can we use the model vendor's watermark?

Yes, if it covers your outputs and you can detect it or point users to a detector. You will usually still sign your own C2PA manifest, because your company is the provider of the system your users see.

• C2PA Technical Specification 2.2
• European Commission — Code of Practice on Transparency of AI-generated Content
• Regulation (EU) 2024/1689 — the AI Act
• Regulation (EU) 2026/1744 — the AI Omnibus

• EU AI Act Article 50: transparency rules and the 2 December deadline
• Practical EU AI Act guide
• GPAI provider vs downstream integrator
• EU AI Act FAQ for enterprise teams