EU AI Act Chatbot Disclosure: An Article 50 Operations Checklist

The EU AI Act chatbot disclosure question stopped being a future-planning exercise on 2 August 2026. But adding “this is an AI” somewhere in a help centre is not an operating plan. A customer may enter through a web link, a QR code, WhatsApp, Instagram, Messenger or voice; resume an old thread; change language; or move between AI and a person. Each path can pass or fail independently.

The legal text also gets compressed too aggressively in search results. Article 50 contains several different transparency duties. Paragraph 1 concerns AI systems designed to interact directly with natural persons. Paragraph 2 concerns machine-readable marking of synthetic outputs. Paragraphs 3 and 4 address other situations, including emotion or biometric categorisation and deepfakes. Treating them as one generic “AI label” creates bad implementation decisions.

This guide turns the direct-interaction duty into a practical customer-operations checklist. It is operational guidance, not legal advice. Your organisation should map its actual role, system and jurisdiction with qualified counsel.

What Article 50(1) actually requires

Article 50(1) says providers must ensure that AI systems intended to interact directly with natural persons are designed and developed so people are informed that they are interacting with AI, unless that is obvious from the circumstances and context to a reasonably well-informed, observant and circumspect person.

Paragraph 5 adds delivery requirements: the information must be clear and distinguishable, arrive no later than the first interaction or exposure, and meet applicable accessibility requirements. The European Commission’s Article 50 FAQ says the obligations apply from 2 August 2026.

Two cautions matter. First, Article 50(1) names providers. A business deploying a third-party model should not assume either that it is automatically the provider or that the model vendor carries every customer-facing responsibility. Map the actual system, branding, modifications and contractual roles with counsel. Second, the “obvious” exception is not a licence to rely on a bot name, an icon or a customer’s technical sophistication. If there is doubt, explicit disclosure is the safer operating choice.

Separate disclosure from output marking

The easiest deadline error is to merge paragraphs 1 and 2. The Commission FAQ describes a limited grace period until 2 December 2026 for the Article 50(2) machine-readable marking obligation for certain systems placed on the market before 2 August. That grace period does not postpone the Article 50(1) duty to inform a person in a direct AI interaction.

For a customer-service team, keep separate workstreams:

• Interaction disclosure: does the person know from the first interaction that the conversational counterpart is AI?
• Synthetic-output marking: does a provider have the technical marking and detection measures required for covered generated content?
• Special transparency cases: are emotion recognition, biometric categorisation, deepfakes or public-interest text involved?

One journey can trigger more than one workstream, but one banner cannot be assumed to satisfy all of them. Record the paragraph, system and responsible owner for each control.

Run a four-part scope test

The Commission FAQ frames the Article 50(1) assessment around four conditions. Turn them into an inventory review:

1. Is it an AI system? Do not classify a feature by marketing name alone. Record the system and version being used.
2. Was it designed for direct exchange? A real two-way conversation is different from a form that merely collects data or a deterministic acknowledgement.
3. Is the interaction direct? Identify whether AI communicates with the person without a human intermediary.
4. Is the other party a natural person? Separate customer-facing journeys from machine-to-machine traffic.

Build the inventory by journey, not only by vendor. “Customer chatbot” is too broad. A sales qualifier, order-status assistant, appointment agent and internal drafting tool may have different facts. For each journey, record channel, entry points, supported languages, AI function, owner, provider/deployer analysis, first machine response and escalation path.

This scope record is an operational aid, not a legal conclusion. Its value is that counsel, product and operations review the same concrete interaction instead of debating an abstract chatbot.

Design the first-interaction disclosure

Write the shortest sentence that says what the user needs to know. For example: “You are chatting with an AI assistant. You can ask for a person at any time.” The first sentence addresses identity; the second is a service design choice, not wording mandated by Article 50(1).

Good disclosure copy is:

