Labelling AI in your product under the EU AI Act: disclosure patterns that work on screen

Since 2 August 2026, Article 50 of the EU AI Act has required AI products to tell people they are dealing with an AI system, and to mark AI-generated content so software can detect it (generative systems already on the market before that date have until 2 December 2026 for the marking). Deepfakes, and AI text published to inform the public on matters of public interest, also need a visible label. For a SaaS product with an assistant, a copilot or generated text, the law turns into three design decisions: where the notice sits, what it says and when it repeats.

Our short answer: say it in plain words at the first turn, keep a small persistent marker beside the AI, put the label on the output at the point where someone decides whether to trust it, and track what a human changed. The rest of this page sets out the duties as they land on screens, surface by surface. It is design guidance, not legal advice: your counsel decides which of these duties apply to your product.

What Article 50 requires

Article 50 of Regulation (EU) 2024/1689 holds four duties and one rule about how all of them are delivered:

• Article 50(1), interaction. Providers must build any AI system that converses directly with people so that it tells them they are dealing with AI. The only everyday exception is where that would already be obvious to a person who is "reasonably well-informed, observant and circumspect".
• Article 50(2), machine-readable marking. Providers of systems that generate synthetic audio, image, video or text must mark the outputs in a machine-readable format so they are detectable as artificially generated or manipulated. Systems that only assist with standard editing, or do not substantially alter the input, are excepted.
• Article 50(3), emotion recognition and biometric categorisation. Deployers must inform the people exposed to such systems. Few SaaS products sit here, so we leave it aside.
• Article 50(4), visible labels. Deployers must disclose deepfakes, and must disclose AI-generated or manipulated text "published with the purpose of informing the public on matters of public interest", unless the text has had human review or editorial control and a person holds editorial responsibility for it.
• Article 50(5), delivery. The information must be given "in a clear and distinguishable manner" at the latest at the first interaction or exposure, and must meet the applicable accessibility requirements.

Two Commission documents explain how to meet these duties. The guidelines on Article 50, first published on 20 July 2026 (the current text is dated 5 November 2026), interpret the whole article with worked examples. The Code of Practice on Transparency of AI-Generated Content, published on 10 June 2026, sets out concrete measures for Article 50(2), (4) and (5). Signing the code is voluntary; the obligations are not. The Commission's Q&A on Article 50 says signatories can rely on the code, while everyone else must show compliance through other adequate means. For Article 50(1), there is no code: you choose your own measures, and the guidelines describe what works.

National market surveillance authorities enforce Article 50. Under Article 99, fines reach up to 3% of total worldwide annual turnover or a fixed sum, whichever is higher. For small and medium-sized enterprises the lower of the two applies, and a new Article 99(6a), added by the Omnibus, extends that to small mid-caps.

The dates, including the 2 December change

Article 50 has applied since 2 August 2026, under Article 113. Some coverage describes the Digital Omnibus on AI as deferring the marking duty to 2 December 2026. The text is narrower than that. The Omnibus, Regulation (EU) 2026/1744, added a new Article 111(4): providers of generative systems placed on the market before 2 August 2026 must comply with Article 50(2) by 2 December 2026.

What that means for a product team:

• The chat notice was due on 2 August 2026. The guidelines say a system that is partly interactive and partly generative gets the transition only for marking; the Article 50(1) disclosure applied from 2 August.
• Only marking moves, and only for systems already on the market. A generative feature launched on or after 2 August 2026 must mark its outputs from launch.
• Nothing is relabelled backwards. Content generated and published before 2 August 2026 needs no retroactive mark or label. Text generated before that date but published after it does need a label, if it falls under Article 50(4).

Who carries which duty in a SaaS product

This is the question that decides your backlog. The guidelines give a direct answer for the common SaaS case: a company that offers a chatbot, image generator or AI agent on the EU market under its own name or trademark is the provider, and carries Article 50(1) and (2), whether it charges for it or not. A company that takes another provider's generative system, modifies it and puts it into service under its own name also becomes a provider of the new system.

