Article 50 is live. Marking was the easy half.

On 2 August 2026, Article 50 of the EU AI Act stopped being a thing to plan for. Providers of AI systems that generate synthetic audio, images, video, or text now have to ensure those outputs are marked in a machine-readable format and detectable as artificially generated.

If your system was already on the EEA market before that date, you have until 2 December 2026. That is the whole runway.

Most teams read the requirement, reached for C2PA or a watermark, shipped it, and closed the ticket. That covers the first verb. The second one — detectable — is where compliance programmes are going to come apart, and it is not a paperwork problem. It is a physics problem.

Two verbs, two different tests

The obligation is not "mark your output." It is that outputs be marked in a machine-readable format and detectable as artificially generated or manipulated. Those are separate properties, tested at different moments.

Marked is a property of the file at the point you produce it. You can verify it on your own infrastructure, in CI, before anything leaves your servers. Embed a C2PA manifest with a digital source type assertion declaring AI generation, run a validator, see it come back. Done, and auditable.

Detectable is a property of the content at the point somebody looks at it. Not on your servers — in a newsroom, in a court, in a moderation queue, three re-uploads later. You do not control any of that environment, and nothing you did at generation time is guaranteed to still be present when the question gets asked.

The Code of Practice language sharpens this. Technical solutions must be effective, interoperable, robust, and reliable as far as technically feasible, accounting for the generally acknowledged state of the art. "Robust" and "reliable" are not adjectives you can satisfy at the point of generation. They are claims about what happens afterwards.

The Code of Practice names no technology, and that is the point

The Code of Practice on Transparency of AI-generated Content was finalised on 10 June 2026. By the end of July roughly 190 companies and organisations had signed it, and the European Commission and the AI Board confirmed it as adequate for demonstrating compliance with Article 50.

Here is what it does not do: it does not name C2PA. It does not name watermarking, or metadata, or cryptographic provenance. It specifies the outcome — machine-readable marking, detectable as artificially generated — and leaves the mechanism to the state of the art and to standardisation work still in progress.

Plenty of people read that as a gift. It is closer to the opposite.

A named technology would be a safe harbour: implement X, point at the clause, move on. An outcome-based rule means the burden of demonstrating that your chosen approach is actually effective and robust sits with you. If a regulator asks why your marking scheme counts as reliable, "we implemented the standard everyone uses" is not an answer to the question that was asked. The question was whether it works.

And a signatory list of roughly 190 organisations sets a reference point. "As far as technically feasible" is measured against what the field demonstrably manages, not against what you found convenient — and that bar moves as the state of the art moves.

Where the marking goes to die

C2PA is the right standard for the marking half. It is open, it is signed, it carries a purpose-built assertion for declaring AI origin, and any validator can read it. We build on it and we recommend it.

It has one well-documented failure mode: the manifest lives inside the file, so it shares the file's fate.

Upload an image to most platforms and it is re-encoded for delivery — resized, recompressed, stripped of metadata that does not serve the product. A Content Credential is metadata that does not serve the product. This is not a bug anybody is racing to fix; it is a delivery pipeline doing its job.

Screenshots are worse, and they are how a great deal of content actually travels. A screenshot is a new file. It has no byte-level relationship to the original at all. Nothing embedded survives it, no matter how well signed — not because the signature failed, but because there is no longer a file for the signature to be attached to.

So run the compliance argument end to end. You marked the output: verifiable. Someone posted it, a platform re-encoded it, someone screenshotted that, and the screenshot is what fifty thousand people saw. At the moment the content mattered most, was it detectable as AI-generated?

No. And you can prove you did the marking, which is a strange position to be in when the obligation has two verbs.

Watermarking is the usual proposed fix, and it does survive re-encoding better than metadata. But it only marks the models of the vendor who implemented it — a 2025 survey found that only 38% of popular AI image generators ship machine-readable watermarks at all — and if you serve open-weights models, no provider watermark covers what you ship.

The mechanism the spec already describes

The C2PA specification anticipates exactly this. Alongside the hard binding — the cryptographic hash tying a manifest to exact bytes — it describes a soft binding: an identifier derived from what the content looks like, stored outside the file, so a stripped manifest can be recovered by lookup.

