Chatbots and the EU AI Act

Chatbots and the EU AI Act: Practical Article 50 Transparency Guidance

Chatbots are one of the clearest use cases under Article 50 of the EU AI Act. From 2 August 2026, providers of AI systems intended to interact directly with people must ensure users are informed they are interacting with an AI system, unless this is obvious from the circumstances and context of use.

This page delivers operational advice on UI placement, disclosure wording examples, evidence routines, and the provider/deployer split so teams can prepare workflows, logging, and notices that address real buyer and user expectations. It focuses on what actually works across website widgets, voice bots, in-app assistants, and support escalations.[1][2]

Law status (May 2026) Current law: Article 50 transparency obligations for interactive AI systems apply from 2 August 2026. The voluntary Code of Practice on marking and labelling of AI-generated content is at second-draft stage (published March 2026) and remains voluntary even after finalisation. No obligations are in force today. This page reflects the Regulation text and official EU timelines; proposed changes under the Digital Omnibus are labeled separately where relevant. Always verify against primary sources.[3]

Users should know when they are interacting with AI unless that is obvious from the point of view of a reasonably well-informed, observant and circumspect person, taking into account the circumstances and the context of use. The goal is to reduce deception, build trust, and let people make informed decisions about the information or advice they receive.

Wording, timing, accessibility, and proof all matter. Vague phrases such as “powered by AI” are often insufficient; clearer statements like “This is an AI chatbot. My responses are generated automatically and may contain errors. For critical matters, please request a human agent” perform better in practice.

Key operational priorities:

• Timing: Deliver the notice at the earliest reasonable point — typically the header of the chat widget, the first system message, or the opening of a voice interaction.
• Clarity and accessibility: Use plain language, sufficient contrast, screen-reader compatible text, and multilingual support based on user locale or preference.
• Evidence routines: Maintain version-controlled records of notice text, placement screenshots (with timestamps), UI version history, and logs showing the notice was active for live sessions. These artifacts demonstrate that the system was designed and developed with the obligation in mind.
• Obviousness test: If your branding and interface already make it unmistakably clear (e.g., a large persistent “AI Assistant” label plus robot icon with no human photo or name), an explicit notice may not be required. Most teams choose to add an explicit notice anyway to reduce risk and support consistent evidence collection.[2]

See the full operational breakdown in our guide to Article 50 transparency obligations explained.

Three common real-world examples illustrate the range:

• A support bot that answers customer questions on a retail website.
• A voice bot handling inbound customer service calls.
• An internal employee assistant used at scale for HR and policy queries.

In each case the core obligation is the same, but implementation details (visual, auditory, logging) differ by channel.

The EU AI Act maintains a clear distinction between providers and deployers. Blurring these roles creates gaps in accountability and evidence.

• Provider: The entity that develops or places the AI system (the chatbot) on the market or puts it into service. This is usually the organisation that builds or heavily customises the conversational interface, integrates the model, and controls the user-facing design. Providers are responsible for designing and developing the system so that the transparency notice obligation can be met (Article 50(1)). If you use a third-party foundational model via API and then create the chatbot experience, you are typically the provider of that specific AI system.

• Deployer: The organisation or individual using the finished AI system in a production environment. A company that simply integrates a pre-built chatbot widget from a vendor into its own site without substantial modification is more likely acting as a deployer. Deployers must use the system in accordance with instructions and, in some transparency contexts, ensure end users receive required information.

In typical chatbot stacks:

• The model provider (e.g., a general-purpose AI model maker) supplies the underlying intelligence and may have separate GPAI obligations.
• The chatbot system provider controls the prompt engineering, conversation flow, UI layer, and notice delivery mechanism. This party owns the primary Article 50(1) design responsibility.
• The deployer (e.g., an enterprise customer) controls branding, placement on their domain, escalation paths to human agents, and day-to-day monitoring. They often own the practical “notice experience” because they control where and how the widget appears.

Practical tip: Document the split in your internal responsibility matrix and in contracts with vendors. The party that controls the UI almost always ends up owning the evidence package for notice placement and wording. If you are a deployer using a third-party model, request evidence from your provider that the underlying system was designed with Article 50 in mind, then layer your own UI-level notice and logging.[3]

The second draft of the Code of Practice (March 2026) emphasises cooperation across the value chain for generative outputs; see the update summary at Article 50 transparency code second draft: what matters now.

Effective implementation goes beyond adding a line of text. Focus on entry-point placement, fallback channels, voice interfaces, mobile UI, multilingual support, and screenshot logging.

Entry-point placement: Show the notice in the persistent header of the chat window, as the very first message from the bot, or both. For long conversations, consider a subtle recurring indicator (e.g., small “AI” badge on every bot message).

