Deepfake Disclosure Under the EU AI Act: 2026 Guide

Deepfake disclosure under the EU AI Act is one of the most misread obligations in the whole transparency chapter, because two separate duties keep getting collapsed into one. This guide separates them cleanly: the provider-side duty to mark synthetic output in a machine-readable way, and the deployer-side duty to disclose deepfakes to the people who see them. You will get a plain reading of Article 50(4), a note on who carries the duty, where and when to place the label, the narrow editorial and artistic exceptions, and a worked per-product example.

This is not legal advice. It is an operational walk-through to help you scope the work and brief your counsel. The Article 50 text and official guidance — not this article — determine what is sufficient for any given product.

Two duties, one output: why the confusion happens

When your product generates a realistic face-swap video, two obligations can attach to the very same file, and they belong to different parties.

Article 50(2) — provider, machine-readable marking. The provider of the generative AI system must mark synthetic audio, image, video or text output as artificially generated or manipulated, in a machine-readable format that is detectable by other software. This is metadata for machines: watermarks, embedded signals, or attached provenance data.
Article 50(4) — deployer, human-facing deepfake disclosure. The deployer of the system must disclose that the content is a deepfake, in a way a person can perceive and understand.

One is read by software. The other is read by a human being. A file can satisfy 50(2) — carrying a clean machine-readable tag — and still fail 50(4) because nobody watching the video was ever told it was fake. The reverse is also true: a visible "AI-generated" caption does not, by itself, discharge the provider's machine-readable marking duty. You can confirm both framings against the official Article 50 explainer from the Commission's AI Act Service Desk.

Treat them as two line items on your checklist, not one. If you are both the provider and the deployer of the same system — a common case for teams that build and run their own tool — you carry both, but you still implement them as distinct controls.

What counts as a deepfake under Article 50(4)

Article 50(4) targets deepfakes: AI-generated or manipulated image, audio or video content that resembles existing persons, objects, places, entities or events and would falsely appear to a person to be authentic or truthful. The test is resemblance to reality plus a realistic appearance — not artistic intent, not how the file was produced.

A few practical consequences:

A photorealistic video of a real politician saying something they never said is squarely a deepfake.
A synthetic voice clone of a named individual reading a script is in scope.
An obviously cartoonish or plainly stylised image that no reasonable viewer would mistake for a real photograph is a weaker candidate — but "obvious" is a judgement call, and the safer path is to disclose and let counsel confirm where the line sits for your product.

Article 50(4) also carries a second, separate branch that is easy to miss: AI-generated or manipulated text published to inform the public on matters of public interest must be disclosed too. That branch is about published informational text, not faces or voices, and it has its own exception (see below). If your product auto-writes news-style or public-interest copy, scope that branch as well as the deepfake branch.

Who carries the duty: the deployer

Article 50(4) puts the human-facing disclosure duty on the deployer — the party that uses the AI system under its own authority and publishes or distributes the output. That is usually you: the SaaS company, the app, the agency, the media team running the tool in production.

This matters because deployers often assume the model vendor "handles disclosure." They do not, at least not for 50(4). The vendor may be the provider and may satisfy the machine-readable marking duty under 50(2), but the visible, human-readable deepfake disclosure travels with the party that puts the content in front of people.

Two edge cases worth flagging to counsel:

Calling a third-party model API (OpenAI, Anthropic and similar) does not remove the duties attached to the AI system you deploy. You are still the deployer of your product.
Modifying or fine-tuning a general-purpose model does not automatically make you its provider — but a significant modification can trigger a separate general-purpose AI assessment. The Commission's GPAI provider guidance is the reference here, and this is genuinely an edge case for a lawyer, not something to decide from a blog post.

Because these roles attach to systems inside products, assess them per product, not per company. Two features in the same app can land differently: one may generate deepfakes and trigger 50(4); another may only summarise text and never touch it.

How and where to disclose: placement and timing

The Act requires the disclosure to be clear and distinguishable, provided at the latest at the time of the first interaction or exposure. Translating that into product terms:

Placement

Make it perceivable in the medium the content lives in. For video, that means an on-screen label or an unmistakable overlay — not a disclosure buried three clicks away in a settings page. For audio, an audible or clearly presented statement. For a published image, a visible caption or badge adjacent to the image.
Bind the label to the content, not just the page. If the asset can be downloaded, embedded, or reshared, a disclosure that only exists in surrounding page chrome disappears the moment the file travels. Prefer a label that stays with the asset.
Write it so a non-expert understands it. "This video is a deepfake" or "AI-generated — depicts events that did not occur" beats vague phrasing like "enhanced with AI."

Timing

Disclose before or at the point of exposure, not afterwards. A viewer should know it is synthetic before they have absorbed it as real.
For interactive or streamed experiences, surface it at the first moment of exposure and keep it available, not as a one-time flash that is easy to miss.

