BLUF: An AI-content label is reliable only if the disclosure decision, visible notice and machine-readable mark survive every boundary between generation and audience. Treat transparency as an end-to-end data contract: classify the output and actor, issue a provenance record, bind it to the asset, preserve or re-materialise the disclosure through CMS and export transformations, test the delivered representation, and retain evidence of the decision. Metadata alone is too fragile; a visible badge alone is not machine-readable provenance. Use both where the applicable obligation and content type require them.
This is engineering guidance, not legal advice. Article 50 separates provider duties for direct interaction and machine-readable marking from deployer duties for specified disclosures. Scope, exceptions, actor role and the effect of amendments must be confirmed against the current consolidated law and by qualified counsel.
Start with the legal split—not a universal “AI label” switch
The official AI Act text and the Commission’s Article 50 guidance do not create one identical label for every AI-assisted sentence. Article 50(1) addresses direct interaction with an AI system. Article 50(2) requires providers of systems generating synthetic audio, image, video or text to support machine-readable and detectable marking, subject to technical feasibility, content-specific limitations, cost, state of the art and stated exceptions. Article 50(4) addresses deployer disclosure for deepfakes and for certain text published to inform the public on matters of public interest, with specific exceptions. Paragraph 5 adds clear, distinguishable and accessible presentation at first interaction or exposure.
The Commission’s Article 50 FAQ further distinguishes provider and deployer roles, standard editing, machine-to-machine outputs, closed-loop industrial or product-development contexts and human editorial review. Those distinctions belong in a counsel-owned applicability rule, not in an engineer’s guessed boolean. The architecture should execute a reviewed decision and preserve its evidence.
The failure boundary is the export boundary
A generator may attach a machine-readable mark correctly, yet the delivered file can lose it. Image resizing can discard EXIF or XMP. Screenshotting rasterises a page and leaves DOM metadata behind. PDF printing can flatten accessibility and document metadata. Video transcoders can remove container fields. A CMS may preserve an upload but create derivatives without custom metadata. Social platforms often re-encode assets. Copy-and-paste can detach text from its source record. The compliance-relevant test is therefore not “did the model emit a mark?” but “what did the audience receive after the actual transformation chain?”
This is different from logging and technical documentation. Logs prove what the system decided and did; they do not make a disclosure visible to the audience. Conversely, a visible label does not reconstruct the model, policy version, exception or transformation that produced it. Link the two through stable IDs without exposing sensitive internal logs.
Reference architecture: generation to delivered representation
GENERATION EVENT → content classifier → actor-and-scope policy → disclosure decision → provenance record + content digest → [machine-readable mark / visible disclosure / both] → source asset registry → CMS ingest → derivative builder → API or document export → channel adapter → delivered-representation verifier → evidence store and exception queue. Every arrow is a transformation contract. Every output variant receives its own digest and verification result.
The applicability decision can reuse the relationships captured by an AI use-case applicability graph: system provider, deploying organisation, purpose, content modality, audience, editorial responsibility, distribution channel and jurisdiction. Keep legal assertions—such as an approved exception—separate from computed engineering facts such as “XMP absent after resize.”
Use a provenance envelope, not a metadata guess
Define one immutable provenance envelope per content version. Minimum fields: provenance_id; parent_provenance_id; content_digest and digest algorithm; asset_id and variant_id; generator system and release reference; provider/deployer role assertions; modality; disclosure_policy_id and version; decision outcome; applicable disclosure surfaces; exception assertion with owner and evidence reference; transformation history; created_at; verification status; signer/key reference; retention class; and human editorial-responsibility record where relevant. Do not place personal data, prompts or confidential source material into public metadata.
The envelope is the system of record; embedded metadata is one carrier. Sign the canonical envelope or store it in an append-only evidence service, then bind each exported asset by digest. When a transformation necessarily changes bytes, create a child envelope rather than pretending the old digest still matches. This makes the lineage explicit: original → resized image → WebP card → PDF attachment → platform-delivered derivative.
Decision table: which surface must survive?
Content and context | Primary actor question | Delivery control | Export test | Counsel decision Direct conversational UI | Is the system itself interacting with a natural person? | persistent accessible interaction notice | first interaction, resumed session, embedded widget and API client | obviousness and any exception Synthetic image/audio/video | Is the organisation provider, deployer or both for this system? | machine-readable mark plus required visible disclosure for covered deepfakes | resize, transcode, screenshot, download and platform re-encode | scope, deepfake definition, artistic/other exception Public-interest text | Is it published to inform the public and who holds editorial responsibility? | disclosure at publication surface when required; provenance retained internally | CMS render, RSS, print/PDF, syndication and copy path | public-interest purpose and human-review exception Standard editing | Does the assistance substantially alter input or semantics? | retain decision evidence; avoid blanket public claims | compare input/output and tool mode | whether standard-editing exception applies Closed B2B/industrial output | Is it genuinely closed-loop and never exposed to people? | contractually constrain channel; monitor leakage | API destination and downstream export | conditions of any narrow exclusion or exemption
Build the export contract
Each renderer and channel adapter should declare inputs, transformations and guarantees. Example: cms_to_web accepts provenance_id and source asset, preserves a public disclosure component, emits JSON-LD or another approved machine-readable carrier, writes the derived digest back to the registry, and fails closed when a mandatory surface is absent. pdf_export may be unable to preserve the same carrier; its contract can render a visible accessible notice and embed a document-level provenance reference, then verify both in the resulting bytes and rendered pages.
Do not silently downgrade. Return a typed outcome: PRESERVED, RE_MATERIALISED, NOT_APPLICABLE, EXCEPTION_APPROVED, or BLOCKED. Include policy version, transformation version, verifier version and evidence URI. A channel that cannot carry the required mark goes to an accountable exception or alternative-delivery path; it must not simply log a warning after distribution.
Verification must inspect the output, not configuration
Create golden assets for text, image, audio and video. Send them through every production path: upload, crop, responsive rendition, CDN optimisation, download, email attachment, API export, office-document conversion, print/PDF and supported social publishing. Extract the resulting metadata, render the visible disclosure, check accessibility semantics, recalculate digests and test detection where the selected technique supports it. Run this suite when the CMS, image library, encoder, template, CDN or channel integration changes.
Keep three independent signals: carrier presence, audience disclosure and lineage match. Carrier presence answers whether expected metadata or watermark remains. Audience disclosure answers whether the notice is clear, distinguishable and accessible in the delivered experience. Lineage match answers whether the delivered bytes map to an approved provenance chain. None alone proves the others—and provenance does not prove that the underlying claim is true.
Implementation checklist
1. Inventory generation and editing systems, content modalities, actor roles and delivery channels. 2. Obtain reviewed applicability rules and exception owners; do not encode informal legal conclusions. 3. Define the provenance envelope, stable IDs, digest/signature policy and retention. 4. Add disclosure_policy_id and provenance_id to CMS/API schemas. 5. Specify transformation contracts for web, PDF, media derivatives, syndication and social channels. 6. Implement visible, accessible disclosure components separately from machine-readable carriers. 7. Build golden-asset export tests and block releases on mandatory-surface loss. 8. Monitor NOT_VERIFIED and BLOCKED outcomes; assign remediation owners and expiry. 9. Re-evaluate rules when law, Commission guidance, standards, encoders or channels change.
Failure modes and trade-offs
Metadata stripping is the obvious failure. Less obvious failures are a stale policy decision after the use case changes; a digest that points to the source but not the delivered derivative; a badge hidden by responsive CSS; German pages carrying an English disclosure; signed provenance with unmanaged keys; and “human reviewed” selected without a named editor or retained decision. Test locale, accessibility, derivatives and exception evidence—not only the happy-path file.
More carriers improve resilience but add implementation cost, file size, key management and false-positive handling. Visible labels can reduce ambiguity but consume interface space and may be inappropriate for some artistic contexts. Detection is probabilistic for some techniques and can degrade after transformation. The sensible target is not an indestructible universal watermark; it is a documented, content-specific control set with measured transformation behaviour, fallback disclosure and accountable exceptions.
Primary sources and legal boundary
Primary references: Regulation (EU) 2024/1689; Article 50 text in the EU AI Act Service Desk; Commission Guidelines on Article 50 transparency obligations; Code of Practice on Transparency of AI-generated Content; and the Commission Article 50 FAQ. The Commission states that Article 50 applies from 2 August 2026 and explains a limited transition for certain earlier systems; because the legal text and guidance can be amended, counsel should verify current applicability, dates and exceptions before relying on any implementation.
Make one export path auditable
Choose the highest-volume content path—such as generated image → CMS → responsive CDN derivative → download—and trace one asset end to end. I can help turn that trace into a provenance schema, transformation contract, automated verifier and release gate. The useful deliverable is a testable answer to one question: which disclosure reached the audience, and what evidence proves it survived the path?
