EU AI ACT · ARTICLE 50(2)Lucairn / Compliance

Machine-readable marking of synthetic content —
what the regulation requires, what Lucairn produces.

Effective 2 December 2026.

Article 50(2) of the EU AI Act requires providers of AI systems generating synthetic audio, image, video, or text to ensure their outputs are marked in a machine-readable format and detectable as artificially generated. The obligation becomes effective on 2 December 2026 — a compromise date set by the May 2026 Digital Omnibus. The regulation does not specify the marking technique; standards work at CEN-CENELEC JTC 21 and ISO/IEC is in progress, and the AI Office's guidance is pending. Until those settle, deployers and providers need a defensible mechanism. This page explains what the obligation actually requires, why notification copy alone is not sufficient, and how Lucairn's per-conversation Decision Certificate maps to the regulator's likely test under Article 74.

01What the regulation says

Article 50(2),
in plain reading.

Article 50(2), verbatim:
“Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated.”
EU AI Act · Article 50(2) · consolidated text via EUR-Lex
A

What “machine-readable” means here.

Detectable by an automated process, not just by a human reading a notification. This is the key shift away from notification-copy as the compliance approach. A privacy banner that says “this content was generated with AI” does not survive a regulator running a detector against the actual file.

B

What Article 50(2) does NOT specify.

The marking technique. The detector. The provider/deployer split of responsibility for marking versus detection. Those are being settled in CEN-CENELEC JTC 21 standards work (ongoing) and AI Office guidance (pending). Any vendor claiming Article 50(2) certification today is overclaiming — the standards aren't finalised.

C

Cross-reference to Article 50(4).

Deployers of synthetic content disclose. Providers under 50(2) mark. The marking has to be present in the response for the deployer's disclosure to be verifiable. The two paragraphs lock together — if the upstream provider's marking is absent or stripped, the downstream deployer's disclosure becomes unfalsifiable.

02Why notification copy isn't enough

The regulator's question
is per-output, not per-policy.

The regulator's question under Article 74 is: “show me, for this specific output, that it was marked at the time of generation.” A privacy notice or banner that says “we mark our content” does not answer that question. The defense requires four properties together:

  • An artifact bound to the specific output. Not a policy referring generically to “all AI-generated content.” A record that ties to this hash, this prompt, this response.
  • Produced at the moment of generation. Not retrofitted from logs after a complaint comes in. The timestamp matters because retrospective marking is exactly what an investigation rules out.
  • Verifiable by an independent party. The investigator should not need to take the deployer's word for anything. The signature, the inclusion proof, the timestamp authority — all checkable without contacting Lucairn or the deployer.
  • Not stripped or modifiable by the deployer or downstream platforms. A marking embedded in mutable application logs fails this property. A signed external receipt anchored to a public transparency log survives operator compromise.

This is the same gap the cornerstone post on Article 50 deployer obligations describes — see Article 50 of the EU AI Act — what GPAI deployers actually have to ship by August 2026. Article 50(2) makes the gap sharper because the regulator can run a detector directly against the content; the deployer cannot defend the absence of a mark by pointing at policy text.

03What Lucairn produces

A per-conversation
signed receipt, by construction.

Plain language. Map the architecture to Article 50(2):

  • Per-conversation Decision Certificate. Every inference call routed through the Lucairn gateway produces a signed receipt. The receipt binds the input (sanitized prompt hash), the output (sanitized response hash), the model identifier, the timestamp, and the participating service signatures (sanitizer, bridge, gateway, sandbox-b inference). The witness assembler service in-tree owns the signable construction.
  • Ed25519 signatures. Each participating service signs its claim. The witness then signs the assembled certificate over a 7-key signable map locked by an in-tree invariant test. The cryptographic chain is reconstructable from the public Lucairn keystore endpoint.
  • Sigstore Rekor v2 anchoring. Inclusion proofs are written to the public Rekor transparency log (Rekor v2, GA October 2025). Anyone can verify the certificate was published before any disputed downstream event — a property the deployer cannot fabricate after the fact.
  • FreeTSA RFC 3161 timestamps. Independent time anchor that doesn't depend on Lucairn's clock or Rekor's clock. RFC 3161 is the standard the financial-services and document-archiving worlds have used for two decades.
  • Recipient-side detector. The public /verify page accepts a certificate ID or URL and reconstructs the chain. Programmatic verification via the published SDKs (Python, TypeScript, Go) on /developer.

