---
title: "When you must label AI-generated content in the EU"
canonical: "https://auditbadger.com/blog/when-you-must-label-ai-generated-content-in-the-eu/"
last-updated: "2026-08-23"
---

# When you must label AI-generated content in the EU

By Maciej • Published 2026-08-27 • 7 min read • Categories: Compliance Governance, Legal Regulations, Policy Management

Created with AI assistance. AuditBadger retains editorial control and responsibility.

**TL;DR:** EU AI Act article 50 contains four different disclosure duties that get conflated constantly. Providers of systems that interact with people must make sure users know they are dealing with an AI unless it is obvious. Providers of generative systems must mark synthetic audio, image, video and text in a machine readable format so it is detectable as artificially generated, which is metadata and watermarking, not a visible label. Deployers of emotion recognition or biometric categorisation must inform the people exposed. And deployers must disclose deep fakes, plus AI generated text published to inform the public on matters of public interest, with one important exemption: the text duty falls away where the content went through human review or editorial control and a natural or legal person holds editorial responsibility for it. That exemption is the practical answer for most content teams, because earning it costs one named editor and a review step you probably already have. Ordinary marketing copy about your own product is not obviously text informing the public on a matter of public interest, but the safest posture is to name an editor rather than argue the boundary. All of this has applied since 2 August 2026.

Short answer: you have to disclose when you publish a deep fake, and when you publish AI generated text to inform the public on a matter of public interest without a human taking editorial responsibility for it. Separately, if you build the generative system, you have to mark its output in a machine readable way. And if you run something people talk to, it has to say it is not a person.

Four duties, not one. They apply to different parties, they are satisfied in different ways, and mixing them up is why so much advice on this topic reads as either paranoid or complacent. All of them have applied since 2 August 2026.

## The distinction that clears up most of the confusion

Article 50 contains two fundamentally different kinds of obligation.

**Marking** is technical and machine facing. It sits on the provider of a generative system: outputs must be marked in a machine readable format and detectable as artificially generated or manipulated. Think watermarks, provenance metadata, signed manifests. A person reading the page will usually see nothing.

**Disclosure** is human facing. It sits mostly on the deployer, the party publishing or operating the thing: a label, a notice, a sentence that a reader actually reads.

You can be fully compliant on marking and still owe a disclosure, and the reverse. Treat them as two separate lines in your control set.

## Duty one: systems people talk to

AI systems intended to interact directly with people must be designed so the person is informed they are interacting with an AI, unless that is obvious to a reasonably well informed, observant and circumspect user.

In practice: your support bot needs to say so. The bar is low and the fix is a sentence in the opening message plus a persistent label in the widget. The "obvious" carve out exists, but arguing that your assistant is obviously a machine is a worse use of your time than just labelling it.

Note the timing rule that applies across article 50: the information has to be given at the latest at the first interaction or exposure, and it has to be clear, distinguishable and accessible. A disclosure buried in your terms of service is not a disclosure.

## Duty two: marking synthetic output

If you provide a system that generates synthetic audio, image, video or text, the outputs have to be machine readable as artificially generated or manipulated. The obligation is qualified by technical feasibility and effectiveness, and it explicitly expects solutions to be robust and interoperable as far as that is possible.

For a small team building on a model provider's API, the practical questions are: what does the provider already embed, does it survive your processing pipeline, and what do you add on top for content you generate and store yourself. Write the answer down. This is the article 50 duty most likely to be technically incomplete at a small company, and being able to show what you assessed and why is worth more than pretending it is fully solved.

## Duty three: emotion recognition and biometric categorisation

Deployers of emotion recognition systems or biometric categorisation systems must inform the people exposed to them. Most small SaaS teams are nowhere near this, but check before dismissing it: sentiment scoring of a person's voice or face is not the same as sentiment analysis of written text, and the first one is squarely in scope.

## Duty four: deep fakes and published text

This is the one people mean when they ask about labelling, and it splits in two.

**Deep fakes.** Deployers generating or manipulating image, audio or video content that constitutes a deep fake must disclose that it has been artificially generated or manipulated. Straightforward, and the disclosure is visible.

**Published text.** Deployers of AI systems that generate or manipulate text published with the purpose of informing the public on matters of public interest must disclose that the text was artificially generated. Then comes the exemption that changes everything for content teams:

> the duty does not apply where the AI generated content has undergone a process of human review or editorial control and a natural or legal person holds editorial responsibility for the publication.

Read that twice if you run a blog. The exemption is not a loophole you have to squeeze through. It describes what a functioning editorial process already looks like: a human reads it, a named party owns it.

## So does your marketing blog need a label?

Two questions decide it, and only one of them is worth arguing about.

The first is whether the text is published to inform the public on a matter of public interest. The Act does not hand you a tidy definition. A guide to a regulation sits closer to that line than a product release note or a landing page, and reasonable people will read the boundary differently.

The second question is whether a human reviewed it and someone holds editorial responsibility. If the answer is yes, the first question stops mattering.

That is the whole practical strategy. Rather than litigating what counts as a matter of public interest across your content calendar, make the exemption unambiguously true for everything you publish: a named editor, a review that actually happens, and a record that it happened. It is cheaper than the argument, and it is better editorial practice regardless of what the law says.

## Turning this into controls you can evidence

Four artifacts cover it. None of them is heavy.

1. **A register of AI touched surfaces.** Every place AI generates or manipulates something a customer or the public sees: product features, the bot, generated images, published content. One row each, with the hat you wear (provider, deployer, or both).
2. **A labelling standard.** What the disclosure says, where it appears, and what triggers it. Applied consistently, because inconsistency is what makes a disclosure look decorative.
3. **A named editorial owner** for anything published, and a review step recorded per piece. This is what buys the exemption, so make the evidence boring and durable: who reviewed, when, and that they took responsibility.
4. **A marking assessment** for anything you generate: what your model provider embeds, what survives your pipeline, what you add, and what is not currently feasible with the reason.

If you already run a policy process, this fits inside it rather than beside it. The mechanics are the same as any other policy you have to keep current and prove people follow, which we covered in [the practical guide to internal policy management](/blog/internal-policy-management-the-complete-practical-guide/).

## Where to start

If you have not yet worked out which of the four duties reach you, do that before writing any policy. Our free assessment asks nine plain language questions and produces a dated applicability record with the reasoning attached, plus an action plan with controls, evidence and owners. No email required, and nothing you type is stored. [Run it here](/eu-ai-act-article-50/assessment/).

For the long form version of every obligation above, including what to keep on file for each one, read [the Article 50 operational pack](/eu-ai-act-article-50/). And if you are still at the earlier question of whether the Act touches you at all, start with [does the EU AI Act apply to your SaaS](/blog/does-the-eu-ai-act-apply-to-your-saas/).

One closing caveat, in the spirit of not overselling. This is an operational reading of one article, not legal advice, and the boundary of "matters of public interest" has not been tested. That is precisely why we recommend the editorial responsibility route: it makes the boundary irrelevant to you.