Customers tell chatbots far more than you ask for. They paste order numbers, home addresses, complaints about a neighbour, the medication they take, the reason their payment failed. The moment a conversational AI goes live, it becomes one of your busiest personal-data systems — and under the GDPR you, not the model vendor, are responsible for it.
That sounds heavier than it is. A GDPR-ready chatbot comes down to a handful of decisions made before launch: who processes what, on which legal basis, where the data lives, how long logs are kept and what happens when something goes wrong. Get these right, and the same documentation answers your data protection officer, your enterprise customers’ procurement teams and the AI Act’s transparency rules in one go.
Why a chatbot is a GDPR project
Three properties make conversational AI different from a contact form:
- Free text. You cannot control what users type, so special categories of data (health, religion, ethnicity — Article 9 GDPR) can appear without being asked for.
- A long processor chain. A typical setup involves a chat widget, an orchestration layer, an LLM API, a vector database, your CRM or helpdesk, and logging or analytics. Each link can store data.
- Opaque reuse. Some AI vendors retain prompts for abuse monitoring or, on consumer tiers, for model training. If you don’t check, your customers’ data may end up somewhere your privacy notice never mentioned.
European companies know this. Among German businesses already using AI, 66% name data protection requirements and 45% the risk of data leaks as obstacles (Bitkom). A bot that can prove its data handling clears those objections faster than a slightly smarter bot that cannot.
Step 1: map the data flow
Before any legal analysis, draw the path of a single message:
- Widget or channel — website, WhatsApp, Telegram, email. Note that since 15 January 2026 the WhatsApp Business API no longer allows general-purpose AI assistants; company bots serving their own customers remain allowed (TechCrunch).
- Orchestration — a platform such as Botpress or Intercom, a self-hosted n8n instance, or custom code.
- Model — the LLM API, its region, and whether prompts are retained.
- Retrieval — the vector database and the documents indexed in it.
- Actions — CRM, order system, booking calendar.
- Logs and analytics — transcripts, traces, error tracking, dashboards.
For each box, note what personal data it receives, where it is hosted, and how long it keeps it. This map becomes the core of your record of processing (Article 30) and your DPIA.
Step 2: choose a legal basis per purpose
There is no single “legal basis for the chatbot”. Each purpose needs its own.
| Purpose | Typical legal basis (Art. 6 GDPR) | What to watch |
|---|---|---|
| Answering questions, processing an order or return | Contract or pre-contractual steps, Art. 6(1)(b) | Only data needed for the request |
| Order status, booking, account changes | Contract, Art. 6(1)(b) | Authenticate before revealing personal data |
| Reviewing transcripts to improve answers | Legitimate interest, Art. 6(1)(f) | Document the balancing test; pseudonymise |
| Marketing follow-up, newsletter sign-up in chat | Consent, Art. 6(1)(a) | Separate, unticked, provable |
| Health questions in a clinic bot | Plus an Art. 9(2) condition, usually explicit consent | Consider keeping clinical topics out of scope |
| Training a vendor’s model on your chats | Avoid | Switch off in the vendor settings and contract |
The cleanest design is purpose-limited: the bot answers, books and escalates, and it says so at the start of the conversation.
Step 3: the DPA and the sub-processor chain
Every vendor that processes conversations on your behalf is a processor, and Article 28 requires a written agreement (DPA). A good DPA with an AI vendor covers:
- processing only on your documented instructions — which should exclude training on your data;
- confidentiality of staff and appropriate security measures (Article 32);
- a list of sub-processors and your right to object to new ones;
- help with data subject requests and DPIAs;
- deletion or return of data at the end of the contract;
- breach notification without undue delay, so you can meet your own 72-hour deadline;
- audit rights or recognised certifications.
Ask every AI vendor the same five questions: Do you train on our data? How long do you retain prompts and outputs, and why? In which regions is data processed? Who are your sub-processors? How fast will you notify us of an incident? The answers belong in your vendor file — and they often decide which vendor you choose.
Step 4: data residency and international transfers
Sending personal data outside the European Economic Area requires a transfer basis under Chapter V GDPR. For US vendors this usually means certification under the EU–US Data Privacy Framework or standard contractual clauses combined with a transfer assessment. US voice and chat platforms are commonly used this way in Europe; it works, but it adds paperwork and a political risk that many buyers price in. In surveys reported from Deloitte, 77% of companies consider the country of origin of their AI vendor and 66% worry about dependence on foreign AI (DEV Community).
| Option | Transfer work | Quality and cost | Good fit |
|---|---|---|---|
| US model API via DPF or SCCs | Transfer assessment, vendor checks | Top models, pay per token | Low-sensitivity support, no special categories |
| Major vendor with EU processing region | Lower; confirm region in the contract | Top models, sometimes higher price | Most SMB support bots |
| Open-weight model (e.g. Mistral) hosted in the EU | None outside the EEA | Slightly lower quality, fixed infra cost | Sensitive data, regulated sectors |
| On-premises model | None | Highest effort | Strict sector rules, large volumes |
The orchestration layer matters too. The community edition of n8n can be self-hosted for free on an EU server (n8n), which keeps workflow data and credentials inside your infrastructure. For the trade-offs of running your own models, see private and on-prem LLMs for European companies.
Step 5: logs — keep what you need, delete the rest
You need logs: to debug wrong answers, to handle disputes (“your bot promised me a refund”), to detect abuse and, for high-risk systems under the AI Act, to keep automatically generated logs for at least six months. But the GDPR’s storage limitation principle (Article 5(1)(e)) means “keep everything forever” is not an option.
A retention schedule we often use as a starting point — to be adapted to your purposes and documented:
| Data | Suggested retention | Notes |
|---|---|---|
| Raw transcripts with personal data | 30–90 days | Long enough for quality review and complaints |
| Escalated conversations | Same as the related ticket in your CRM | Follow your existing customer-record rules |
| Pseudonymised traces (prompts, model, latency, cost) | 6–12 months | For evals, cost control and debugging |
| Aggregated analytics | Indefinitely | No personal data left |
| Security and access logs | Per your security policy | Protect them like production data |
Two techniques shrink the problem. Redaction before the model: mask emails, phone numbers, IBANs and order IDs before the prompt leaves your system, and re-insert them only where an action needs them. Separate observability: tracing tools such as Langfuse or Helicone, which strong AI teams use as standard (HouseofMVPs), can run in your own environment so traces never sit with yet another vendor.
Step 6: transparency and user rights
Your privacy notice must cover the chatbot (Articles 13 and 14): purposes, legal bases, recipients including AI vendors, transfers, retention and rights. At the start of the chat, show a short line with a link to it. Since 2 August 2026, the EU AI Act separately requires telling users they are talking to an AI system — one sentence can do both jobs. We explain the AI Act side in the EU AI Act guide for SMBs.
Plan for rights requests from day one:
- Access (Art. 15) and erasure (Art. 17) — can you find all conversations of one person across widget, logs and CRM? Link them to a customer ID.
- Objection (Art. 21) — honour it for legitimate-interest processing such as quality review.
- Automated decisions (Art. 22) — if the bot makes decisions with legal or similarly significant effects, for example refusing a refund or a credit, offer human review and explain the logic.
- Deadline — one month to respond (Art. 12(3)).
Step 7: security is part of compliance
Article 32 requires security appropriate to the risk, and the AI ecosystem has produced plenty of cautionary tales. A scan of 5,600 publicly deployed vibe-coded apps found more than 2,000 serious vulnerabilities, 400 exposed secrets and 175 personal-data leaks (SoftwareSeni). One AI chat app exposed 406 million records through a Firebase rule that allowed everything (Cloud Security Alliance).
Then there is prompt injection — instructions hidden in user messages or documents that make the model leak data or misuse tools. Even OpenAI concedes it may never be fully solved (Brandon Ta). The practical answer is architectural: give the bot the narrowest possible tools, enforce authorisation outside the model, never let it query databases freely, and test attacks before launch. More in prompt injection and agent security.
If personal data does leak, Article 33 gives you 72 hours to notify the supervisory authority. Have the playbook ready before launch, not after.
When you need a DPIA
Article 35 requires a data protection impact assessment when processing is likely to result in a high risk. For chatbots, typical triggers are new technology at scale, special categories of data, systematic monitoring, recorded calls and voice biometrics. In practice, a DPIA for a support bot is a compact document rather than a book: the data flow map, legal bases, risks (wrong answers, leaks, injection, transfers), and the measures against each. It doubles as the document enterprise customers ask for in due diligence.
Worked example: a support bot for an online shop
A webshop selling furniture in Germany and the Netherlands wants a bot that answers product questions, tracks orders and starts returns. Here is how the decisions above play out:
- Scope. Product questions use the public catalogue only — no personal data needed. Order tracking and returns require the customer to verify with order number and postcode before the bot reveals anything.
- Legal basis. Contract (Art. 6(1)(b)) for order and return handling; legitimate interest for reviewing a sample of transcripts to improve answers, documented in a short balancing test.
- Vendors. Bot orchestration on a self-hosted server in Germany, an LLM accessed through an EU processing region, the shop system and helpdesk already under DPAs. Training on shop data switched off by contract.
- Redaction. Names, addresses and phone numbers are masked before prompts reach the model; the order lookup happens in code, not in the model.
- Logs. Raw transcripts kept for 60 days, pseudonymised traces for a year, escalations stored with the helpdesk ticket.
- Transparency. First message, in German or Dutch depending on the shop version: “I’m the shop’s AI assistant. How we handle your data is explained in our privacy notice. Type ‘agent’ to reach a person.” — with the privacy notice linked.
Nothing in that list is exotic. It is design work done once, at the start, instead of retrofitting it under pressure when the first enterprise customer or data protection request arrives.
Typical mistakes
- Using consumer AI accounts for a business bot. Consumer terms often allow training on inputs and offer no DPA.
- No sub-processor overview. Your privacy notice names one vendor; in reality five touch the data.
- “Keep all logs, just in case.” Unlimited retention violates storage limitation and turns every breach into a large one.
- Letting the model decide who may see what. Authorisation must live in code, not in the prompt.
- Treating health data as an edge case. In clinics, insurance or HR it is the main case — design for it or scope it out.
- Forgetting the human route. Without escalation to a person, Article 22 and frustrated customers will catch up with you.
Conclusion
A GDPR-compliant chatbot is not a special product; it is an ordinary one built with discipline: a mapped data flow, a legal basis per purpose, DPAs with every processor, a deliberate choice of where data lives, a retention schedule, redaction before the model and a breach plan. These decisions cost days, not months, when they are made at the start — and they keep your options open, because data you control is data you can move. That is also the core of owning your AI and avoiding vendor lock-in.
Lotus Libre builds AI support and sales agents and the systems around them — EU hosting, redaction, logging and DPA-ready documentation included. If you want a second pair of eyes on your current bot or a planned one, book a free 15-minute audit.
This article is general information and not legal advice. For decisions about your specific situation, consult a qualified lawyer or your data protection officer.