What this is not. It is not a watermark embedded in the audio/image/video/text content itself. Lucairn produces a signed external receipt bound to the content. That is one defensible answer to “machine-readable marking”; it is not the only architecture the regulator will accept, and the Act does not endorse a specific technique.

04What a 7-month path looks like

Roughly thirty weeks
until 2 December 2026.

Calibrated to a single-team rollout. The shape transfers across organisation sizes; only the scoping in Weeks 1–4 changes materially.

Weeks 1–4

Inventory.

List every place your product or workflow generates synthetic content. Classify each into: text generation (LLM completion / chat output), image generation, audio synthesis (TTS, speech-to-speech), video generation. Most teams underestimate the number of paths — internal tools and Slack-integrated agents are usually missing from the first pass.

Weeks 5–10

Decide marking approach.

Native watermarks (model-level) for image and audio — frequency-domain or spread-spectrum techniques are mature; for text, watermarking is contested today (see C2PA Content Credentials and contemporary academic literature). External signed receipts (the Lucairn-class architecture). Or both. The choice is partly contractual: which upstream GPAI providers are you bound to, and what marking do they ship?

Weeks 11–18

Build the detection path.

A regulator under Article 74 will run their detector. If your marking is internal (native watermark), the detector ships with the model or with C2PA-aware tooling. If your marking is external (signed receipt), the detector is your /verify endpoint or SDK. Either way, the deployer's runbook needs the detector documented before an incident.

Weeks 19–26

Wire the contractual chain.

If you depend on a GPAI provider for the marking, your contract has to cover their Article 50(2) compliance, the technical mechanism they use, and your access to the verification path. The deployer's Article 50(4) disclosure has to point at a verifiable upstream marking — otherwise the disclosure is hearsay.

Weeks 27–30

Run a regulator-style audit drill.

Pick a synthetic-content sample from production, hand it to someone outside the team, ask them to verify the marking. If they cannot, the gap is real before 2 December 2026. The drill is the only output that survives “we believe we comply” as a defence.

05What Lucairn doesn't claim

The honest scope
of this mechanism.

  • Lucairn does not claim Article 50(2) compliance on behalf of any customer. The regulation binds the provider of the AI system; Lucairn is infrastructure your team uses to produce the evidence layer. Compliance is a controller obligation involving governance, risk management, and deployer-side disclosure under Article 50(4) — Lucairn covers the technical surface; your CISO and DPO cover the rest.
  • Lucairn does not claim its signed-receipt approach is the only acceptable Article 50(2) marking technique. The regulation deliberately does not specify a technique, and CEN-CENELEC JTC 21 + ISO/IEC standards work is ongoing. When the standards land, vendors will need to revisit — including Lucairn.
  • Lucairn does not embed watermarks in the output content itself. If your use-case requires content-embedded watermarks (image-only deployments, broadcast workflows, file-archival pipelines), the Lucairn receipt complements but does not replace that.
  • The Act may evolve before 2 December 2026. Secondary legislation, AI Office guidance, or further Omnibus revisions can change the operative shape. Track those — the obligation date is fixed, but the implementation guidance is still moving.
06Next steps

Verify a sample certificate
or see the full obligation map.

The architectural claim is checkable. The verify page lets you audit a real signed certificate without contacting Lucairn; the EU AI Act compliance landing maps every other obligation (Articles 12, 13, 14, 15, Annex IV) to receipt fields the same way.

Verify a sample certificate →See the full obligation map →

REFERENCES