The mechanics are unglamorous and that is the appeal. A perceptual fingerprint is computed from the broad light-and-dark structure of the image rather than its bytes. Recompression, resizing, and screenshotting mostly perturb fine detail; the structure that makes the picture recognisable survives. So a re-encoded copy produces a near-identical fingerprint, you look it up in a registry, and the original record comes back — provider, model, timestamp, signature. We took that mechanism apart in detail in how a fingerprint survives what the file cannot.

Marking is now something you did at generation. Detectability becomes something anyone can exercise at any point afterwards, on the copy in front of them, with no cooperation from the platform that stripped the file. That is what "robust" and "reliable" have to mean if they mean anything.

We operate such a registry openly: an append-only Merkle transparency log on the RFC 6962 pattern — the same structure that keeps the web's certificate system honest — with Ed25519-signed tree heads and inclusion proofs anyone can recompute. Verification is free, keyless, and needs no account, because a detection mechanism that costs money to consult is not a detection mechanism.

The parts that got no grace period

The 2 December date is easy to fixate on, and it only covers one slice of Article 50. The obligations around deepfakes, emotion recognition, biometric categorisation, and certain public-interest text have applied since 2 August 2026 with no transition window at all.

That distinction catches people out because it splits by obligation, not by product. The same company can be inside the grace period for marking the outputs of a generator it shipped in 2025 while already being on the hook, today, for disclosing that a published image is a deepfake. One is a provider obligation about machine-readable marking. The other is closer to a labelling duty owed to the person looking at the content, and it landed first.

There is also a quieter problem sitting in the scope: Article 50 covers synthetic text, and text is genuinely harder. You cannot embed a manifest in a paragraph that survives being copied into a different document, and perceptual fingerprinting has far less to work with than it does on an image — there is no low-frequency structure in a sentence that survives a rewrite the way an image's broad light-and-dark structure survives recompression. Anyone claiming a robust, general solution for marking synthetic text should be asked to demonstrate it on a paraphrase.

We do not serve text, and we say so rather than gesturing at a roadmap. It matters here because it is a case where "as far as technically feasible" is doing real work: the standard is calibrated to the state of the art, and for text the state of the art is weak. A compliance file that acknowledges that, and documents what you do instead, is more defensible than one that claims a capability a regulator can disprove with a thesaurus.

What auditability actually requires

There is a third thing the transparency rules imply that almost nobody has built, and it only bites during an audit.

Marking and detection are things you do to content. Evidencing them eighteen months later is a different capability. If your answer to "show me that this specific output was marked at generation" is a log line in your own observability stack, you are asking an auditor to trust your infrastructure — including on the days it was misconfigured.

An append-only log with public inclusion proofs removes that ask. Records are added, never edited or reordered, and an auditor can verify any historical proof against a published, signed tree head using nothing but public endpoints. You are not asking to be believed. You are handing over something checkable.

What to have in place before 2 December

Concretely, if you generate images and you serve the EEA:

Embed a C2PA manifest at generation with the digital source type assertion set. That is the marking half, and it is the easy half. If certificate procurement is the blocker, that problem is solved — the signer and the claim generator were never required to be the same party.

Register a soft binding for every output, so origin stays recoverable after the manifest is gone. This is the half that answers "detectable."

Make the check free and public. Detectability that requires an API key is detectability that will not be exercised by the newsroom that needs it.

Keep an audit trail somebody else can verify without trusting you.

And write down what your system cannot do. Heavy regeneration of content through another AI model defeats any scheme that works from appearance — soft bindings, watermarks, and classifiers alike. Stating that plainly is not a weakness in a compliance file; it is the difference between a robustness claim a regulator can evaluate and a marketing claim they cannot.

None of this is legal advice, and whether a specific deployment satisfies a specific obligation turns on your system and your documentation, not on ours.

The deadline is not asking whether you marked your output. It is asking whether anyone can still tell. Those questions have the same answer for about as long as it takes a file to reach a platform.

Further reading: EU AI Act, Article 50 · Code of Practice on Transparency of AI-generated Content (European Commission) · Guidelines on transparency obligations (European Commission) · Transparency obligations under Article 50 — FAQ · Watermarking in AI image generators (arXiv 2503.18156)