If your product generates synthetic audio, images, video or text, the EU AI Act expects you to mark that output so machines can detect it was artificially generated. This guide explains how to label AI-generated content in practice under Article 50(2): what "machine-readable" actually means, the difference between advisory metadata and signed provenance, the marking techniques that fit each output type, and the 2026 dates you need on your roadmap. It is a practical walkthrough for product and engineering teams, not legal advice — see the note at the end.
What Article 50(2) actually requires
Article 50(2) puts the marking duty on providers of AI systems that generate synthetic audio, image, video or text. The output must be marked in a machine-readable format and be detectable as artificially generated or manipulated. The Act also asks that the technical solutions be effective, interoperable, robust and reliable as far as this is technically feasible.
Two things are worth pinning down early.
First, this is the provider-side obligation. It is distinct from the deployer-facing disclosure duties in Article 50(4) — the ones about disclosing deepfakes and AI-generated text published to inform the public on matters of public interest. Article 50(2) is about a technical mark travelling with the output; Article 50(4) is about telling the audience. You may owe both, but they are solved in different places.
Second, the obligation attaches to the AI system inside your product, assessed per product, not per company. A company shipping three products may find one squarely in scope and two outside it. So the honest first step is an inventory: which of your features generate or manipulate audio, images, video or text, and for each, are you the provider of that system?
> Calling a third-party model API (OpenAI, Anthropic and others) does not remove the duties attached to the AI system you provide or deploy. Fine-tuning or modifying a general-purpose model does not automatically make you its provider, but a significant modification can trigger a separate GPAI assessment — an edge case worth taking to counsel. The Commission's guidelines for GPAI providers are the reference here.
Scope also reaches beyond the EU: providers and deployers outside the EU are covered when their systems are placed on the EU market or their output is used in the EU. A US-only team shipping an EU-facing feature is not automatically out of scope.
The 2026 dates to put on your roadmap
Article 50 transparency obligations start to apply on 2 August 2026 (Article 113, dates). That is the date to plan around.
There is one narrow easing. For eligible systems already on the market before the general application date, provider-side machine-readable marking can extend to 2 December 2026. Treat this as a limited transition, not a general extension — it does not push back the rest of Article 50, and whether a given system qualifies is a determination for counsel. The safe planning assumption is that your marking should work by August 2026.
What "machine-readable" means in practice
"Machine-readable" is the phrase that trips teams up, because it does not mean a visible watermark or a line of small print. It means a signal a program can reliably parse without a human reading it. In practice, three families of technique are in play.
1. Advisory metadata (HTML, JSON-LD, headers)
This is embedded, structured data that says "this was AI-generated" in a place software looks. Examples:
- HTTP response headers on an API or media endpoint that flag the payload as synthetic.
- JSON-LD or schema-style annotations attached to a page or an asset describing its AI origin.
- HTML attributes or `<meta>` tags on the surface that renders the content.
- Sidecar or embedded fields — EXIF/XMP for images, ID3 for audio, container metadata for video, structured wrappers for text responses.
The good news: this is cheap, standards-friendly and interoperable. The catch is honesty about what it is. Advisory metadata is a claim, not a proof. It is easily stripped by a re-encode, a screenshot, a copy-paste, or a platform that rewrites metadata on upload. It is the right baseline, and often the most feasible option today, but on its own it is fragile.
2. Signed provenance (and why it is not the same thing)
Signed provenance goes further: the marking is cryptographically bound to the asset and to an issuer, so a verifier can check that the claim has not been altered and can see who asserted it. This is the direction of travel for high-stakes media, because it survives some of the tampering that defeats plain metadata.
Two honest caveats:
- Advisory metadata is not signed provenance. Adding a JSON-LD field or a header is not the same as issuing a signed, verifiable credential. Do not describe a metadata flag as "provenance" in your documentation — it will not stand up to that reading.
- Signed provenance is not, by itself, C2PA certification. C2PA / Content Credentials is a specific ecosystem with its own manifests, trust lists and verification tooling. You can implement signing without being C2PA-certified, and being "C2PA-style" is not a compliance stamp. Article 50(2) asks for machine-readable marking that is effective and interoperable; it does not mandate a single named standard. Treat C2PA as one credible option, not as a box the Act ticks for you.
3. Embedded watermarks
For images, audio and video, statistical or perceptual watermarks embed a signal into the content itself so it survives some transformations that strip metadata. These are more robust than a header but not tamper-proof, vary in quality by modality, and are hardest for short text. Think of them as complementary to metadata, not a replacement.
The realistic posture: layer these. Advisory metadata as the interoperable baseline, watermarking where the modality supports it, and signed provenance where the stakes justify the engineering. No single layer is sufficient on its own, and the Act's own wording — "as far as technically feasible" — acknowledges the limits.
Techniques per output type
Here is how the layers map onto each modality.
Text
Text is the hardest case: metadata does not travel with a copied paragraph. Practical options:
- Return a machine-readable field alongside generated text in your API (for example a response header or a JSON attribute marking it synthetic), so downstream systems can carry the flag.
- Where the text is rendered on a surface you control, add structured annotation (JSON-LD / meta) at the point of display.
- Consider text watermarking where your model stack supports it, understanding it is weaker for short passages.
- Keep a provenance record on your side so you can attest origin later even if the mark is lost downstream.
Images
- Embed XMP/EXIF metadata flagging AI generation.
- Add an invisible watermark for robustness against re-encoding.
- Where warranted, attach signed provenance / Content Credentials so a verifier can check the claim.
Audio
- Write container/ID3-style metadata marking synthetic origin.
- Apply an audio watermark that survives common transcoding.
- Carry the flag in API/stream headers where the audio is served programmatically.
Video
- Mark at the container level and, where feasible, per-stream.
- Combine a frame/audio watermark with metadata for resilience.
- For distribution pipelines, keep the marking as close to export/encode as possible so it is applied once, consistently.
A cross-cutting engineering rule: apply the mark at the generation or export boundary, not sprinkled through the UI. One well-placed step is easier to test, log and prove than ten scattered ones.
A short worked example
Say you ship an EU-facing app with an "AI image" feature built on a third-party model. A workable approach:
1. Confirm the role. You are the provider of the image-generation system inside your product, even though the model is someone else's. The API call does not transfer the duty away. 2. Mark at export. When the image is finalised, write XMP metadata flagging AI generation and apply an invisible watermark in the same step. 3. Serve the signal. Set a response header on the delivery endpoint so programmatic consumers see the flag without parsing the file. 4. Decide on provenance. If these images may circulate in sensitive contexts, evaluate signed Content Credentials — and document that plain metadata is advisory only. 5. Handle the deployer duty separately. If any output is a deepfake or public-interest text, that is Article 50(4) disclosure to the audience, solved in the UI, not in the metadata. 6. Write it down. Record what you mark, how, and where it can be lost, so you can show your reasoning.
A labelling checklist
Use this as an operational review, not a certificate of anything:
- [ ] Inventory every feature that generates or manipulates audio, image, video or text — per product.
- [ ] For each, confirm your role (provider vs deployer) and whether EU market/output-in-EU scope applies.
- [ ] Choose a machine-readable baseline (metadata: headers, JSON-LD, EXIF/XMP/ID3/container).
- [ ] Add watermarking where the modality supports it.
- [ ] Decide, per surface, whether signed provenance is warranted — and record that metadata alone is advisory, not signed provenance, and not C2PA certification.
- [ ] Apply marking at the generation/export boundary and add a test that fails if the mark is missing.
- [ ] Map any separate Article 50(4) audience-disclosure duties (deepfakes, public-interest text).
- [ ] Note the dates: 2 August 2026 general application; provider-side marking possibly to 2 December 2026 for eligible pre-existing systems.
- [ ] Document limits — where each mark can be stripped, and what you do about it.
- [ ] Review with counsel for role determinations and edge cases (significant model modification, transition eligibility).
Be honest about the limits
Two realities worth stating plainly. First, no marking technique is tamper-proof. Metadata gets stripped, watermarks can be degraded, screenshots defeat almost everything. The Act's "as far as technically feasible" language reflects that — the goal is effective, robust, interoperable marking, not an impossible guarantee.
Second, there is a voluntary Code of Practice on AI-generated content being developed to give providers a shared reference for how to satisfy these duties. It is voluntary and evolving; watching it is sensible, but it does not replace your own assessment. The AI Act Service Desk on Article 50 is the official first stop when the text is ambiguous.
Nothing here makes a product "compliant" — the Act and official guidance, not this article, determine what is sufficient. This is a practical starting point to help you scope the work and ask better questions of your legal team.
Next step
If you want a structured way to see where your product stands against Article 50, run DiscloseKit's free readiness check. It walks you through the per-product questions above and helps you document your marking approach — a useful input to the conversation with counsel, not a substitute for it.
_This article is for general information and is not legal advice. Assess each product on its facts and consult qualified counsel for determinations._