So if your assistant runs on a model vendor's model but appears in your product under your brand, plan on being the provider. The code allows the marking itself to be applied upstream, by the model provider or by a specialist third party, but says this is without prejudice to your own responsibility for compliant marking.

Your customers become deployers when they use your product to publish deepfakes or public-interest text. The Article 50(4) label is then their duty, not yours. The code still asks something of you here, as an optional measure (Section 1, Measure 1.4): providers whose systems can produce such content are encouraged to offer an integrated option that lets deployers apply a perceptible label at the moment of generation. In practice, that means a labelling control in your export and publish flows.

Two edge cases matter. You can hold both roles, for example when your own marketing team publishes with your own generator. And the guidelines treat employees and contractors working under a company's authority as part of that company, not as separate deployers.

Patterns by surface

Chat and assistants: the first turn

The guidelines list what works for Article 50(1): a plain-language banner such as "You are interacting with an AI system", a first-turn greeting in which the assistant says it is AI, and, where the context calls for it, a persistent badge visible throughout the conversation. They recommend placing the disclosure close to the input and output field and using simple wording.

They also list what does not work on its own:

• a disclosure that lives only in terms and conditions, a URL or documentation;
• machine-readable marks users cannot see;
• vague labels such as a generic "assistant", or human-like representations that may mislead;
• a site-wide line such as "Services on this website use AI";
• a technical description such as "this system uses LLMs" that says nothing about what the system does.

The pattern we recommend: an "AI" badge on the assistant's avatar, a first message that says it is an AI and what it can and cannot do, and no human first name or stock photo. The assistant must also answer truthfully whenever someone asks whether it is a person. The guidelines require disclosure whenever the system is asked about its nature or a user seems confused about it. The guidelines say a single prominent notice before the first interaction is likely to suffice in most cases, but they expect reminders in riskier contexts: financial advice, insurance, legal help, health and complaints handling, and products used by children, older people or people with lower literacy. Our B2B chatbot UX guide covers the rest of the conversation design.

Two traps are specific to support products. If AI replies and human replies share one thread, the AI-generated replies need disclosure unless a human reviewed them and sent them as the main interlocutor. And when a person takes over from the bot, or the bot takes back over, say so in the thread.

The "obvious" exception is narrow. The guidelines say it should be read restrictively, and that general awareness that chatbots exist does not mean people recognise one in a given exchange. Their examples of obvious cases are tight: code-review assistants used only by professional developers, internal assistants for trained staff. Chatbots in help desks, where users may take replies for human ones, are given as an example where the duty applies. If your product reaches many customers' staff, you do not control who is trained. One line of text costs less than the argument.

AI agents that act for the user

Agents get the most specific guidance. Under the guidelines, an agent that books, corresponds, negotiates or buys on someone's behalf must disclose both that it is AI and on whose behalf it acts. Where the provider cannot predict whether the agent will meet a person, it should be built to disclose itself whenever that is reasonably likely. Agents should also disclose themselves to the person instructing them at key steps: authorisation, reporting and validation.

On screen, that means the agent's actions carry an "AI agent" marker in the activity log, the approval step names the agent as the actor, and outbound messages state the principal: "Sent by an AI agent on behalf of [person], [company]". The guidelines' own example is an email generated by an AI agent that carries an AI label at the top. Anything the agent writes or renders for people to read is also synthetic content that must be marked under Article 50(2). Its reasoning steps and web requests are not.

Generated text in documents and emails the user sends on

Here the two duties pull apart, and it is easy to over-apply one of them.

Machine-readable marking (Article 50(2), the provider). Summaries and rewrites that change style, structure or meaning are in scope. Grammar and spelling correction, minor stylistic polishing and translation are given as examples of standard editing that is not. Short outputs fall outside entirely: single words, captions, alt text, UI labels and source code. The code asks for signed metadata where a format can carry it, such as documents and other containerised text. Plain running text cannot carry metadata, so for it the code accepts an imperceptible watermark alone, and expects watermarking for any such text longer than 200 tokens.

