C2PA for generative AI providers

Machine-readable marking — Article 50(2)

Providers of generative AI systems must mark output as artificially generated in a machine-readable format. A C2PA manifest is the standard answer: it carries a digital source type assertion declaring AI origin, and any validator can read it.

The practical obstacle is not the format, it is the certificate. Producing manifests means sourcing an X.509 certificate validators trust and running the signing lifecycle around it. Managed signing removes that step: one call, your brand named as the claim generator.

Detectability — the half that usually fails

Article 50 asks that markings be effective and reliable as far as technically feasible. Metadata is not reliable on its own, because most platforms re-encode on upload and drop it. A provider can be diligently signing every generation and still have nothing detectable by the time content reaches an audience.

The C2PA specification’s own answer is a soft binding — a fingerprint derived from what the content looks like, stored outside the file. Every 0byte stamp writes one into a public transparency log, so a screenshot of a re-uploaded copy still resolves to the original record, and anyone can check it free, with no account. That free public verifier is the detection side of the same obligation.

Open-weights models, which no watermark covers

Invisible watermarks cover one vendor’s own models. If you serve open-weights models, no provider watermark applies to what you ship, and a 2025 survey found only 38% of popular AI image generators ship machine-readable watermarks at all.

Stamping sits at your serving layer instead of inside the model, so it covers everything you serve regardless of which model produced it — one import change, whatever is behind the endpoint.

The audit trail you can hand a regulator

Marking and detection are the visible obligations; being able to evidence them afterwards is the one that bites during an audit. Each stamp produces a proof — fingerprint, provider, model, timestamp, signature, key ID — appended to a Merkle transparency log built on the RFC 6962 pattern, the same structure behind Certificate Transparency.

• Append-only. Records are added, never edited or deleted — not even by us. Rewriting history would break the published roots.
• Independently verifiable. An auditor checks any historical inclusion proof against an Ed25519-signed tree head using public endpoints only.
• Every key published. Historical signing keys stay served by key ID, so old proofs remain checkable after a rotation.

The compliance mapping in the docs ties each requirement to the specific feature that addresses it.

The date on the calendar

Under Regulation (EU) 2024/1689, generative AI systems already on the market before August 2026 have until 2 December 2026 to comply. That is the practical planning constraint for anything already in production.

Common questions

01

Does C2PA on its own satisfy Article 50?

It supplies the machine-readable marking, but Article 50 also asks that marking be effective and reliable as far as technically feasible. Since most platforms strip metadata on upload, a manifest alone can fail the detectability half of that. Pairing the manifest with a soft binding in a public registry is what keeps it detectable. Whether a specific deployment satisfies a given obligation depends on that system — none of this is legal advice.

02

We serve open-weights models. Can we still mark output?

Yes, and registry stamping is the practical route. Provider watermarks only cover that vendor’s own models, so nothing covers an open-weights model you host. Stamping happens at your serving layer and works regardless of which model produced the content.

03

What do we actually hand an auditor?

A proof per generation: the fingerprint, the provider, the model name, a timestamp, a signature and a key ID, anchored in an append-only Merkle log with a published, signed tree head. An auditor can verify any historical inclusion proof using only public endpoints and published keys, without trusting 0byte.

04

Do you store our prompts or our content?

Neither. The record holds the fingerprint, who stamped it, the model name, a timestamp and the signature. Never the content, never the prompt. The fingerprint is a compact perceptual hash and mathematically cannot be reversed into an image. Content sent to verification is checked in memory and never stored.

05

What happens at generation-time scale?

Stamping is a synchronous call with a measured median of 41 ms and 53 ms at p99, over loopback and excluding network. Rate tiers run 60, 300 and 1,000 requests per minute, and an Idempotency-Key header makes retries safe against an append-only log.