Article 50 for developers

A technical implementation walkthrough — C2PA manifests, the AI-generated assertion, watermarking options, detection, and evidence.

1. Scope — who this is for

Article 50(2) of the EU AI Act places a transparency obligation on providers of AI systems that generate synthetic image, audio, video, or text content: outputs must be marked in a machine-readable format and detectable as artificially generated or manipulated. Under the AI Act as currently applicable, the obligation applies from 2 August 2026 to all in-scope systems, regardless of when they were first placed on the EU market. If the agreed Omnibus grandfathering provision is formally adopted, qualifying systems already on the market before that date would have until 2 December 2026 to meet the Article 50(2) marking and detection requirements — that provision is pending final publication in the Official Journal and is not yet law.

Three things developers most often get wrong about scope:

• It follows your users, not your registered office. The AI Act reaches providers placing a system on the EU market or whose output is used in the EU — a UK or US company with EU users can be in scope.
• "Provider" attaches to the brand on the product. If you offer a generation feature under your own name or trademark — including a product built on a third-party model — the provider obligations can sit with you, not only with the upstream model vendor.
• Upstream marking may not survive your pipeline. Some upstream models embed C2PA metadata at generation, but re-encoding, resizing, or stripping metadata in your pipeline removes it. What matters is what your users actually receive.

Whether the obligations apply to your system depends on your answers, not ours — run the scope screener for an orientation. The Code-measure mapping shows which measures a platform can implement for you and which remain yours.

See also: Scope screener and Code-measure mapping.

2. Machine-readable marking with C2PA manifests

The de-facto standard for machine-readable provenance marking is C2PA Content Credentials — an open specification with an open-source reference implementation (c2pa-rs, with Node and Python bindings) and an ecosystem of validators, including Adobe's public verify page. A C2PA manifest is embedded in the asset itself (in a JUMBF container) and consists of:

• Assertions — statements about the asset, stored as CBOR/JSON and referenced from the claim by cryptographic hash. The one that matters here is the AI-provenance action (§2.1).
• A hard binding (c2pa.hash.data) — a hash over the asset's content, so any pixel-level change breaks validation.
• A claim — the CBOR structure tying assertions, binding, and generator identity together.
• A COSE signature (COSE_Sign1, typically ES256) over the claim, carrying the signer's X.509 certificate chain, and — strongly recommended — an RFC 3161 trusted timestamp from a TSA on the C2PA TSA trust list. The timestamp proves when the signature was made, which keeps previously signed assets valid even after a certificate is later rotated or revoked.

Trust state matters as much as the signature. Validators distinguish between a structurally valid signature and one whose certificate chains to the C2PA Trust List. A self-managed certificate produces manifests that validate but display as an unrecognised issuer; a trust-listed certificate requires completing the C2PA Conformance Program and obtaining a claim-signing certificate from a CA on the trust list. Whatever state you sign in, disclose it — presenting a pre-conformance signature as trusted is the fastest way to lose the credibility the mark exists to create.

Key management is the part validators can't see but assessors will ask about: the claim signing key should live in a managed key service (e.g. AWS KMS or an equivalent HSM-backed store) where the private key is non-exportable and signing is an audited API call — not a PEM file on a server.

2.1 The AI-generated assertion

AI provenance is expressed with a c2pa.actions assertion whose action carries an IPTC digitalSourceType:

{
  "label": "c2pa.actions",
  "data": {
    "actions": [{
      "action": "c2pa.created",
      "digitalSourceType":
        "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
      "softwareAgent": "YourProduct/1.0"
    }]
  }
}

trainedAlgorithmicMedia declares fully AI-generated content; compositeWithTrainedAlgorithmicMedia covers AI-manipulated composites (with c2pa.edited). Set softwareAgent — verify pages display it as the "AI tool used".

One discipline worth adopting whatever tooling you use: a marking service should be able to state that content is AI-generated — and nothing more. Assertions about authenticity, human authorship, or a third party's identity are different trust claims with different stakes; keeping them out of an automated signing path by construction (an assertion allow-list) is cheap insurance against your own infrastructure being used to sign something it shouldn't.

