EU AI Act Article 50: Marking AI Output in Production

Four duties across two roles, with separate owners, separate artifacts, and in one case a separate deadline.

Article 50(3) covers a separate class of systems, is out of scope here, and also applies on 2 August 2026 with no transition.

Two structural points change how you scope this. Article 50 is not a high-risk obligation: it reaches all AI systems in its situations, so a support chatbot with zero Annex III exposure is squarely inside 50(1) and, if it generates text, inside 50(2). And the 50(2) exemptions are scope-limited, applying only "to the extent" a system performs assistive standard editing or does not substantially alter deployer-supplied input, which forces per-endpoint classification.

Article 50(6) preserves everything else, so this is additive to your GDPR posture. Our guide on GDPR compliance for AI systems handling EU customer data covers the lawful-basis side of that overlap.

The Digital Omnibus is no longer a provisional agreement. It is Regulation (EU) 2026/1744, signed 8 July 2026, published in the Official Journal on 24 July 2026, in force since 27 July 2026. Anything describing it as pending is stale. It deferred Chapter III. It did not defer Article 50, which sits in Chapter IV.

The transition is narrower than most summaries suggest, and broader. Narrower: it covers Article 50(2) and nothing else, so a system that both interacts with people and generates content still owes 50(1) on 2 August 2026 while its marking is in flight. Broader: 50(2) has a marking limb and a detectability limb, and the Guidelines describe the transition as covering both. Write "Article 50(2)" into your plan.

One content-side trap: outputs generated before 2 August 2026 need no retroactive marking, but text generated before that date and published on or after it does need labelling. A scheduled content queue crosses that line.

Note the knock-on. 2 August 2026 is no longer a high-risk deadline; here it means Article 50 transparency and nothing else. Our analysis of EU AI Act data residency and sovereignty requirements covers the Chapter III timeline in depth.

The provider carries 50(1) and 50(2). The deployer carries 50(4). Get this backwards and you build the wrong thing.

The trap is assuming that using someone else's model makes you a deployer. Article 50(2) binds "providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content". If you assemble a system and put it into service in the Union, the marking duty attaches to that system, and the Guidelines close the escape route: providers may rely on a marking solution implemented by an upstream model provider or a third party, and such reliance is "without prejudice to the responsibility of the provider of the AI system to demonstrate compliance."

You may inherit the mechanism. You may not inherit the burden of proof. For on-premise and air-gapped deployments, where most regulated workloads land, that means four things:

The Guidelines do carve out purely personal non-professional activity by deployers, research and development, and free and open-source licences. Across deployments we have reviewed, the R&D framing is the one teams reach for and the one that survives contact with a live production endpoint least often. Note too that technical feasibility "is an objective notion that is not dependent on the specific resources and capabilities of individual providers." Being a small team is not a defence.

Article 50(5) sets the timing: the information must arrive "at the latest at the time of the first interaction or exposure", clearly and distinguishably. For a streaming chat UI, that means before the first token.

Render the disclosure from application state, in the transport or UI layer. Never from the system prompt. A system-prompt disclosure is a probabilistic control on a deterministic legal duty, exposed to instruction drift, injection, sampling temperature, and every context eviction you will ship. It also costs tokens and delays first output. If you stream, emit the disclosure as its own frame before the model stream opens:

event: disclosure
data: {"kind":"ai_system","modality":["text"],"marked":true,"detect":"/.well-known/ai-content-detect"}

event: token
data: {"delta":"Sure, "}

The client renders the persistent disclosure on frame one, before the model call is issued. Time to first token is unchanged; time to first disclosure drops to zero.

Three notes. Do not rely on "obvious." That exemption applies where interaction with an AI system is obvious to a "reasonably well-informed, observant and circumspect" person, a standard you argue after the fact and one that does not scale across embedded widgets, voice channels, or a chat surface reached from a deep link. Watch the carve-out's own carve-out: 50(1) exempts systems authorised by law to detect, prevent, investigate or prosecute criminal offences, and that exemption switches off where the system is available for the public to report a criminal offence, putting a public reporting portal back inside the duty. Accessibility is in the statutory text, and the Code names ETSI EN 301 549 and WCAG 2.1 as reference points, so screen-reader detectability of the disclosure is part of the obligation.

Here the law and the Code diverge, and collapsing them is the most common analytical error in this space.

