AI Content Marking Is a Provenance Problem, Not a Labeling Task

A lot of European AI roadmaps were rewritten this summer. It is worth checking that yours relaxed the right deadline.

On 8 July 2026 the Parliament and Council adopted Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July and in force since 27 July. It postponed the high-risk obligations due on 2 August 2026: stand-alone Annex III systems now apply from 2 December 2027, and AI embedded in regulated products under Annex I from 2 August 2028. The stated reason was that harmonized standards and national governance were not ready.

That is the part everyone read. What matters to anyone shipping is what the Omnibus left alone. Article 50, the transparency chapter, applied on 2 August 2026 as scheduled. Its only concession was a four-month transitional period for the machine-readable marking duty in 50(2), and only for systems already on the market before that date. Those have until 2 December 2026, under twelve weeks away. Anything shipped since 2 August owed marking on day one.

The duty is probably yours, not your model vendor’s

Article 50(2) binds providers of AI systems, including general-purpose ones, that generate synthetic audio, image, video or text. The instinct in most engineering organizations is that this lands on whoever trained the model.

It usually does not. If you build a customer-facing assistant, a document drafting tool or a marketing generator on a third-party model and ship it under your own name, the common reading is that you are the provider of that AI system, and the marking duty attaches to its outputs. Your model vendor’s obligations cover the model and the systems it offers directly, not yours. Put the question to counsel with your real architecture in front of them, and do not assume the answer is no.

The part that catches teams by surprise is text. Article 50(2) is not limited to images and video: a system generating text falls inside it, with a carve-out for standard editing functions that do not substantially alter the input data or its semantics. Spellcheck is out. A support assistant that composes replies is not.

Article 50(4) is a different duty and lands on deployers. Deepfake image, audio or video must be disclosed; inside an evidently artistic, creative, satirical or fictional work the obligation narrows to disclosing the existence of the generated content in a manner that does not hamper enjoyment of the work, which changes how you disclose rather than whether you do. AI-generated text published to inform the public on matters of public interest must also be disclosed, unless it had human review and a named person or organization holds editorial responsibility. That exemption releases the text limb only. Assess the roles per system, not per company, and do not treat them as alternatives: you can be the provider of a system and also its deployer when you use your own product, in which case both duty paths apply. Note too that 50(1) does not bite where the AI is obvious to a reasonably well-informed person in context.

The regulator has already conceded that one technique is not enough

The Commission published its Code of Practice on Transparency of AI-Generated Content on 10 June 2026, and the Commission and the AI Board confirmed in July that adhering to it is an adequate way to demonstrate compliance with Article 50(2), (4) and (5). The final Guidelines followed on 20 July.

Article 50(2) sets the bar: marking must be effective, interoperable, robust and reliable, “as far as this is technically feasible”. The Code’s answer is the interesting part. As Jones Day’s reading of the final text puts it, the Code accepts that no single marking technique meets all four criteria today, and expects providers to use at least two layers where needed. Tech Policy Press’s explainer adds the state of the art: forensic detection is not yet reliable enough and common benchmarks have not emerged, leaving providers with internal testing and evolving practice.

Read that as an engineer rather than a lawyer. A regulator looked at the available technology, concluded any single mechanism will fail under normal conditions, and wrote the redundancy into the compliance path. That is a system design statement, and the shape it describes is not a label.

Layer one: signed metadata, and the way it dies

The Code points at C2PA for the metadata layer, with CAWG assertions inside the manifest for richer provenance. A C2PA manifest holds assertions, a claim and a claim signature. Its integrity comes from a hard binding: a cryptographic hash over the asset bytes letting a validator confirm the manifest belongs to this asset and the asset is unmodified. One per manifest, and it is strong because it is brittle. Change a byte the binding covers and validation fails.

That brittleness is not the problem in practice. The manifest travels alongside the bytes as a separate structure, and ordinary infrastructure throws it away. The specification says so plainly: an asset can become separated from its manifest through removal or corruption. An image pipeline re-encoding to WebP, a CDN transform, a chat client stripping EXIF, a screenshot, a copy and paste into a ticket. None of these are attacks. They are Tuesday.

Here I would push back on how most teams scope the work. The threat model discussed is an adversary removing the mark. The failure that will generate your incidents is your own delivery path dropping it. The Code addresses the first case with commitments to retain existing metadata and forbid users from stripping it. Terms of service do not survive a thumbnail generator. Audit your own pipeline first.

Layer two: a signal that outlives the container

The Code’s second layer is an imperceptible watermark carried in the content itself. C2PA files that under soft bindings, alongside the perceptual fingerprint: identifiers that are not statistically unique and are designed to work across derived assets and renditions, because they identify the content rather than the bytes. How much transformation a given scheme tolerates is a property of that scheme, not of the idea, so test the one you pick. The Code treats fingerprinting or logging against a registry as an optional third mechanism, so a fingerprint is not a substitute for the watermark on a media pipeline.

Pair a soft binding with a manifest repository and you get what C2PA calls durable Content Credentials. A stripped asset can be fingerprinted, matched against the repository, and its provenance recovered. That optional third layer is the one I would fund first after the two the Code names, because recovery beats watermark strength as an objective.

Be honest about its limits. The NeurIPS 2024 paper Invisible Image Watermarks Are Provably Removable Using Generative AI shows regeneration attacks that strip pixel-level invisible watermarks while preserving image quality, with a provable removal result for a class of schemes. Later work on transfer attacks and diffusion-based editing points the same way. Treat an invisible watermark as a durability aid against benign transformation rather than a control against a motivated adversary.