Visible label (Article 50(4), the deployer). A visible label is required only when text is published to inform the public on matters of public interest. The guidelines say private professional correspondence and internal company communications are not published, and that advertising and product descriptions fall outside, unless they make claims related to, for example, health, consumer safety or sustainability. A listed company's AI-manipulated investor report on its website is one of their examples inside the scope.

So an email your user drafts with AI and sends to a client needs no visible AI label under Article 50(4). Your machine-readable marking duty as the provider still applies to it, unless it is a short output or the AI only did standard editing. Inside your product, though, mark what the AI drafted anyway: the person about to send it is the one deciding how much to check it. If your product publishes, through a help centre, a newsroom or a public report, give your customers a label control. For published text the code suggests placing the label above or at the top of the text, near the headline or in the colophon. You may label only the AI-generated part. For very short text, a contextual notice in the interface can do the job.

Images, video and audio

For generated media, the code asks signatory providers for at least two layers of machine-readable marking: digitally signed metadata and an imperceptible watermark. Fingerprinting or logging is an optional supplement and is not sufficient on its own. C2PA Content Credentials are one open standard for signed provenance metadata of this kind. We name it as an example of the method, not as the one you must use.

Deepfakes need a visible label from the deployer: content that resembles real people, objects, places, entities or events and would falsely appear authentic. The code's placement rules are specific. Put the icon where no other overlay sits, for example the top right corner. Show it at the start of a video, at intervals where possible and after breaks. Begin audio with a short spoken disclaimer, and add a visual label when a screen is present. Evidently artistic, creative, satirical or fictional works get a lighter regime, a disclosure that does not hamper enjoyment of the work.

Voice

For voice assistants and phone lines, the guidelines describe a spoken statement at the start ("This is an AI-powered assistant"), with periodic reminders in longer interactions, after interruptions and when the AI's role changes during the journey. Tones and earcons can help recognition, particularly for people with visual impairments, but the guidelines say they are not sufficient by themselves.

When a person edits AI output

For published public-interest text, human review removes the label duty only under two cumulative conditions. Someone with relevant knowledge must deliberately examine the substance, with fact-checking as a minimum. And a named person or organisation must hold editorial responsibility. The guidelines rule out spell-checks, automated review and cursory approval. Any substantive AI change made after sign-off voids the exception. The code asks signatory deployers to keep a policy that names who holds editorial responsibility and describes the review set-up, without documenting every individual text.

The machine-readable mark is a different matter. The guidelines say content that mixes AI output with human material still counts as synthetic. The code also commits signatory providers not to strip existing metadata marks from content their system transforms, and to forbid deliberate removal in their terms.

Inside the product, the useful move is to track authorship at the level of the passage, not the document. In our work with OmnyAI, AI-generated content was shown in purple and human-entered content in blue, and nothing the AI wrote reached the listing until a person chose it. The case study records Omny's view that users grew more conscious of their own use of the AI. That is the byline idea in practice: the label tells the reader who made this, so they know how much to check it.

The surface table

The EU icon

The Commission has published three EU icons for labelling AI-generated content, set out in Annex 1 of the code:

• a fully AI-generated icon ("AI" with "GENERATED"), for content with no human-created elements beyond prompting;
• a partially AI-modified icon ("AI" with "MODIFIED"), for human-made content partly changed with AI;
• a basic icon, for use with your own text label or with an interactive second layer.

Each comes in four colour variants: black, white, and both at 50% transparency. The Commission's page says using them is optional and does not by itself establish compliance. The code's design rule for any equivalent label is the capitalised acronym "AI" in English, unless national language law requires another language. The code reports that, in user testing across several member states, variants with a clear text label such as "modified" performed significantly better for noticeability and clarity. The code says a task force under it will explore an interactive second layer and develop an audio-only version of the icon.