The law permits one technique. Guidelines paragraph (72) is explicit: providers may rely on a single marking technique or a combination, so long as the overall technical solution is machine-readable and meets the four requirements to the legally required degree.

The Code commits signatories to two. The Code of Practice on Transparency of AI-Generated Content, final since 10 June 2026 and assessed as adequate by both the Commission and the AI Board, records the signatories' acknowledgement that in most cases, in particular for content that can be disseminated online, no single technique suffices. On that premise they commit to at least two layers: Sub-measure 1.1.1, digitally signed metadata, and Sub-measure 1.1.2, imperceptible watermarking.

Adherence is voluntary, and per the Omnibus recitals, codes under Article 50(7) have limited legal effect and grant no presumption of conformity. Two layers is a state-of-the-art judgement rather than a legal floor. Ship one and you carry the argument that it clears the bar.

Sub-measure 1.1.1 requires recorded information be "digitally signed and time-stamped ... in a secure and tamper-evident manner". Sub-measure 1.1.2 requires the watermark be embedded so it is difficult to separate from the content. Sub-measure 1.1.3 covers fingerprinting or logging, is optional, and the Code says outright that relying on either alone is not sufficient.

C2PA is a reasonable way to build the metadata layer. Its 2.x specification defines a manifest as one or more assertions including content bindings, exactly one claim, and one claim signature, mapping cleanly onto "digitally signed and time-stamped". Just do not tell your auditor the EU asked for it.

generate → assert → sign → bind → deliver → detect
             │        │       │              │
             │        │       │              └─ public verification route (50(2) detectability)
             │        │       └─ hard binding over asset bytes + soft binding for recovery
             │        └─ claim signature, time-stamped, key in your own HSM or KMS
             └─ minimal assertion set: was this AI generated or manipulated, by which system

Keep the assertion set minimal on purpose. Paragraph (73) separates the legal duty from what a provenance framework offers: "providers are not required to record or keep a full provenance chain containing information on content origin and modifications or any other relevant assertion concerning the history of the content." Article 50(2) is a "was this AI?" flag. Every extra assertion you sign is a data-protection surface you now own.

Robustness is not an abstract adjective. Guidelines paragraph (79) defines it as the capability to identify and distinguish AI-generated content "under varying conditions, covering both common alterations and adversarial attacks." Common alterations includes your own delivery path, which makes your CDN a compliance surface.

The mechanics follow from first principles. A hard binding is one or more cryptographic hashes over the asset bytes. Your image pipeline emits renditions: resized, re-encoded, format-shifted for bandwidth. Change the bytes and the hash no longer matches. The C2PA specification names this class, defining an asset rendition as a representation where a non-editorial transformation such as re-encoding for reduced resolution or bandwidth has been applied. It documents removal in its own words, under a threat entry titled "Threat: Stripping C2PA Manifests": "C2PA does not offer any protection against the complete removal of C2PA manifests from assets", while the design does aim to prevent unauthorized tampering with the asset or the manifest. Tamper-evidence is not tamper-proofing.

Two documented mitigations, both decided before launch. Manifest repositories: serving manifests to user agents when the embedded copy is missing, which is a service you run, with retention and availability targets. Durable Content Credentials: a Content Credential whose soft bindings (a fingerprint or an invisible watermark) enable discovery in that repository. The stated purpose is to enable recovery of the manifest, so write it that way in your own docs. Actual survival depends on the specific watermark algorithm and the specific transformation.

Test every variant your delivery tier can emit, as a gate:

#!/usr/bin/env bash
# Run per rendition, per CDN behaviour, in CI. Not once, at launch.
set -euo pipefail

ORIGIN="https://origin.internal/assets/sample.jpg"
declare -a EDGE=(
  "https://cdn.example.com/assets/sample.jpg"
  "https://cdn.example.com/assets/sample.jpg?w=640"
  "https://cdn.example.com/assets/sample.jpg?fm=webp"
)

curl -sS "$ORIGIN" -o /tmp/origin.bin
for url in "${EDGE[@]}"; do
  curl -sS "$url" -o /tmp/edge.bin
  same_bytes=$(cmp -s /tmp/origin.bin /tmp/edge.bin && echo yes || echo no)
  # Replace with your verifier. Must exit non-zero when no manifest is found.
  metadata=$(verify-manifest /tmp/edge.bin >/dev/null 2>&1 && echo present || echo STRIPPED)
  watermark=$(detect-watermark /tmp/edge.bin >/dev/null 2>&1 && echo present || echo LOST)
  printf '%-56s bytes_identical=%-4s metadata=%-9s watermark=%s\n' \
    "$url" "$same_bytes" "$metadata" "$watermark"
  [ "$metadata" = "STRIPPED" ] && [ "$watermark" = "LOST" ] && exit 1