For text the honest position is starker. Copying plain text out of your interface drops any metadata you attached, and paraphrase defeats schemes that depend on the exact token sequence, so short text is the weakest case for both layers. Our judgement, not a route the Code sets out: sign the artifacts you emit and keep a server-side log of what your system generated, keyed so you can answer the question later. That log is the registry in another shape. Whether a regulator would accept it as an equivalently adequate means is untested.

flowchart TD
  A[Take one system and run both paths.<br/>The roles are not alternatives] --> B{Do you place it on the market or into<br/>service under your own name?}
  B -->|Yes: you are its provider| C{Interacts directly<br/>with people?}
  C -->|Yes, and the AI is<br/>not obvious in context| D["Art 50 para 1:<br/>tell them at first interaction"]
  B -->|Yes: you are its provider| E{Generates audio, image,<br/>video or text?}
  E -->|Yes| F["Art 50 para 2:<br/>machine-readable marking"]
  F --> G[Code layer 1: signed,<br/>time-stamped metadata]
  F --> H[Code layer 2:<br/>imperceptible watermark]
  F --> I[Optional third: fingerprint or log<br/>against a repository]
  F --> J[Plus a detection lookup<br/>third parties can call]
  A --> R{Do you use it, whoever<br/>placed it on the market?}
  R -->|Yes: you are its deployer| K{Deepfake image,<br/>audio or video?}
  K -->|Yes| L["Art 50 para 4:<br/>deployer discloses"]
  L --> M[Artistic or satirical work:<br/>manner is limited, duty remains]
  R -->|Yes: you are its deployer| N{Published text on matters<br/>of public interest?}
  N -->|Yes| O["Art 50 para 4:<br/>deployer discloses"]
  O --> P{Human review with named<br/>editorial responsibility?}
  P -->|Yes| Q[Text limb exempt.<br/>Never releases a deepfake]

The part everyone forgets is a product surface

The Code does not stop at emitting marks. Providers are expected to make detection available so deployers, users, authorities, researchers, civil society and media can check whether a piece of content came from your system. That is an externally reachable service with an availability expectation, an abuse surface, a privacy question about what a lookup reveals, and a retention policy that outlives the content. It is the most underestimated item in the obligation, because it does not look like compliance work and never appears on the ticket that says “add watermarking”. Budget for a small public API with an owner.

Three failure modes worth naming

Assuming the model vendor’s marking covers you. Their marking applies to their surface. If you re-render, re-encode, template around it or emit text through your own service, you are the one putting that output in front of a user.

Marking the media and forgetting the text. Image pipelines get the attention because C2PA tooling exists for them. The support assistant generating thousands of messages a day is the larger exposure and the harder case.

Putting the disclosure in the terms of service. Article 50(5) requires the information in a clear and distinguishable manner at the latest at first interaction or exposure, in an accessible form. A clause nobody opens is not first-interaction notice.

A twelve-week sequence that fits

Start with an inventory. List every surface where your systems emit generated audio, image, video or text to someone outside the team, and record whether you are its provider, what the output format is, and which delivery paths it traverses. Expect to find surfaces nobody was tracking.

Then instrument the generation boundary rather than the model call. At the point where the artifact leaves your system, apply the watermark your media pipeline supports, sign the manifest over the finished asset, and write the same provenance record into a registry keyed by a content fingerprint. Order matters: watermarking after signing changes bytes the hard binding covers and invalidates it. The first two steps are the Code’s layers; the third is the recovery path, and doing all three in one place is what makes them cheap. Walk each delivery path afterwards and see whether the mark survives your transforms, your CDN, your email templates and your mobile clients. Then add the detection lookup, add the first-interaction notice, and give the whole thing an engineering owner who is accountable when a release removes the mark, as someone is when a release removes a security header.

Where the constraints are real

The absence of common benchmarks is a validation problem, not a licence. You cannot demonstrate adequacy against an external yardstick, and you cannot buy certainty from a vendor claiming one. The Code of Practice is voluntary. Adhering to it is a recognized route to demonstrating compliance; declining it means proving compliance by alternative equivalently adequate means, which in practice means documenting your reasoning to a standard a market surveillance authority will accept. For a small team the Code is usually the cheaper path, because the reasoning is already written down.

The scope boundaries are also unsettled. Where ordinary editing ends and manipulation begins, and how far the artistic and satirical limitation reaches, are being resolved case by case. If your product sits near an edge, build the pipeline anyway and keep the decision about which outputs flow through it in configuration.

The rule worth keeping

Strip out the regulation and the dates and a design statement remains: if you generate content, the origin of that content is a property of your system that has to survive leaving it, and no single mechanism carries it reliably. Signed metadata is precise and fragile. Content-derived signals are approximate and more durable. A registry turns the second into an answer. The deadline is the reason to start now; the design is worth having wherever you operate.

Further reading: the Commission’s Guidelines on transparency obligations for providers and deployers of certain AI systems, which set out the interpretation that national market surveillance authorities will work from.

If your product generates content for people outside your team and nobody yet owns how that origin is recorded, we can help. We work with engineering teams to inventory generative surfaces, design the provenance path from the generation boundary through delivery, and build the detection and registry services that make it verifiable later. Talk with us about your AI provenance work.