The icons belong to Article 50(4): deepfakes and published text. There is no official icon for a chat notice. The guidelines do recommend standardised visual indicators across a provider's services, so using one consistent "AI" mark across your product, chat included, is the practical choice.

Where over-labelling backfires

The law asks for honesty, not for warnings everywhere. The guidelines say disclosures should be proportionate and should avoid habituation, naming "banner blindness" directly. Products that treat the label as a compliance sticker train users to stop reading it. Products that put it where the decision to trust is made keep the user's judgement switched on.

Do and don't, described in words:

• Do open the assistant with one sentence: it is an AI, it can draft and summarise, and figures should be checked before sending. Don't greet users as "Sarah from support" with a stock photo.
• Do put a small "AI draft" marker at the top of a generated passage, beside the text the person is about to rely on. Don't badge every autocompleted word or suggestion chip; single words and UI labels are outside the marking duty anyway.
• Do show the label once, persistently, beside the AI. Don't fire a modal that people must dismiss every session; a dismissed dialogue informs nobody.
• Do say what the AI did ("Summarised from 14 tickets"). Don't write "Powered by LLMs", which the guidelines say is not enough on its own.
• Do offer a label control in the publish flow, switched on when the content is generated and the destination is public. Don't rely on a line in your terms of service.
• Don't label grammar fixes and translations as if they were generated content. The guidelines class them as standard editing, and labelling them dilutes the labels that matter.

This is the core of our trust, control and recovery work: AI and human work marked apart in the same way everywhere, with the label travelling with the content into exports and emails.

Accessibility of the label

Article 50(5) requires the information to meet the applicable accessibility requirements. The guidelines say Article 50 adds no accessibility requirements of its own; it points to the rules you may already be under, the European Accessibility Act (Directive (EU) 2019/882) and the Web Accessibility Directive (Directive (EU) 2016/2102). If you already produce an accessibility conformance report, the label belongs in it; our VPAT guide covers how that report works.

The code's deployer measures and the icon page are concrete about it:

• give the icon an accessible name through alt text or an ARIA label that says the content is AI-generated or AI-modified;
• use high-contrast icons, and do not let colour carry the meaning on its own (the same principle as WCAG success criterion 1.4.1);
• keep a time-limited disclosure on screen long enough for people with cognitive or processing difficulties to read it;
• make any second layer reachable and navigable with assistive technology;
• for audio, add a visual or haptic cue where you can; for visual content, add an audio description or other alternative cue.

Where children may use the product, the guidelines expect notices that are child-friendly, age-appropriate and easy to understand.

Pre-launch checklist

Run this before any AI feature reaches EU users, and again when a feature changes role:

1. List every surface where AI interacts with a person or produces content: chat, agents, generated text, media, voice.
2. For each one, record whether you are the provider, your customer is the deployer, or both.
3. Write the first-turn notice in plain words, and test that the assistant answers truthfully when asked whether it is a person.
4. Remove human names and human photos from AI personas.
5. Decide where reminders are needed: sensitive domains, vulnerable users, long sessions, handovers between AI and a person.
6. Confirm that your agents name their principal in every outbound message and appear as the actor in logs and approvals.
7. Check that machine-readable marking is in place for every generated output in scope, and whether it is applied by you or upstream. If the feature was on the market before 2 August 2026, the deadline is 2 December 2026.
8. Exclude standard editing, translation, short outputs and code from your labels, on purpose and on record.
9. Give customers a label control wherever your product publishes text or media, and keep labels attached in exports.
10. Track authorship by passage, so a human edit is visible and an AI change after review is caught.
11. Check every label for an accessible name, contrast, timing and a non-colour cue.
12. Write down what each label means and where it appears; the code asks signatories for this kind of record and encourages publishing it.
13. Take the list to your counsel, who decides what applies to you.

If you want a structured pass over an AI feature before launch, our AI product UX readiness audit works through real tasks as each role that touches the result, and ends with a ranked fix list and questions for your compliance specialists.