Since 2 August 2026, a customer service chatbot in the EU must tell every customer at the start of the chat that it is an AI system. The Digital Omnibus gave this duty no grace period. The GDPR adds a retention period for transcripts, a privacy notice and a processor agreement. Done well, the visible part is the first line of the chat window.
This post is for the IT manager, CIO, informatiemanager or head of customer service at a 250 to 5,000 FTE organisation in the Netherlands or Flanders with a chatbot next to an existing ticketing system and ICT partner. Crux Digits builds the AI part and its evidence; your ICT partner keeps running what it runs.
What must a customer service chatbot tell customers under Article 50?
That they are talking to AI, stated clearly by the first interaction, under Article 50(1) and (5) of the AI Act.
The Commission guidelines on Article 50, whose content the Commission approved on 20 July 2026 (C(2026) 5054), name chatbots in customer support, complaints management and e-commerce as in scope. Rule-based quick replies and out-of-office messages are not AI systems in this sense.
The date did not move. Article 113, as amended by the Digital Omnibus, Regulation (EU) 2026/1744, keeps the general date of application at 2 August 2026, as the Commission's Article 50 FAQ confirms. The transitional period to 2 December 2026 covers only machine-readable marking under Article 50(2) for generative systems already on the market. The guidelines are explicit: a partly interactive, partly generative system may use it for marking only, and the disclosure applies from 2 August 2026. Our Digital Omnibus overview covers the dates that did move, and the Article 50 labelling post covers marking.
The regulators state the upside plainly. In their joint call of October 2025, the Autoriteit Persoonsgegevens (AP) and the Autoriteit Consument & Markt (ACM) name faster answers at any time of day as a real gain for customers. They ask for two things in return: say it is a machine, and keep a person reachable.
Who owes the disclosure: your chatbot vendor or you?
The provider owes Article 50(1), and if you have a chatbot built and run it under your own name, you are the provider.
The guidelines give this example: an organisation that develops a chatbot in-house and puts it into service under its own name is a provider. The definition in Article 3(3) includes systems you have had developed, so a bot a partner builds for you counts. Modify an existing system with new training data and run it under your name, and you are the provider of the new system.
Buy a SaaS chatbot and configure it, and the vendor is normally the provider. The design choices still sit with you: greeting, persona name, avatar and handover message, exactly where a compliant product can become a misleading deployment. Add the disclosure to your configuration review.
Fines for Article 50 breaches run to EUR 15 million or 3% of worldwide annual turnover, whichever is higher, under Article 99(4). The Omnibus added paragraph 6a: for small mid-caps under Commission Recommendation (EU) 2025/1099, the lower applies. The AP calls itself the intended supervisor of the AI Act in the Netherlands; the draft implementing act went to consultation on 20 April 2026.
What does a chatbot disclosure that works look like?
A plain first-turn message plus a persistent label near the input field, which is the combination the Commission guidelines recommend for text chat.
The guidelines list techniques that work: plain-language labels such as "You are interacting with an AI system", first-turn greetings, and persistent badges near the input field. They also list what fails when used alone: a disclosure only in the terms and conditions, a machine-readable mark nobody sees, a vague reference to an "assistant", a site-wide line such as "Services on this website use AI", and a technical statement like "this system uses LLMs". Human-like representations that may mislead are on the same list.
The AP and the ACM added a detail of their own: "typing" dots before a reply can suggest a person is typing. Their example has a customer passed from a human-sounding bot called Alex to a second bot, Anna, before reaching an employee. Both are design choices, easy to reverse.
An example of a first message that follows the guidelines' examples, to adapt to your own wording: "You are chatting with an AI system, not a person. It answers from our help pages and can make mistakes. Type 'colleague' at any time to reach our team. How we handle this chat: privacy statement." One line of copy and one link. It answers two problems the ACM's consumer research describes, not knowing whether it is a bot and not reaching a person, and carries the GDPR notice too.
For voice, the guidelines ask for a spoken statement at the start and reminders in longer calls. The ACM and the AP expected to adopt their own chatbot guideline in autumn 2026; we found no published version on 28 October 2026.
When is one notice at the start of the chat not enough?
In riskier contexts the guidelines expect reminders, and the bot must always disclose its nature when a customer asks whether it is a person.
One prominent notice is likely to suffice in most instances, per the guidelines. The exceptions: vulnerable users, emotionally sensitive conversations, and contexts with a higher risk of being misled, naming financial advice, insurance, legal assistance, health advice and complaints handling. An insurer's claims chat qualifies. There, repeat the label on a new topic and after every handover.
Three situations decide most implementations.
Hybrid replies. If agents use AI to draft a reply and then review and send it themselves, the guidelines treat that as indirect interaction, outside Article 50(1). If AI output reaches the customer directly inside a human-led conversation, those specific messages need disclosure. Show each message's real sender in the chat window and in the ticket.
Internal service desks. An internal assistant for trained, AI-literate staff, and the guidelines' example explicitly includes IT support, can fall under the exception for obvious interactions. The exception is read restrictively, so record why your audience qualifies. A service desk bot open to every employee, including colleagues with low digital skills, may not.
Emotion analysis. Article 50(3) adds a separate deployer duty for emotion recognition, which the AI Act defines as inferring emotions on the basis of biometric data. Sentiment scoring on typed messages falls outside that definition. Analysing a caller's voice falls inside it and is high-risk as well; for your own agents at work, the guidelines point to the prohibition in Article 5(1)(f).
How long may you keep chat transcripts?
As long as a stated purpose needs them and no longer: the GDPR sets no fixed term, so you choose one and record why.
The AP's page on retention says organisations set their own periods, must record the reasoning so they can account for it to the AP, and must state the periods in the privacy statement. Statutory duties, such as tax law, or a pending legal procedure can require keeping specific records longer.
A chatbot adds one twist: after a handover, the transcript lives in two systems, the bot platform and the ticket. Set retention in both, or the shorter term means little. Zendesk, for example, offers deletion schedules that delete archived tickets after a set period on its Team, Professional and Enterprise plans, with one active schedule per type, or up to 10 with the Advanced Data Privacy and Protection add-on.
An example split, with assumptions rather than a rule: conversations that became a ticket follow the ticket's retention; conversations the bot closed without a ticket get a short term, for instance 90 days, long enough to review answer quality; and question logs stripped of names, e-mail addresses and order numbers can stay for improving the knowledge base. Whatever terms you pick, the reasoning goes into your record of processing activities.
What belongs in the privacy notice and the processor agreement?
The privacy notice states the chat's purpose, legal basis and retention; the processor agreement binds the supplier to your instructions under Article 28 GDPR.
Customers must be informed before they share data. The AP explains that for data entered on a website, a clear reference to the online privacy statement is enough: the link in the first chat line. In the statement, add a chatbot section: purpose, legal basis, whether staff read transcripts, retention and the supplier.
The chatbot supplier processes customer data on your behalf, so you must conclude a processor agreement with it. The AP's recommendations of 11 November 2025 ask for concrete terms and grip on the whole supplier chain. For Flemish organisations, the Gegevensbeschermingsautoriteit (GBA) held in decision 137/2023 that the duty rests on controller and processor alike, and found a breach where the agreement was signed only after the processing had taken place.
Five fields we check in a chatbot processor agreement: the sub-processors, including the provider of the underlying AI system; whether transcripts train or improve the supplier's systems, and how to switch that off; retention and deletion of transcripts, logs and files, including at contract end; where processing happens and the transfer mechanism outside the EEA; and breach notification timing plus your audit right.
When is a DPIA the sensible choice for a customer service chatbot?
When the chatbot meets two or more of the nine DPIA criteria, which for a public chatbot at this scale is the normal case.
Neither the AP's list of 17 processing types that always require a DPIA nor the GBA's list names chatbots. Both regulators point to the nine criteria of the European privacy regulators and give the same rule of thumb: meet two and you should assume a DPIA is required (AP, GBA). A public chatbot at a 250 to 5,000 FTE organisation usually meets two already: innovative use of new technology and processing on a large scale.
Three design choices add criteria, and each is a reason to run the DPIA before go-live. The bot handles health, financial or other sensitive data, as at a health insurer, a care provider or a collections desk. Transcripts are used to profile customers or assess their behaviour, which the AP's list names under category 15, profiling. Or handover data is used to assess your own agents, which touches category 11, monitoring of employees.
With three data flows, chat, knowledge base and handover, a chatbot DPIA is short work, and it doubles as the design record your auditor will ask for. Our post on AI over SharePoint shows the same method for an internal system, and AI and the GDPR covers the baseline.
Where Crux Digits fits
For many teams the fastest route is off the shelf. SimplyBoost is our own product: an AI support agent that answers from your website, PDFs, FAQ and catalogue on website chat, WhatsApp, Instagram and Facebook Messenger. An account includes three AI agents. It hands a conversation to a person, or to Zendesk, Freshdesk, Gorgias or Slack, with the conversation attached, which is the human route the AP and the ACM ask for. An agent can run on logged-in portal pages and recognise users by verified email, and it replies in Dutch, French, German, Spanish and English. See simplyboost.io.
When the chatbot has to work inside your own systems, Crux Digits builds it alongside your ICT partner: an AI audit at €2,500, a Production-ready MVP at €20,000 and production from €50,000, excluding VAT, with the code handed over to you. There you are the provider under Article 50(1), so disclosure, handover and retention are part of the build and the documentation we deliver. Your ICT partner keeps running your infrastructure.
The custom route in detail: AI customer support agent.
Last updated: 28 October 2026.
Our AI Act Check (€950 fixed) gives you your risk classification, obligations and a concrete to-do list within one week, including what you can safely ignore.
See the AI Act Check →SimplyBoost, our own product, answers from your documents on website chat and WhatsApp. When the answer has to come from your own systems, we build that part.
AI customer service agent →
