AI chatbot GDPR: planning data flows, notices and deletion properly

A contact form has required fields, a submit button and a clear moment when data leaves the browser. A chat window has none of that. Visitors write the way they talk: “I’m Ms Meier, my heating pipe has been leaking since yesterday, please call me back on this number.” A single sentence contains a name, a phone number and a request tied to where she lives.

In this scenario, a trades business has built a chatbot prototype. It answers questions about services and takes appointment requests. Functionally it is convincing, but when asked where the conversations are stored, all it gets is a shrug. The provider is based somewhere, the model comes from yet another company, and the privacy policy does not mention the chat.

This starting picture is common. It does not arise from negligence, but because during development a chatbot looks like a feature and only later like data processing. The study shows how to reverse that order. It is a guideline for planning and for conversations with your data protection adviser, expressly not legal advice and no substitute for reviewing your individual case.

The first question is: do visitors know they are writing to a machine? A friendly name and a photo are enough for someone to assume it is an employee. The second: where do the inputs go? Between the browser and the answer there are often three stations, each with its own servers and its own rules.

The third question concerns duration. Many chat tools store histories by default and without limit, because that is handy for analysis. Without a conscious decision, an archive of personal statements grows that nobody asked for. The fourth question is the most uncomfortable: what do you do when someone wants their data deleted and you do not know which conversation it is in?

On top of that comes a failure pattern that occurs more often in everyday use than the big data leak: out of helpfulness, the bot asks for more than it needs. Someone asking about opening hours does not have to give an address. Someone leaving a callback request does not need to describe their medical history, which can easily happen at practices. The more open the input, the wider the spread of what arrives.

Before talking about contracts, a simple picture of the data flow is worthwhile. A message starts in the visitor’s browser, goes to the chatbot provider’s server, from there to the interface of a language model, and back again. For appointment requests or callbacks, a fourth station is added: a calendar, a CRM or a mailbox to which the data is passed on.

Every station answers the same questions. Who operates it, in which country are the servers, is the message stored, is it used to improve models? The last question is especially important because providers differ here. With business interfaces, many providers contractually exclude use for training; with consumer offerings, this is often different. This must be evident from the contract documents, not from an assumption.

An example shows how easily stations are overlooked. The chat itself runs with a provider in the EU, but the notification about a new callback is sent by email through another service, which contains the message verbatim. Suddenly the same sentence sits in two places, with two different retention periods. Such side paths go unnoticed when you look only at the chat system.

A sheet of paper is enough for this inventory. We draw the stations, add the operator, location, storage and purpose for each, and mark where personal data actually occurs. Often it turns out that a tool sees more than expected, such as an analytics script that reads along, or a log that stores messages in plain text.

The easy route would be to rely on the chatbot provider’s privacy page. But it describes their view, not yours. You are responsible for processing on your website, even if you buy in the technology. The provider is generally a service provider processing on your behalf, and under generally recognised principles that requires a data processing agreement.

We would therefore proceed in three steps. First, clarify the roles: who is the controller, who is the processor, and are there sub-processors, such as the operator of the model? Second, check whether the data processing agreement covers the actual chain, including location and sub-processors. Third, assess whether data is transferred to countries outside the EU and on what basis.

There are alternatives. A self-hosted model keeps data in your own data centre but requires operation, updates and security on your side, which rarely pays off for small businesses. A provider with servers in the EU reduces questions about transfers but is not automatically privacy-compliant. The choice is a trade-off between effort, quality of answers and control, and it should be justified in writing so that it remains traceable later.

A third way is not to let the data arise in the first place. The less the bot asks, the smaller every question about contracts and retention period becomes. This attitude of data minimisation is a generally recognised principle and the most effective lever in the whole concept.

The notice about the AI belongs before the first word. As a rough guideline: anyone talking to an AI system should be able to tell, at the latest at the start of the conversation. The European AI Act takes up this idea with transparency obligations. Which obligations apply to your chatbot specifically and from when, you should clarify with your legal adviser. Technically, the notice makes sense anyway, because it sets realistic expectations.

The greeting can do both: “I’m the digital assistant of [business] and an AI. I answer questions about services and appointments. Please do not write any sensitive information here, such as health data, account numbers or passwords.” Two sentences, one link to the privacy information. That is shorter than any wall of pop-ups and more likely to be read.

The input itself can be guided. Instead of one open text field for everything, the bot leads visitors through steps: choose the request, name a preferred time, and only at the end ask for contact details in separate fields. Structured fields have an advantage that free text does not offer. They can be validated, stored separately and deleted selectively, whereas a name somewhere in the middle of a paragraph is hardly findable.

A stricter line applies to practices and other areas with particularly sensitive information. There, the bot should visibly answer only organisational questions and, when complaints or symptoms are described, kindly point to the phone or an appointment. This is less a question of technology than of defining the bot’s tasks, and it belongs in the bot’s instructions before launch.

The technical implementation begins where corners are often cut: the history configuration. We check whether the provider offers an adjustable retention period, whether histories can be deleted automatically and whether individual conversations can be found by an identifier. If one of these features is missing, that is not a detail but a selection criterion for the provider.

The chat widget is loaded only after consent if it establishes connections to the provider’s servers and, for example, transmits the IP address. Whether consent is needed or another legal basis applies depends on the setup and belongs in the legal review. Technically it means: the chat does not load automatically on page load, but behind a click or a prompt. As a side effect, the load time decreases.