• visible or audible with the first AI interaction, not buried in terms;
• clear in the language of the conversation;
• distinguishable from promotional copy and routine greeting text;
• usable with the channel’s accessibility features;
• accurate about whether and how a person can take over.

Do not write “virtual assistant” if users could reasonably read it as a human job title. Do not promise “instant human help” unless staffing and routing can deliver it. A knowledge-grounded AI setup can control what the assistant answers, but disclosure copy and escalation remain explicit operating decisions.

If a thread can resume after days or switch from human back to AI, decide whether to repeat the disclosure. Article 50(5) sets the latest point at the first interaction; it does not prescribe every repeat. Repeating after a material mode change is a defensible clarity practice, but label it as your control design rather than as quoted law.

Build a channel test matrix

Test the real journey, not a design mock-up. A compact evidence matrix should contain:

• Channel and entry path — Exact link, QR destination, ad entry or inbound route
• First AI response — Timestamp and customer-visible capture
• Disclosure — Exact visible or audible wording and placement
• Language and accessibility — Locale, reading order, screen-reader or voice behaviour where applicable
• Resume and mode switch — What happens in an old thread and after human or AI takeover
• Human request — Route, owner, acceptance and customer acknowledgement
• Release — System version, copy version, tester and date

Run it for every supported language and meaningful entry path. Check short screens, notification previews, voice playback, slow connections and failed handoffs. A screenshot is useful, but it is not sufficient if audio, accessibility or routing behaviour is part of the journey.

Store evidence with a named owner and review date. This is a recommended assurance practice, not a claim that Article 50(1) itself mandates this exact table.

Preserve human handoff and change control

A disclosure can be legally relevant and still create a poor customer experience. If it says a person is available, the operating system needs a real queue, ownership rule and acceptance signal. DripTell’s Team Inbox keeps conversation ownership, status, notes and context visible, while automation workflows can route or assign work and pause automation when a person takes over.

Keep the message mode visible internally. Operators should know whether the last customer-facing message came from AI, a deterministic workflow or a person. When control changes, preserve the conversation history and explain the transition to the customer in plain language.

Treat any change to the model, prompt, knowledge source, channel integration, greeting, language or escalation rule as a release. Re-run the affected rows of the evidence matrix. A disclosure tested on the website does not prove that a WhatsApp deep link or a voice entry point behaves correctly.

Worked example: an appointment request on WhatsApp

A customer opens a WhatsApp conversation from an appointment link. The first response says: “You are chatting with an AI assistant. I can help collect appointment details, or you can ask for a person.” It then asks for service type and preferred day.

The team tests four paths. In the standard path, the disclosure and first question appear together in the customer’s language. In a resumed thread, the assistant repeats the identity statement because the last interaction was with a person. When the customer types “agent,” automation stops, the shared inbox assigns an owner and the customer receives an honest acknowledgement. When no agent is available, the copy gives a real response window rather than claiming an instant transfer.

The AI may qualify the request from approved knowledge, but it does not invent live availability. A person or connected source confirms the slot. The evidence record contains the entry link, first-response capture, language, accessibility check, handoff timestamps and release version.

This example is not a legal safe harbour. It shows how identity, scope, truthful service promises and operational ownership fit together.

Put disclosure into the operating system

Start with the highest-volume customer-facing AI journey. Name the owner, map every entry path, run the four-part scope test, approve one clear disclosure for each language, and execute the evidence matrix. Fix failures before expanding to another channel.

Then create a small release gate: no model, prompt, greeting, channel or routing change goes live until the first interaction and human-request paths pass again. Review failed handoffs, missing disclosures and customer confusion as operating incidents, not merely copy defects.

DripTell does not determine your legal role or guarantee compliance. It can support the practical layer: grounded answers, visible ownership, controlled routing and a continuous conversation when AI hands work to a person. If your audit finds fragmented entry paths or unowned handoffs, contact DripTell to map the smallest reliable control loop.