Short answer: if your product has a chatbot or conversational assistant and you have EU users, then under Article 50(1) of the EU AI Act, yes — you generally have to make sure users know they're interacting with an AI. This applies from 2 August 2026. This article explains the rule, its one exception, and what a compliant disclosure actually looks like. It's compliance tooling and documentation, not legal advice.
What Article 50(1) actually says
Providers of AI systems that are intended to interact directly with people must ensure the systems are designed so that users are informed that they are interacting with an AI system — unless this is obvious from the point of view of a reasonably well-informed, observant and circumspect person, taking into account the circumstances and context.
Two things matter in that sentence. First, the duty is on the provider of the system. Second, there's an exception for when AI interaction is obvious from context — and it's narrower than most teams hope.
"But I just use the OpenAI API"
A lot of teams assume that because the model comes from OpenAI, Anthropic or Google, the disclosure duty is the model provider's problem. It isn't. When you embed a general-purpose model into your product, you're regulated based on the intended purpose of your system. If your app presents a chat interface to end users, your app is the thing that interacts with people — so the disclosure obligation attaches to you.
When is it "obvious from context"?
This exception exists, but lean on it carefully. It's meant for situations where no reasonable person could be confused — not for situations where you'd simply prefer not to add a notice.
- A tool literally labelled "AI Assistant" in an AI product may make the interaction obvious.
- A branded support chat that opens with a human-sounding greeting and no other signal is not obviously AI — this is exactly the case the rule targets.
- Voice assistants are a grey area: a synthetic voice may or may not be obvious depending on how human it sounds.
If you're unsure whether the exception applies, the safe move is to disclose. A small notice costs you nothing; getting the judgement wrong costs you the exemption.
What a compliant disclosure looks like
The law doesn't prescribe exact wording, but the spirit is clear: the information must reach the user, at the right moment, in a way they'll actually notice.
Good practice:
- Place it at the point of interaction. A line before or at the start of the chat — not on a separate legal page.
- Keep it plain. "You're chatting with an AI assistant" beats a paragraph of legalese.
- Make it perceivable. Adequate contrast, readable size, and — for accessibility — announced to assistive technology (an ARIA live region or status role).
- Keep it persistent enough. A notice the user can dismiss is fine, as long as it was clearly shown.
Bad practice: burying "this service may use artificial intelligence" in paragraph 14 of your terms of service. That doesn't inform the user at the moment of interaction.
Accessibility and cookies
Two details teams often miss:
- Accessibility. The disclosure has to be perceivable by everyone, which means it needs to work with screen readers and meet contrast requirements. A notice that only sighted users can see isn't reaching all your users.
- No tracking required. Disclosing AI interaction doesn't require a cookie or any personal data. A good disclosure widget is cookie-free and stores nothing about the individual user.
Voice assistants and multimodal interfaces
Text chat is the clearest case, but 50(1) isn't limited to it. A voice assistant that speaks in a convincingly human voice raises the same question: would a reasonable user know they're talking to an AI? If the voice is obviously synthetic, the interaction may be self-evident; if it's engineered to sound like a specific person or an indistinguishable human, disclosure becomes more important, not less. The same logic extends to avatars and video agents. The rule follows the substance of the interaction, not the modality.
Multiple languages
If you serve users across the EU, your disclosure should be understandable to them. A notice only in English shown to a French-speaking user arguably hasn't informed that user. Practically, this means detecting the user's language and showing the disclosure in it — the same way you'd localise any other user-facing copy. A disclosure the user can't read isn't a disclosure.
What about "AI-powered" marketing copy?
A subtle trap: teams sometimes assume that because they market the product as "AI-powered" on the landing page, the in-product disclosure is redundant. It usually isn't. The landing page reaches prospects; the disclosure duty is about the person *in the interaction*. Someone who arrived via a shared link and started chatting never saw your marketing. Put the notice where the interaction happens.
Frequently asked questions
Is a one-time notice enough, or does it need to persist? The law requires that the user is informed — it doesn't mandate a permanent, undismissable banner. A clear notice shown at the start of the interaction, which the user can acknowledge and dismiss, generally satisfies the spirit of the rule. Re-show it when the context materially changes.
Do we need consent? 50(1) is about *information*, not consent. You're telling the user they're interacting with AI; you're not asking permission. That's why it needs no cookie and no personal data.
Our chatbot hands off to a human — what then? Disclose the AI portion. If a human takes over, that's a change in context; a well-designed notice reflects who (or what) the user is currently talking to.
Record when you disclosed
Disclosure is only half the job; being able to *prove* you disclosed is the other half. Regulators and enterprise customers increasingly ask not just "do you disclose AI use?" but "since when, and how consistently?". If your disclosure notice went live on a specific date and has been shown ever since, that's a strong, verifiable answer. If you can only say "we think it's been there a while", that's weaker.
The lightweight way to handle this is to keep an append-only log: a dated entry each time the notice is enabled, changed, or shown, that no one can quietly edit after the fact. It turns a subjective claim ("we're transparent") into an objective record. This is exactly why a disclosure tool that also logs impressions and configuration changes is more useful than a hand-rolled banner — the banner discloses, but it doesn't remember.
How DiscloseKit handles this
The DiscloseKit disclosure widget is built for exactly Article 50(1): a Shadow-DOM notice under 15 KB with no dependencies, five placement variants (floating badge, top/bottom banner, inline chip, pre-chat notice), three languages that auto-select from the browser, full keyboard and screen-reader support, and no cookies. You configure it once, paste one script tag, and every disclosure it shows is recorded in an append-only evidence log — so if anyone ever asks whether and when you disclosed, you have dated proof.
Not sure whether 50(1) applies to your specific setup? Run the free two-minute check.