Logs deserve their own attention. In addition to the history, web servers, error monitoring and analytics tools often store data in which messages or identifiers may appear. We check whether chat content appears in plain text in error messages, email forwards or webhooks, and shorten or mask it where possible. Hand-offs to the calendar or CRM also carry only the fields needed there.

Deletion needs a defined route. In practice, an identifier per conversation has proven its worth, carried along when handing off to the downstream system. That way, for a request, the conversation in the chat system and the associated entry in the calendar or CRM can be found. In addition, automatic deadlines are set after which histories disappear, even if nobody thinks of it.

The most common special case is unsolicited disclosure. A visitor describes their illness at length, the separation from their partner or their debts, although the question was only about an appointment. The bot cannot prevent this, but it can react calmly: briefly acknowledge, not ask follow-up questions, point to the appropriate contact route. A bot that eagerly presses for more makes the situation worse.

A special feature are conversations that the bot aborts or does not understand. Visitors then repeat their details, often at greater length and more personally than before. Here an early, friendly handover to a human helps, before someone explains their situation for the third time. That is good service and data minimisation at once.

The second case concerns minors and third parties. Someone asking for an appointment for their mother passes on data of another person. In such conversations the bot should ask only for the bare minimum and not infer further persons from the history. A blanket age check is not reliably feasible in a chat, so what helps most is an offering that visibly addresses adults.

Another case is attachments. As soon as visitors can upload photos or documents, such as a photo of the damage or a letter, the volume of data grows considerably, and images often show people, licence plates or addresses. We would leave uploads out in the first step and instead refer to a separate route with its own information and short retention.

Third, the request for access or deletion. When someone gets in touch, they want to know what is stored about them. Without an identifier or contact detail in the conversation, this cannot be answered, and that is not a flaw. One should not retroactively collect attributes just to be able to assign a conversation. The request also requires an identity check so that unauthorised persons do not request histories.

A fourth case is prompt injection, the attempt to get the bot, through inputs, to disclose internal instructions or other people’s data. This becomes relevant to privacy when the bot has access to customer data. That is why, when in doubt, it gets none. Knowledge base and conversation data stay separate, and the bot never sees more than the current conversation.

A clean concept reduces risks; it does not eliminate them. It makes decisions traceable: you can explain which data arises, why, where it is stored and when it disappears. Whether a specific construction is legally sufficient is ultimately decided by your data protection adviser or data protection officer. A concept of this kind cannot give an assurance of legal compliance, and we do not give one either.

Progress can be measured by things that can be verified. Is there a contract for every service provider involved? Does the privacy policy match the actual processing? Do deletion deadlines run automatically, and can that be shown on a test conversation by spot check? How many conversations contain information the bot should not have asked for at all? The latter can be observed in a sample of anonymised histories over a few weeks.

There is also a business benefit that cannot be quantified but can be described. Visitors who learn in advance what they are talking to and what happens to their information probably abandon conversations less often. That is an expectation, not a measurement, and whether it holds true is shown by abandonment rates and follow-up questions in your chat, compared before and after the adjustment. Figures for this would have to come from your own business.

Another checkpoint is consistency. If the privacy policy claims a retention period that the system does not keep, that is worse than a long but honest one. We therefore reconcile text and configuration, not just once before launch, but with every change to the chat.

It cannot be guaranteed that nothing unexpected will ever happen. Visitors type what they like, providers change terms, models get new features. That is why the concept includes a regular review, for example twice a year and with every change of provider or model.

First: privacy in a chatbot is first of all a design task. Whoever builds the dialogues so that little personal data arises has less to protect, explain and delete. That also reduces the effort for all later steps. Second: documentation should be created in parallel with configuration. A note with the date, who set what and why is worth more later than any retroactive reconstruction.

Third: notice texts are product copy. They should be written in the business’s own language, short and concrete, without legalese in the chat window. The detailed information belongs in the privacy policy and is linked there. We gladly test the texts on people who do not know the project and ask what they believe happens with their inputs.

Fourth: staff are part of it. Whoever handles callbacks from the chat should know how long they may keep the data, where it does not belong and how to pass on a deletion request. A deletion route nobody knows works only on paper. Fifth: a chatbot changes with its knowledge base. Every new feature, such as appointment booking or document upload, requires a brief reassessment of the data flow.

A common misconception to finish: more notices do not mean more protection. A banner nobody reads does not replace data minimisation, and consent does not replace the question of whether the processing is necessary. What is effective is what shrinks the processing, not what merely announces it.

A website chatbot can relieve enquiries and help visitors faster. In doing so it processes statements that visitors type believing they are having a conversation. This difference from a form is the core of the task. Whoever knows the data path, has clarified roles and contracts, sets the notice about the AI and defines retention and deletion periods has answered the essential questions before anyone asks them.

The next step is small: draw which stations a message passes through in your chat, and note what you know about the location, storage and contract of each station. The gaps are the topics for your data protection adviser. We are happy to help with the technical side of this inventory and with drafting notice texts and dialogues.

To be honest about it: the legal assessment stays with you and your adviser. We deliver technology that can be reviewed and documentation that answers questions instead of raising new ones. That saves time in every further conversation.

For small businesses the effort is manageable if it comes early. An inventory of the data flow, a draft of the notice texts and the configuration of the deadlines can be prepared in a few working days. It gets expensive when a live chat with hundreds of conversations has to be put in order retroactively. The timeline below shows one possible sequence.