Skip to content
← BlogComplianceAnalysis5 min read

Chatbot disclosure is now binding law. Here's the implementation checklist

Article 50 of the EU AI Act is enforceable from August 2, 2026. If you ship an AI chat feature, here's what to build this quarter — the punch list.

By Gabriel Lara, Developer Relations, Norbelys

Founder-reviewed ·How we research and correct articles

Article 50 of the EU AI Act is enforceable from August 2, 2026. If your product has a chatbot, an AI agent, or any surface where a user might reasonably think they’re talking to a person, this is a shippable feature, not a policy discussion. The legal breakdown is here if you need it for a compliance ticket. This is the version for whoever’s actually implementing it.

The rule in one sentence

If a system is designed for direct interaction with a person, the person has to know it’s AI — perceivably, in the interaction itself, before or at the first exchange. “Perceivably in the interaction” is the load-bearing phrase: your terms of service don’t count, a hidden watermark doesn’t count, and neither does a euphemism a user could reasonably read as human (“I’m Alex, happy to help!” with no AI label anywhere).

What to ship

Article 50 chatbot disclosure — implementation checklist

  1. Add a persistent visible marker on the chat surface

    A badge, icon, or label near the input/message area — "AI Assistant" or equivalent — visible for the whole session, not just on load.

  2. Make the first AI message state it's automated

    The opening message from the system should say plainly that it's an AI, in the same language the conversation is happening in. Don't rely on the UI badge alone to carry this.

  3. Never assign the AI a persona that implies humanity

    A first name and friendly tone are fine. A persona built to be indistinguishable from a human support agent, with no disclosure anywhere in reach, is the exact failure mode the rule targets.

  4. Handle handoff-to-human explicitly

    If a conversation escalates to a human agent, make that transition explicit in the transcript. Don't let a human silently take over an AI-labeled thread, or vice versa — both directions create the ambiguity Article 50 is written against.

  5. Separate the machine-readable and human-readable disclosures

    If you're also watermarking AI-generated content (images, audio, longer text) for provenance, treat that as a distinct requirement from the human-visible label. One doesn't substitute for the other.

  6. Localize the disclosure copy per deployment locale

    "You are chatting with an AI system" needs to actually be legible to the user in front of it — ship it through your existing i18n layer, not as an English-only string.

  7. Log that disclosure was shown, not just that it exists in code

    For an audit trail, capture that the disclosure rendered for the session (not just that the component exists in your codebase) — useful if a regulator or customer ever asks for evidence of compliance at a point in time.

What NOT to do (near-misses that still fail)

A minimal reference pattern

If you’re wiring this into an existing chat component, the shape is small enough to sketch in a few lines:

pseudocode — first-message disclosure
On session start, before any user input is required:$ renderPersistentBadge({ label: "AI Assistant", locale: session.locale })$ sendSystemMessage(t("disclosure.ai_notice"), { role: "assistant" })→ "You're chatting with an AI assistant. Ask for a human anytime."On handoff to a human agent mid-thread:$ sendSystemMessage(t("disclosure.human_handoff"), { role: "system" })→ "You're now talking with [agent name], a human team member."

The specifics of your stack will vary; the structural requirement doesn’t — a rendered, localized, session-start disclosure plus an explicit marker for any human/AI transition.

Scope check: does this actually apply to your feature

It applies if a reasonable user could be uncertain whether they’re talking to a person. It doesn’t apply where AI involvement is obvious from context — a code-completion tool inside an IDE, or a clearly-labeled “generate with AI” button on a form field, isn’t the kind of ambiguous direct interaction Article 50 targets. The gray zone is anything conversational: support widgets, sales chat, AI agents operating an inbox or replying to messages on a company’s behalf. If your product touches that gray zone and reaches EU users, build the checklist above now rather than after a support ticket asks whether your bot is required to say so.

Where does an AI-assisted cold-email or reply-drafting agent fall? Mostly outside the gray zone, and the reason is structural rather than a judgment call. An agent calling Norbelys’s API or MCP server to draft copy, personalize a sequence, or triage a reply doesn’t get to talk to a recipient directly — a campaign built that way sits in draft state until a separate, explicit launch call sends it, and an inbound reply surfaces in the unibox for a human to answer, not something the agent replies to on its own. That’s not Article 50 compliance by accident; it’s the difference between an agent that assembles an outbound message and one that conducts a live conversation a recipient could mistake for talking to a person.

If you’re building or evaluating outreach tooling with an AI layer in the loop — drafting, personalizing, or replying — Norbelys’s API and MCP surface stays out of your way here by design: it’s infrastructure for sending and replying, not a chat interface presenting itself as a person, so Article 50’s chatbot-specific disclosure duty is squarely a decision for whatever agent or UI you build on top, not something the sending layer needs to solve for you.