Fallback channels: If the primary interface fails to display the notice (edge cases, embedded views, API-only access), provide it via accompanying email, onboarding materials, or a linked transparency statement.

Voice interfaces: Deliver a clear spoken disclosure at the start of the interaction: “Hello. This call is being handled by a voice AI assistant. I can help with general questions, but I may make mistakes. Would you like to continue or speak to a human agent?” Offer the ability to repeat the disclosure. Record metadata that the disclosure was played.

Mobile UI: Use prominent banners or modal overlays on small screens. Ensure the notice does not disappear behind keyboards or get truncated. Test with real devices and assistive technologies.

Multilingual support: Detect browser or account language and serve the notice in the user’s preferred language. Maintain parallel versions of the wording and keep all translations in your evidence repository.

Screenshot logging and evidence: Automate periodic captures of the live interface showing the notice in context. Pair these with Git commits for the frontend code, changelog entries for notice text changes, and anonymised session logs confirming the notice appeared. These routines turn a legal obligation into auditable workflow artifacts.

Example wording patterns (adapt and test):

• “This is an AI-powered chatbot. Responses are generated automatically and are not guaranteed to be accurate or complete. Important decisions should be reviewed by a human.”
• “You are chatting with an artificial intelligence assistant. I do not have personal experiences or real-time knowledge beyond my training data.”

For generative outputs that accompany the chat (images, summarised reports), consider machine-readable marking where the Code of Practice recommendations apply once finalised.[1]

Most implementation gaps appear in four areas:

• Footer-only notices: Placing disclosure only in page footers or legal pages fails the “early and clear” test for interactive systems. Users may never see it before engaging.
• Unclear wording: Phrases such as “may involve AI” or generic “tech-powered” language do not clearly communicate that the user is interacting with an AI system rather than a human.
• No version history or artifact capture: Teams launch a notice but cannot later prove what exact text and placement were live on a given date. Screenshot logging and Git-based versioning are essential.
• No escalation for human handoff or artifact retention: Users who become frustrated with AI responses need an obvious path to a human. Few teams log the notice alongside conversation transcripts or capture how the interface appeared at the time of the interaction.

These misses create evidence gaps when internal audits or regulator questions arise. Addressing them early turns transparency into a repeatable operational process rather than a one-time legal checkbox.

• Map your chatbot stack and document provider vs deployer responsibilities in writing.
• Draft and version-control notice wording for each supported language and channel.
• Implement entry-point placement and test for obviousness with representative users.
• Set up automated or scheduled screenshot logging tied to UI releases.
• Define human-escalation paths and ensure the notice references them.
• Create a central evidence repository linking notice versions, screenshots, logs, and responsibility matrices.
• Review the latest Code of Practice draft and decide whether voluntary measures add value for your generative outputs.
• Schedule a quarterly review of notice effectiveness and UI changes.

Does every chatbot need a giant disclaimer block? No. The obligation is to inform users they are interacting with an AI system in a clear and accessible format. A concise, well-placed notice is usually sufficient. The key is whether a reasonably observant user would understand the nature of the interaction early enough. Test and document your choice.

Who is responsible for the notice if the bot uses a third-party model? The provider of the AI system (typically the organisation that integrates the model, builds the conversation logic, and controls the UI) carries the Article 50(1) design-and-development obligation. Deployers are responsible for using the system according to instructions and maintaining the notice in their specific deployment. Document the split and request appropriate evidence from upstream providers.

How should notices work for voice? Deliver a clear verbal disclosure at the very beginning of the interaction and make it repeatable on request. Log that the disclosure occurred (e.g., via metadata). Offer an immediate option to transfer to a human. This mirrors the “clear and accessible” requirement in an audio-only context.

Do screenshots count as evidence? Yes, when combined with version control, timestamps, and process documentation. Screenshots of the live interface showing the notice, paired with release notes and session logs, help demonstrate that the system was designed to meet the obligation. They are not a complete compliance package on their own but form a practical part of a broader evidence routine.

Use the free **Article 50 Disclosure Generator** to create, version, and export notices tailored to different channels and languages.

See a completed evidence package in the **chatbot transparency sample report** — it shows exactly what a practical audit-ready artifact set looks like.

For deeper reading, explore the Article 50 transparency obligations explained or the latest Code of Practice developments.

Sources (primary official references used):

• EUR-Lex Regulation (EU) 2024/1689, Article 50 and Article 113.
• AI Act Service Desk timeline and Article 50 helper pages.
• European Commission transparency FAQ and second draft Code of Practice announcement (March 2026).

All legal statements are anchored to these materials. This page is for operational readiness and does not constitute legal advice.