3. Watermarking options

Metadata-based marking and imperceptible watermarking answer different failure modes. A C2PA manifest is standard, verifiable, and attributable — but it lives in metadata, and metadata can be stripped by re-encoding, screenshots, or platform processing pipelines. An imperceptible watermark survives (some of) those transformations but is proprietary to its detector. The Code of Practice's Section 1 describes both signed metadata and imperceptible watermarking as marking measures; robust implementations combine them.

The current landscape, honestly summarised:

• Upstream model built-ins — some model providers watermark at generation (e.g. SynthID in Google's image models). If your upstream does this and it survives your pipeline, document it; it may cover part of the measure for you.
• Open-source models (e.g. Meta's Watermark Anything for images, AudioSeal and VideoSeal for other modalities) — check the licence of the weights, not just the code, for commercial service use, and benchmark robustness yourself: crop, screenshot, re-compress, resize.
• Commercial providers (IMATAG, Steg.AI, Digimarc and others) — mature, enterprise sales motions; several are now on the C2PA conforming-products list.

Whatever you choose, two rules keep you honest: state exactly which measures you implement — "signed metadata only" is a legitimate, documentable position, and it is better than an unverified watermark claim — and keep your implementation records specific about the method used per asset, so an information request can be answered with data rather than assertions. Oprindo follows the same rules: watermarking connects through an adapter (your provider or a platform-offered backend), and where no watermark is applied the evidence records say adapter: none explicitly.

4. Detection and verification

Marking is only half of Section 1 — the marks must also be detectable. For C2PA manifests, detection is standard and already public: anyone can validate your marked assets with c2patool, the c2pa libraries, or Adobe's verify page. A validator reports four things worth understanding before you ship:

• Manifest presence — and its absence proves nothing by itself: marks may have been stripped downstream.
• Signature validity — the COSE signature verifies against the certificate in the manifest, and the hard binding matches the content.
• Issuer trust — whether the certificate chains to the C2PA Trust List (§2's trust states).
• Timestamp — whether a trusted timestamp attests the signing time.

Offering your users a verification surface — a link to a public verify page, or a hosted endpoint that returns a plain-language report — is the practical way to make detection available rather than merely possible. Watermark detection, by contrast, is provider-specific: it requires the detector and parameters of whichever watermarking system was used, which is why per-provider detection endpoints exist.

On interoperability: the Code of Practice includes a 2 February 2027 commitment on watermark-detection interoperability — a common API method, embedded signpost, or consortium solution. That date is a Code signatory commitment: it binds signatories, not automatically all providers. The design consequence for everyone else is simple — build detection so it can join whatever common solution emerges, rather than betting on owning it.

5. Implementation evidence

The least glamorous measure is the one that decides how an information request goes: records that show what your implementation actually did. If a regulator, platform, or customer asks "how is this content marked?", the difference between a good and a bad week is whether you can answer per-asset from data.

A useful evidence record for each marking event captures at minimum: a timestamp, the asset's content hash, the manifest identifier, the signing certificate's serial and trust state, and which marking method was applied (including, explicitly, when a watermark was not applied). Two properties turn a log into evidence:

• Tamper-evidence — e.g. hash-chaining each record to its predecessor so insertion, deletion, or modification is detectable, with the append path restricted at the database layer. A log you could silently rewrite proves little.
• Refusal on inconsistency — an export that re-verifies the chain and declines to produce a report over broken records is worth more than one that quietly papers over gaps.

Map each record to the Section 1 measure it evidences (signed metadata, watermark, detection availability, robustness, records) so an export reads as an implementation account rather than a database dump. Be clear about what such a report is: there is no officially prescribed evidence format — an export demonstrates your implementation; it does not by itself settle your obligations. Alongside the technical records, keep the items that remain yours regardless of tooling: your policies, terms-of-service anti-removal clauses, testing records, and legal assessment (see the responsibility split).

6. Key dates and their legal status