Machine-readable marking is not a substitute

The provider-side machine-readable mark under 50(2) is advisory metadata, not signed provenance. HTML attributes, JSON-LD, or header metadata can be stripped, re-encoded away, or simply ignored by platforms. It is not C2PA-grade certification, and it should not be treated as sufficient on its own for the human-facing duty. There is a voluntary Code of Practice on AI-generated content that teams can look to as the detailed approaches mature. Use machine-readable marking and human-facing disclosure together; do not let one stand in for the other.

The narrow exceptions: editorial, artistic, satirical

Article 50(4) has genuine exceptions, but they are narrower than people hope.

Artistic, creative, satirical or fictional works. Where a deepfake is part of an evidently artistic, creative, satirical or fictional work, the disclosure obligation is limited — it must not hamper the display or enjoyment of the work, and the disclosure can be made in an appropriate manner that does not spoil the piece. Note the word *limited*: the duty is scaled down, not deleted. A satirical film still acknowledges the manipulation somewhere appropriate; it just does not stamp a warning across every frame.
Editorial control over public-interest text. For the AI-generated text branch, the disclosure duty does not apply where the content has undergone a process of human review or editorial control and a natural or legal person holds editorial responsibility for its publication. This is the newsroom carve-out: if a human editor owns the published piece, the automated-text disclosure duty is eased.

What these exceptions are not: they are not a general "it's for marketing" or "it's just fun" escape hatch. If you are relying on an exception, document *why* it applies to that specific product and have counsel confirm it. The reference explainer is a useful orientation, but the determination is legal, not editorial.

Worked example: a per-product walk-through

Consider "CloneCast," a hypothetical B2B app that lets marketing teams generate a spokesperson video from a script using a synthetic avatar and voice. The team calls a third-party model API for generation and publishes finished videos on behalf of clients.

Assess it per product:

1. Classify the output. The avatar resembles a realistic human presenter; some clients upload a real executive's likeness. Realistic, resembles a real or apparently real person → this is deepfake territory under 50(4). 2. Identify the roles. CloneCast is the deployer of the system in its product, so the human-facing disclosure duty sits with CloneCast — not the API vendor. If CloneCast has significantly modified a general-purpose model, it flags a possible provider/GPAI question for counsel. 3. Machine-readable marking (50(2)). Confirm the generative system marks output as artificially generated in a machine-readable format. If the upstream provider does this, verify it actually reaches the exported file; if CloneCast is effectively the provider of its own system, it implements the mark itself. Record this as a distinct control. 4. Human-facing disclosure (50(4)). Add a clear on-screen label to every exported video — for example a persistent corner badge reading "AI-generated video" plus a first-frame statement — bound to the asset so it survives download and reshare. Present it at first exposure. 5. Check for the text branch. CloneCast also auto-generates campaign captions. These are marketing, not public-interest information, so the 50(4) text branch is unlikely to bite — but the team notes the reasoning rather than assuming. 6. Exceptions. A client wants an obviously satirical parody ad. The team documents why the artistic/satirical limb applies, keeps a proportionate disclosure, and asks counsel to confirm before shipping. 7. Document and date. Everything is scoped against the 2 August 2026 application date, with the note that eligible systems already on the market may fall under the limited transition extending provider-side machine-readable marking to 2 December 2026. The date basis is set out in Article 113.

The output of the exercise is not a compliance certificate — it is a documented, per-product review that shows your reasoning and puts the right questions in front of a lawyer.

Dates and scope you should keep in view

Article 50 transparency obligations start to apply on 2 August 2026.
A limited transition can extend provider-side machine-readable marking to 2 December 2026 for eligible systems already placed on the market before the general application date.
The Act reaches providers and deployers outside the EU when systems are placed on the EU market or their output is used in the EU. A non-EU SaaS shipping a deepfake feature to EU users is in scope.

A short checklist

[ ] List every product feature that generates image, audio, video or text.
[ ] For each, classify whether the output can be a deepfake or public-interest text.
[ ] Confirm your role — provider, deployer, or both — per product.
[ ] Verify machine-readable marking (50(2)) actually reaches the exported file.
[ ] Add human-facing disclosure (50(4)) bound to the asset, shown at first exposure.
[ ] Document any editorial/artistic/satirical exception and its reasoning.
[ ] Have counsel review the classifications and any exceptions you rely on.

Next step

If you are mapping these duties across several AI features, start by separating the two: machine-readable marking on the provider side, and human-facing deepfake disclosure on the deployer side. DiscloseKit's free readiness check can help you scope Article 50 obligations per product and organise the evidence — the Act and official guidance still decide what is enough, so keep your counsel in the loop as you go.