done

The exit condition encodes the compliance rule. Losing the metadata layer at the edge is survivable if the watermark recovers the manifest. Losing both is an Article 50(2) failure that ships silently, because the asset still renders perfectly.

Detection is the other half, and it is a deliverable. Paragraph (70) states that fulfilling only one element, for example marking without the means for detection being available, will not suffice. Paragraph (76) sets the target: publicly available industry standard detection any third party can implement, ideally locally executable on the device. Where such standards do not yet exist, particularly for watermarking at this stage, your own or a shared detector is permitted, and that possibility "should be limited in time". Build the interface so you can swap the implementation.

Free-form text is the hard case, and the Code says so by treating it differently from everything else. Because free-form text cannot transport metadata, a single layer of imperceptible watermarking is considered sufficient for it. The threshold is concrete: free-form text longer than 200 tokens still requires watermarking "even though it may have lower reliability compared to that of watermarking very long text", while very short text is excepted. That is the Code conceding, in a document its own signatories wrote, that text watermarking degrades as text gets shorter.

Route by container, not by modality. The moment output lands in a document format, containerised text carries metadata and the two-layer commitment returns. A chat endpoint and a "download as document" button on the same product are different compliance paths.

Build the log as a backstop and do not call it the answer. Sub-measure 1.1.3 permits logging, notes it may be appropriate for text, and states that logging alone is not sufficient. Keep an append-only record keyed by content digest:

{
  "digest": "sha256:9f2c...",
  "generated_at": "2026-08-03T09:14:22Z",
  "system": "internal-assist",
  "kind": "generated",
  "container": "free_form",
  "tokens": 412,
  "watermark": {"applied": true, "layer": "model"}
}

Note what is absent: no prompt, no user identifier, no retrieved passages, no edit chain. A marking log that quietly becomes a prompt archive is a GDPR problem you created to solve an AI Act problem.

Article 50(2) has exactly three exemptions: assistive function for standard editing, no substantial alteration of the input data provided by the deployer or the semantics thereof, and law-enforcement authorisation. The operative qualifier is "to the extent", which makes them partial and scope-limited.

Classify per output path, write down the reasoning, and default to marking when the analysis is close. Marking an exempt output costs you nothing legally. The reverse costs you Article 99(4)(g).

The RAG row surprises teams: a retrieval-augmented answer composes prose around content the deployer never supplied as input to that request, so the "input data provided by the deployer" limb does not reach it.

On the deployer side, the Article 50(4) sub-paragraph 2 carve-out for published text is genuinely conjunctive. Disclosure is not required where the content has undergone "a process of human review or editorial control" and a natural or legal person "holds editorial responsibility for the publication". Both limbs. A review queue nobody is accountable for fails the second; named accountability with no actual review fails the first. The control patterns in our guide to human-in-the-loop approval for AI agents are the same primitives: a real reviewer, a recorded decision, an identifiable owner.

The artistic, creative, satirical and fictional carve-out in sub-paragraph 1 is a reduction rather than an exemption. Disclosure of the existence of generated content is still required, "in an appropriate manner that does not hamper the display or enjoyment of the work".

EU icons are published for 50(4) labelling: fully AI-generated, partially AI-modified, and a basic icon for pairing with an interactive layer. Using them is optional; the labelling duty is not. One constraint catches localisation teams: the Code requires the capitalised acronym AI in English as the main visual element, with a national-language acronym permitted only where English is incompatible with national laws on language use in commercial or administrative matters. Do not build a per-locale acronym matrix. For audio-only deep fakes, the Code asks for a short audible disclaimer at the start of the content, in the content's own language or in English.

Then work the list:

The detection path is where most teams will fail, not the marking. Marking is a build. Detection is a service with an availability target, an interoperability commitment, and a time limit on running your own. If your Article 50 plan has an engineer on the encoder and nobody on the verifier, it is not a plan. For the wider regulatory picture in supervised sectors, our post on AI compliance in financial services maps how these obligations stack, and the AI for business pillar collects the rest of the governance work.