Is an AI Chatbot GDPR Compliant? The Real Checklist
OS
Oskar
·6 min read
A chatbot that collects a name, an email address, or just logs what someone typed is processing personal data, and GDPR applies to it the same way it applies to a contact form or a CRM. Whether that specific installation is compliant depends on decisions made after that fact: who counts as the controller, where the messages actually get processed, what's written into the vendor contract, and how long a conversation sits in a database afterward. None of that is automatic. No chatbot is GDPR compliant out of the box, regardless of what the vendor's landing page implies.
Frequently asked questions
Related Posts
Most articles on this topic stop at consent banners and a link to the privacy policy. That covers the visible layer. It skips the part that actually determines your exposure: what happens to the message the second a visitor hits send.
Does GDPR apply to a chat widget at all?
Yes, and it applies before anyone types their name. An IP address, a session ID, a device fingerprint used to reopen a conversation later, these already count as personal data under Article 4. A widget doesn't need a signup form to trigger GDPR. It triggers the moment it logs a visitor's message and can, even indirectly, connect that message back to a person.
Who's the controller, who's the processor
Your business is the controller. You decide why the chatbot exists on your site and what happens to what it collects, so you carry the legal responsibility, not the software vendor. The chatbot platform is a processor, acting on your instructions under a contract. Article 28 makes that contract, the Data Processing Agreement, mandatory before you connect a processor to personal data, not optional paperwork you sign after launch if a customer asks.
If your chatbot vendor calls out to a separate LLM API to generate answers, that model provider is usually a sub-processor. Their name should appear in your vendor's sub-processor list, and their own retention and transfer terms become part of your risk, even though you never signed anything with them directly.
Where the question actually goes when someone hits send
This is the part most GDPR-and-chatbots guides gloss over. When a visitor asks your chatbot a question, the text of that question, sometimes including a name, an address, or a service request they typed straight into the box, gets sent to a model API to generate the reply. If that API runs on OpenAI's or Anthropic's standard infrastructure, the message leaves the EU. That's a transfer to a third country under GDPR Chapter V, and it's layered on top of the US CLOUD Act, which can compel a US company to hand over data regardless of what Standard Contractual Clauses say on paper.
This isn't automatically illegal. SCCs are a recognized transfer mechanism, and some providers also rely on the EU-US Data Privacy Framework. But the details differ by provider in ways that matter to a Datenschutzbeauftragter, and almost no chatbot vendor puts them on the pricing page:
EU hosting availability. Azure OpenAI offers an EU-region processing option. Anthropic doesn't offer EU hosting on its standard API tiers. Whether your vendor even uses the EU-capable route, instead of the cheaper default, is a question worth asking directly.
The model provider's own retention window. Both OpenAI and Anthropic retain API inputs and outputs for around 30 days by default for abuse monitoring, on top of whatever your chatbot vendor stores in its own database. Two retention clocks, not one, and most privacy policies only mention the vendor's.
Training on your data. Neither provider trains its models on API traffic by default, which is different from their consumer chat products. Confirm your vendor is actually calling the API tier and not routing through a consumer-grade integration to save money.
What actually has to be in the vendor's DPA
"Do you have a DPA" is the wrong question, because the answer is almost always yes. What matters is what's in it. This is the list AmueAI's own team gets asked by Handwerk clients during onboarding, and it holds up against any vendor, not just us:
A named country or region for processing, not "in accordance with applicable law."
A sub-processor list that includes the LLM provider by name, kept current, not a promise to disclose one on request.
A retention period stated as a number of days, not "as long as necessary."
A named transfer mechanism (SCCs, the Data Privacy Framework, or EU-only processing) if any sub-processor sits outside the EU.
A breach notification timeline, and a stated process for a visitor's deletion or access request, not just yours.
How long conversation data should actually be kept
There's no fixed legal number for chatbot conversations. GDPR's storage limitation principle just requires that retention match a stated purpose, and that's exactly where most default configurations fail: indefinite retention because nobody set a limit, not because a limit wasn't required. A support handoff needs recent history, typically weeks, not years. Using conversations to improve a knowledge base needs separate, explicit consent, and shouldn't ride along on the same retention clock as support logs by default.
A reasonable default for most SMB support use cases sits between 30 and 90 days, long enough to review a bad answer and correct the underlying document, short enough that it isn't a growing liability sitting in a database nobody looks at again.
What the widget itself has to tell visitors
Two separate disclosure obligations sit on top of each other here, and it's worth keeping them apart. GDPR's transparency principle expects a short, visible notice before or at the start of a chat, not a privacy policy buried three clicks away. Article 50 of the EU AI Act, which became enforceable in August 2026, separately requires telling a visitor they're talking to an AI system when that isn't already obvious from context. In practice both are satisfied by the same sentence: something like "You're chatting with an AI assistant trained on [company]'s own information" shown before the first reply, with a link to the full privacy notice next to it. No banner needed, just visible text.
A 15-minute check you can run today
Whether you're evaluating a new chatbot or auditing one you already run, this takes less time than the sales call that got you into it:
Open the vendor's DPA and search for the word "country." If it isn't there, ask for the exhibit that names one.
Check the retention section for an actual number of days. "As long as necessary" is not a number.
Open the widget on your own site and see if it discloses it's an AI assistant before the first reply, not just in a footer link.
Confirm the widget's own consent handling is separate from your cookie banner tool. Chat consent and analytics consent are not the same checkbox.
Ask the vendor how a visitor requests their conversation be deleted, and time how long it takes them to answer.
AmueAI is built by a DACH-based team, with consent and disclosure decisions made in the product from the signup flow onward rather than added later, and that's the honest reason we get asked these questions less often than some competitors. It isn't a reason to skip the checklist. Run it against us the same way you'd run it against anyone else.
Before your next chatbot vendor call, ask two questions and write down the answers: which country actually processes the messages, and how many days a conversation sits in the database before it's gone. If either answer is a shrug or a link to a marketing page, that's the real answer.
AI Agents
Rule-Based vs RAG Chatbot: How to Actually Decide
Most rule-based vs RAG chatbot guides skip cost and setup time entirely. Here's a concrete test using your last 100 support questions, what each option actually costs a small business, and when a RAG chatbot like AmueAI beats a decision tree.
