When the EU AI Act's transparency obligations take effect on August 2, 2026, every system that generates synthetic content for EU users will have to attach machine-readable provenance information to that content. Most engineering teams building AI products have only a vague awareness of this requirement, and few have actually built the infrastructure to comply — and among those who have, many have done only half of what regulators are asking for.
What C2PA can actually do (and what it can't)
C2PA is a cryptographic signing standard for digital assets. When an AI system generates an image, a video, or a document, C2PA lets it attach a manifest — a JUMBF-formatted metadata block embedded in the file — that records the tool that created the content, the organization operating that tool, and the time of creation. Manifests are signed with X.509 certificates, and anyone holding the public key can verify the signature and confirm the manifest hasn't been altered.
Manifests contain assertions: typed, CBOR-encoded statements about an asset. The assertion types relevant to AI generation include AI-generation disclosure (introduced in C2PA v2.1), operation records (which edits were performed), material references (which source assets were used), and content binding — a cryptographic hash of the file's bytes used to detect tampering.
When a C2PA-signed asset becomes the source material for another asset — say, an editor drops an AI-generated image into a design — the original manifest lives on as a "material" referenced by the new manifest. That forms a provenance chain: an encrypted graph linking every generation and modification event back to the original source.
Three points are worth being precise about.
C2PA certifies the signature, not the truth. The standard confirms that a signer holding a valid certificate signed the manifest at a particular time. It does not verify that the content is untampered, that the recorded metadata is accurate, or that the signer was honest. Field investigations have documented C2PA cryptographically authenticating fabricated files and misleading clips. The trust model is built on identity, not veracity.
C2PA does not survive metadata stripping. The JUMBF block carrying the manifest is routinely removed — by social platforms (Instagram, X and WhatsApp remove metadata on upload), by CDNs doing adaptive transcoding, and by format-conversion pipelines. Once content passes through any system that doesn't explicitly preserve metadata, the cryptographic proof is gone.
C2PA alone does not satisfy the EU AI Act. The regulation calls for a layered approach: a visible label, machine-readable manifest metadata (which C2PA provides), and an imperceptible watermark (which C2PA does not). Implementing only C2PA leaves a gap on the watermarking requirement.
The metadata-stripping problem
This is the failure mode that catches teams most off guard. A well-built C2PA signing pipeline produces cryptographically valid manifests, cleanly embedded in the source files. Then the content enters production — through a video transcoder, an image optimizer, an S3-to-CloudFront delivery path, or a third-party platform — and the manifest simply disappears.
As of 2025, the major platforms handle this very differently:
- Instagram, X and WhatsApp remove all metadata on upload.
- TikTok preserves and displays C2PA credentials (an early adopter).
- LinkedIn displays credentials in a limited form.
- Google Images reads C2PA, when present, in its "About this image" feature.
- Most CDNs with transcoding pipelines silently delete JUMBF containers.
Video pipelines are especially vulnerable. Adaptive bitrate streaming (HLS, DASH) re-encodes content into multiple resolutions and bitrates, producing new files with no link to the original JUMBF metadata. Every re-encode breaks the hard binding — the cryptographic hash that ties the manifest to a specific set of file bytes.
C2PA v2.1 partly addresses this with soft binding: instead of relying solely on a hash-based hard binding, it uses fingerprints or embedded watermarks as identifiers. Watermarks survive re-encoding and format conversion. When a verifier meets a file that's had its metadata removed, it can extract the watermark, query a soft-binding resolution API (a standardized HTTPS endpoint), and retrieve the manifest from an external repository to verify it.
That's the right architecture: watermarks as durable pointers, external manifest repositories as the source of truth. But it requires building both C2PA and watermarking — which brings us to the compliance requirements.
Why the EU AI Act asks for more than C2PA
Article 50 of the EU AI Act — the transparency obligations for AI-generated content — takes effect on August 2, 2026, and its reach is global: if your system serves EU users, it falls within scope regardless of where your company is registered.
The EU's Code of Practice on AI-generated content spells out what compliance requires:
- Visible disclosure — a human-readable label indicating the content is AI-generated.
- Machine-readable metadata manifest — C2PA satisfies this layer.
- Imperceptible watermark — C2PA alone does not satisfy this; you need an independent signal embedded in the content itself.
- Content fingerprinting — for detection and deduplication.
- Logging — optional, but recommended.
The Code explicitly forbids relying on a single marking technique, and forbids removing watermarks. Violations of Article 50 carry penalties of up to 7.5 million euros or 1.5% of global revenue.
California's AI Transparency Act (SB 942, effective January 1, 2026) imposes similar requirements on systems serving California residents: visible labels, an imperceptible machine-detectable watermark, and publicly available detection tools. California's AB 853 explicitly accepts C2PA as a compliance mechanism for the manifest requirement — but the watermarking obligation stands on its own.
The practical takeaway: if you implemented C2PA but not watermarking, you finished half the job. You need both.
C2PA and watermarking solve different problems
C2PA and watermarking are complementary, not interchangeable.
C2PA gives you a rich, auditable provenance chain. It records who signed the content, which tools were used, when, and which materials were referenced, and it links one generation to the next. It hands investigators and compliance auditors a structurally rich record whose integrity can be cryptographically verified. What it can't do is survive removal at every major distribution node.
Watermarking has the opposite profile. Google's SynthID (used in Gemini and Imagen) embeds imperceptible changes into pixel values, audio frequencies, or text-token distributions during generation. Meta's Video Seal embeds signals in the frequency domain. These survive JPEG recompression, cropping, resolution changes, and social-media processing. SynthID stays detectable at video bitrates as low as 200 kbps, whereas C2PA reliably preserves manifests only above roughly 500 kbps. But a watermark carries no identity — it confirms that AI was involved without saying which organization, model version, or moment in time was responsible.
Cryptographic watermarks — an emerging research direction, not yet production-ready — try to bridge that gap by embedding pseudorandom codes during inference that only the model operator can verify. Today's implementations run into a fundamental tension between cryptographic strength and signal robustness at acceptable error rates; achieving both at once is still an open research problem.
The architecture that satisfies the regulation and survives real-world distribution is this: C2PA manifests for the provenance chain, watermarks for resilience against removal, and watermarks registered as soft bindings that point to externally hosted manifest repositories. It's what Google (C2PA + SynthID) and Adobe (C2PA + soft-binding watermarks) have already built.
Building a production-grade provenance system
If you're building AI content-generation systems that need to comply, the infrastructure breaks down into five components.
Signing service
A dedicated microservice with HSM-backed private-key storage handles manifest signing. It has to be separate from the inference pipeline — signing at generation scale calls for a queue-based, asynchronous design. Certificate lifecycle management (rotation, revocation, OCSP availability) needs an explicit operational owner. For multi-tenant platforms, routing tenant certificates takes special care, because C2PA trust lists grant trust by signer, not by platform.
Manifest repository
C2PA manifests should live in immutable external storage, independent of the media files themselves, and be indexed by hash so any verifier can look one up using a file hash or watermark ID. This is the source of truth after files lose their manifests in transit. Design for write-once storage, read-time CDN distribution, and tenant isolation at the storage layer.
Watermarking service
Watermark embedding happens during inference — the signal is introduced as the content is generated, not bolted on afterward. Watermark IDs are registered in the manifest repository alongside the manifest URLs, and a soft-binding resolution API maps watermarks back to manifests so verifiers can recover provenance for files that have been stripped.
Provenance audit database
Separate from the C2PA manifest store, this holds operational records: content IDs, model versions, timestamps, prompt hashes (hashes, not the prompt text — for privacy), signer certificate fingerprints, tenant IDs, parent material references, and distribution events. Use append-only event logs; Kafka into ClickHouse or BigQuery is a common pattern. When an auditor asks for evidence that your system labeled content correctly, this is what you hand over.
Verification API
An HTTPS endpoint that accepts a file hash or watermark ID and returns a verification status (unknown / valid / trusted / compromised), supporting transparency UIs, downstream partner integrations, and internal compliance monitoring.
The data flow looks like this: inference generates the content; the watermarking service embeds the signal; the signing service creates a C2PA manifest containing the AI-generation assertion, model version, timestamp, and soft-binding reference; the manifest is written to the repository; the media is delivered with both the embedded JUMBF and the watermark; and an audit log is written asynchronously. When the content later passes through a CDN that removes metadata, the watermark persists — verifiers extract it, query the resolution API, retrieve the manifest, and verify the content hash.
The material-chain problem
AI content rarely exists in isolation. AI-generated images get composited into marketing videos. AI-written paragraphs are edited into longer documents. Translated articles reuse AI-generated sections. Each of these derivative relationships creates a material reference that C2PA's nested manifests are meant to track.
In practice, material chains produce graph-structured data that relational databases handle poorly. When an auditor asks, "Show me the complete provenance for this published article," the answer may require walking a material-reference graph across dozens of intermediate assets. Graph databases with SPARQL-style queries fit this far better than SQL joins.
The critical invariant: every reprocessing step must re-sign the manifest and reference the previous one as material. That means signing infrastructure has to exist at every stage of every pipeline, not just at initial generation. Any gap in the chain produces an incomplete provenance record — and that's a compliance and audit risk.
What C2PA can't protect against
Even with all the infrastructure in place, it's worth being clear about the limits.
It can't detect tampering that happened before signing. If content is altered before the manifest is signed, the resulting manifest faithfully records the signing of already-tampered content. The cryptographic proof is valid; the content is still false.
It has no retroactive coverage. Anything your system generated before you deployed provenance infrastructure carries no provenance at all. AI detectors — which have documented false-positive rates above 20% — are the only retroactive option, and they don't hold up at scale.
It can't cover open-source inference. Stable Diffusion running locally, fine-tuned models on consumer hardware, and API-accessible models without provenance support all generate content with no manifest. These are the path of least resistance and the highest volume for bad actors, and the whole C2PA-and-watermarking ecosystem depends on producers choosing to participate — which can't be enforced against open model weights.
And the identity layer creates a surveillance risk. C2PA allows — and in some applications requires — attaching the signer's identity to content. For journalists, whistleblowers, and human-rights workers, the same infrastructure built to fight misinformation could be turned into a tool for state-backed identification. The World Privacy Forum has documented how automatically embedded GPS coordinates and timestamps in manifests expose location data, and how uneditable operation assertions create a permanent edit history for signed content.
The timeline you're actually on
The August 2, 2026 deadline for Article 50 is not theoretical. GPAI (general-purpose AI) transparency obligations for model providers already took effect on August 2, 2025. Organizations that offer AI capabilities through third-party APIs often misclassify themselves as "deployers" (lighter requirements) when they're really "GPAI system providers" (heavier ones). Work out the correct classification first; every technical decision flows from there.
Standing up full provenance infrastructure — regulatory classification, C2PA signing pipelines, watermark integration, external manifest repositories, soft-binding registration, and C2PA trust-list certification — realistically takes a minimum of three to six months for a team that isn't starting from scratch. Teams starting now are already racing the clock.
The reference implementations are in good shape. The Rust SDK (c2pa-rs, maintained under the contentauth GitHub organization) is the reference implementation and works well for in-browser verification via WebAssembly. OpenAI, Adobe Firefly, and Google Imagen all have production-grade C2PA implementations you can study. Midjourney had not implemented C2PA as of early 2026 — a notable gap at its scale, and a sign that adoption across the industry is still largely voluntary.
Content provenance is a real problem, and the tools to solve it are mature enough. The lag comes from engineering teams treating it as a compliance checkbox rather than what it is: a core system-design requirement, with failure modes, operational overhead, and architectural consequences that need to be designed in from the start — not grafted on a month before the deadline.
Where this leaves you
Most of this is the producer's side of the problem — the companies generating content and the infrastructure they have to build. The reader's side is simpler. If someone sends you a file, or you download one, and you want to see what's embedded in it or take it out before you reshare, you can do that locally: Apkimi's photo metadata remover detects and removes the C2PA manifest along with EXIF and GPS data, entirely in your browser, with nothing uploaded. The rest of the Apkimi tools cover images, video, PDFs and text the same way.