A GDPR compliant AI chatbot has a lawful basis for each purpose it processes personal data for, collects only what it needs, deletes transcripts on a schedule, runs on providers bound by a data processing agreement, and keeps any transfer outside the EU on a valid legal footing. In October 2026 that is achievable with mainstream tools: OpenAI offers EU data residency for eligible API customers, AWS Bedrock and Azure keep inference inside EU geographies, Mistral hosts in the EU by default, and open models can run on your own servers. The model choice matters less than the retention settings, the contracts and what you log.
Chatbots are a GDPR problem because people type personal data into them freely: a divorce explained to a bank bot, symptoms typed into a booking assistant, a colleague's appraisal pasted into an internal tool.
This guide is written for teams in Germany, Switzerland and the UK. It covers lawful basis, minimisation, retention, DPAs and transfers, EU-hosted models, a DPIA outline, Swiss and UK notes, and a reference architecture. EU AI Act duties are covered separately in this AI governance framework guide, so they appear here only where they touch chatbot design.
Key Takeaways
- Set the lawful basis per purpose, not per bot. Answering a customer's question, improving the bot, training a model and sending marketing each need their own basis.
- Provider retention is part of your retention. OpenAI keeps API abuse monitoring logs for up to 30 days by default, so your "delete after 7 days" promise must account for it or use approved zero retention controls.
- The Data Privacy Framework is valid but contested. The General Court upheld it on 3 September 2025, and an appeal is pending at the Court of Justice, so keep standard contractual clauses as a fallback.
- EU hosting is now an easy default. OpenAI's Europe region covers the EEA and Switzerland; Bedrock's geographic inference profiles route within the EU; Anthropic's own API offers only US or global inference, so use its models through an EU cloud region instead.
- Germany, Switzerland and the UK each add something. German storage rules for the chat widget and works council rights for staff bots, personal fines under the Swiss FADP, and a mandatory complaints process under the UK's Data (Use and Access) Act.
What Makes an AI Chatbot GDPR Compliant?
Under the General Data Protection Regulation, the business that decides why and how the chatbot processes personal data is the controller. The chatbot platform, model provider and host are usually processors. Watch for vendors that claim independent controller rights for "service improvement", and remove them in the contract.
A compliant AI chatbot answers seven questions with evidence:
- Purpose and lawful basis: why is each kind of data processed, and under which basis in Article 6 (and Article 9 for sensitive data)?
- Minimisation: is the bot collecting and sending to the model only what the task needs?
- Transparency: are users told, before they type, who runs the bot, what happens to their data and that they are talking to an AI?
- Retention: how long are transcripts, logs, embeddings and backups kept, including on the provider's side?
- Rights: can you find, export, correct and delete one person's conversations?
- Processors and transfers: does every vendor have an Article 28 contract, and does every non-EEA transfer have a legal basis?
- Security and accountability: are access controls, logging, a DPIA and a breach process in place?
Article 83 allows fines of up to €20 million or 4 percent of worldwide annual turnover, whichever is higher, for breaches of the core principles and transfer rules.
Lawful Basis: One Purpose at a Time
The common mistake is one consent checkbox for everything. Consent is often the wrong basis for the core service, because it is not freely given when help depends on it.
| Purpose | Usual lawful basis | Notes |
|---|---|---|
| Answering the user's question or handling their request | Contract or steps before a contract (Article 6(1)(b)) | Covers what is necessary to deliver the service the user asked for |
| Security, fraud and abuse monitoring | Legitimate interests (Article 6(1)(f)) | Document a legitimate interests assessment |
| Quality review and analytics on transcripts | Legitimate interests | Pseudonymise first; offer an easy objection route |
| Training or fine-tuning a model on transcripts | Legitimate interests with a strong balancing test, or consent | The EDPB Opinion 28/2024 on AI models sets out the three-step test and what users can reasonably expect |
| Marketing follow-up from a chat | Consent | Also subject to ePrivacy rules for email and SMS |
| Health, religion, union membership and other special category data | An Article 9 condition, usually explicit consent | Better to design the bot not to ask for it and to redact it when users volunteer it |
| An internal assistant for employees | Legitimate interests or contract, rarely consent | Consent from employees is seldom free; see the German works council note below |
Be specific in the privacy notice: "We use your conversation to answer your question and keep it for 30 days for quality checks" beats a paragraph of general language.
Data Minimisation in Practice
Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary. For a chatbot, that translates into design choices:
- Ask for less. Do not request a date of birth or full address unless the task needs it. Verify identity through your existing login instead of in the chat.
- Redact before the model. Detect and mask emails, phone numbers, IBANs, card numbers and ID numbers before the prompt leaves your system, and restore them only where the response needs them.
- Scope retrieval. A retrieval chatbot should only fetch documents the user is allowed to see, and only the passages it needs. The design patterns for this are covered in this RAG chatbot guide.
- Separate identities from content. Store conversation text against a pseudonymous ID, and keep the mapping to the customer record in a different system with tighter access.
- Keep sensitive topics out of the bot's scope. Route medical, legal and financial hardship conversations to a person where you can.
Retention and Deletion
Retention has to cover every copy, not just the chat database. Article 5(1)(e) (storage limitation) and Article 17 (the right to erasure) apply to all of them.
| Data | Where it lives | Suggested default | Deletion method |
|---|---|---|---|
| Conversation transcripts | Your database | 30 to 90 days, shorter where possible | Scheduled job by conversation age |
| Model provider copies | Provider's systems | OpenAI: abuse monitoring logs up to 30 days by default; zero retention controls need approval | Contractual; choose zero or modified retention where offered |
| Application state at the provider | Stored responses, threads, files | Disable storage or set the shortest option | API delete calls plus provider retention |
| Embeddings and vector store | Vector database | Same as source documents | Delete vectors when the source is deleted |
| Application logs and traces | Logging platform | 14 to 30 days, without message text | Log retention policy |
| Backups | Backup storage | Rolling 30 to 35 days | Expire naturally; do not restore deleted data |
| Analytics and evaluation sets | Data warehouse | Pseudonymised or anonymised only | Purge on schedule |
Build the erasure path before launch: find a user's conversations by account or session, delete them from the database, vector store and logs, ask processors to delete stored state, and record it.
DPAs and Subprocessors
Every processor needs an Article 28 contract. For AI chatbot vendors and model providers, check these clauses specifically:
- Processing only on your instructions, with no use of your data to train the provider's general models.
- A subprocessor list with locations, and advance notice of changes with a right to object.
- Retention terms for prompts, outputs, files and abuse monitoring logs.
- Transfer mechanism for any non-EEA processing: adequacy, the Data Privacy Framework or standard contractual clauses.
- Security measures described concretely, plus audit rights or third-party reports.
- Assistance with rights requests, DPIAs and breaches, including a notification deadline short enough for you to meet the 72-hour rule in Article 33.
- Deletion or return of data at the end of the contract.
Mistral, for example, states that data is hosted in the EU by default, with a US endpoint available only if you choose it, and that some features may involve temporary transfers covered by standard contractual clauses. That level of detail is what to look for in any provider.
International Transfers and the EU-US Data Privacy Framework
Sending personal data from the EEA to a country without an adequacy decision is a restricted transfer under Chapter V. For US model providers, there are two main routes.
Route 1: the Data Privacy Framework (DPF). The European Commission adopted the EU-US adequacy decision on 10 July 2023. Transfers to US companies certified on the Data Privacy Framework list need no further transfer tool. On 3 September 2025, the EU General Court dismissed the challenge brought by French MP Philippe Latombe in Case T-553/23. Latombe appealed to the Court of Justice (Case C-703/25 P), and no ruling had been published at the time of writing.
Route 2: standard contractual clauses (SCCs) with a transfer impact assessment. These stay valid whatever happens to the DPF, which is why most providers include them in their DPA as well.
The practical rule: use the DPF where your provider is certified, keep SCCs as a fallback, and prefer EU processing for the most sensitive data. Safe Harbor and Privacy Shield were both struck down by the Court of Justice, which is why risk teams want the fallback.
| Data flow | Legal basis for the transfer |
|---|---|
| EU to a DPF-certified US provider | EU-US adequacy decision (DPF) |
| EU to a non-certified US provider | SCCs plus a transfer impact assessment |
| Switzerland to a certified US provider | Swiss-US DPF, in force since 15 September 2024 |
| UK to a certified US provider | UK Extension to the DPF (the "data bridge") |
| EU to the UK | EU adequacy decision for the UK, renewed on 19 December 2025, running until 27 December 2031 |
| Switzerland to the EU or EEA | Recognised as adequate under Swiss law |
EU-Hosted Model Options
| Option | Where inference runs | What to check |
|---|---|---|
| OpenAI API with data residency | Europe region covering the EEA and Switzerland, via a regional endpoint | Eligibility is confirmed through sales; models released from 5 March 2026 carry a 10 percent uplift |
| Azure OpenAI and Foundry models | EU Data Zone deployments process prompts within EU member nations, per Microsoft's Foundry data privacy page | Global deployments may process anywhere; choose Data Zone or regional |
| Amazon Bedrock | EU regions, or geographic cross-Region inference profiles that keep routing within the EU | Global profiles route worldwide for about 10 percent savings, so avoid them for EU-only data |
| Anthropic Claude | The first-party API's inference_geo setting offers "global" or "us" | For EU processing, use Claude through Bedrock or Google Cloud EU regions |
| Mistral | EU by default | Check feature-level transfers on its subprocessor list |
| Self-hosted open model | Your EU servers or EU cloud account | You become responsible for security, patching and logging; see this large language model development company page for build options |
For Swiss companies, EU processing is a transfer to a country Swiss law treats as adequate.
DPIA Outline for an AI Chatbot
Article 35 requires a data protection impact assessment where processing is likely to result in a high risk. A public-facing AI chatbot that handles free text from customers usually meets that bar, especially with new technology, sensitive topics or large scale. A practical outline:
- Description: purposes, data categories (including likely special category data typed by users), data subjects, systems, vendors and data flows.
- Necessity and proportionality: lawful basis per purpose, minimisation steps, retention periods, how users are informed and how they exercise rights.
- Risks to people: inaccurate answers about them, disclosure through prompt injection or misrouted retrieval, unexpected reuse for training, transfers, profiling, and users sharing sensitive data they later regret.
- Measures: redaction, EU hosting, retention controls, access controls, human handoff, output filters, red-team testing and incident response.
- Residual risk and sign-off: the data protection officer's advice, the decision, and whether prior consultation with the authority is needed.
- Review triggers: a new model, a new data source, a new market or a serious incident.
Prompt injection can make a bot reveal another user's data, and the controls in this guide to AI agent security map directly to the "measures" section.
Switzerland: FADP Notes
The revised Federal Act on Data Protection (FADP) has applied since 1 September 2023. Its logic is close to the GDPR, with differences that matter for chatbots:
- Personal fines. Criminal fines of up to CHF 250,000 can be imposed on the responsible individuals, not just the company, for wilful breaches such as failing to inform users or ignoring transfer rules.
- Impact assessments are required for high-risk processing, as under the GDPR.
- Transfers follow the Federal Council's list of adequate countries, which includes the EU and EEA, and certified US companies since 15 September 2024.
- Data breaches that are likely to lead to a high risk must be reported to the Federal Data Protection and Information Commissioner as soon as possible.
United Kingdom: UK GDPR and the Data (Use and Access) Act
The UK runs its own version of the GDPR alongside the Data Protection Act 2018. The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, and the ICO confirms that its provisions affecting data protection law and PECR are now in force.
For a chatbot, three points stand out:
- Complaints process. Organisations must have a process for handling data protection complaints, so add a route for this to the bot's privacy notice and support flow.
- Automated decisions. The Act reshapes the rules on solely automated decision-making. If your bot makes decisions with legal or similarly significant effects, such as rejecting an application, check the new safeguards and give people a way to reach a human.
- Transfers. UK to US transfers can use the UK Extension to the DPF, and EU to UK flows rest on the EU adequacy decision renewed until 27 December 2031.
The ICO's guidance on AI and data protection remains the most practical reference for fairness, accuracy and transparency in AI systems.
Germany: Three Extra Points
- The widget's storage. Storing or reading information on a user's device, such as a chat session ID in local storage, falls under section 25 of the TDDDG. Storage that is strictly necessary for the chat the user started is exempt from consent; analytics and marketing identifiers in the same widget are not.
- Regulator guidance. The German data protection authorities' joint guidance on AI and data protection (May 2024) sets out what they expect when organisations select and use AI applications, including LLM chatbots.
- Employee assistants. If an internal bot logs prompts in a way that could monitor staff behaviour or performance, the works council has co-determination rights. Agree logging scope and access in a works agreement before launch.
A GDPR Compliant AI Chatbot Architecture
A reference design that satisfies the points above has nine parts:
- Notice layer: a short message before the first input that names the controller, says it is an AI assistant, links the privacy notice and warns against sharing sensitive data. The EU AI Act's Article 50 also requires users to be told they are interacting with an AI system, which this layer covers.
- Consent manager for optional purposes only: marketing and training opt-ins, recorded with time and version.
- Gateway: authenticates sessions, applies rate limits and attaches a pseudonymous user ID.
- Redaction service: masks direct identifiers and flags special category data before any model call.
- Policy router: sends requests to an EU-region model endpoint, with no global routing.
- Retrieval layer with permission filters: returns only documents the user may see.
- Logging without content: records events, IDs and timings, not message text.
- Retention jobs: delete transcripts, vectors and logs on schedule and report completion.
- Rights tooling: an admin function to search, export and erase one person's data across all stores.
Worked Example: What EU Residency and Compliance Add to the Cost
Pixel Web Solutions does not publish fixed AI chatbot prices, so these are industry estimates.
Model cost. A support bot handles 20,000 conversations a month, with six turns each, 2,500 input tokens and 300 output tokens per turn, on a model priced at $2 input and $10 output per million tokens.
- Turns: 20,000 x 6 = 120,000
- Input: 120,000 x 2,500 = 300 million tokens x $2 = $600
- Output: 120,000 x 300 = 36 million tokens x $10 = $360
- Global processing: $960 a month
- With the 10 percent EU data residency uplift: $960 x 1.10 = $1,056 a month, an extra $96
Build cost. The compliance features in the architecture above (redaction, routing, retention jobs, rights tooling, content-free logging and the DPIA) typically add about 120 to 200 engineering hours to a chatbot build. At $40 to $100 an hour, that is $4,800 to $20,000 as an industry estimate.
Both are small next to rebuilding a bot after a failed security review.
Launch Checklist
- Lawful basis recorded for every purpose, with a legitimate interests assessment where used.
- Privacy notice and AI disclosure shown before the first message.
- Redaction live for direct identifiers and special category data.
- EU-region model endpoint configured, with global routing disabled.
- Provider retention set to the shortest available option, or zero retention approved.
- DPAs signed with every processor; subprocessor list reviewed.
- Transfer basis documented for every non-EEA flow, with SCCs as a fallback to the DPF.
- Retention jobs scheduled for transcripts, vectors, logs and analytics.
- Erasure and access requests tested end to end.
- DPIA completed and signed off by the data protection officer.
- Security testing done, including prompt injection and cross-user data leakage.
- Country extras covered: TDDDG storage rules and works council agreement in Germany, FADP notice in Switzerland, complaints process in the UK.
- A named owner for ongoing governance, with controls built through AI governance implementation.
How Pixel Web Solutions Can Help
Pixel Web Solutions builds AI chatbots for European and UK companies with EU-region models, redaction, retention controls and rights tooling designed in from the start. Its AI chatbot development services cover customer support, sales and internal assistants on OpenAI, Azure, Bedrock, Mistral or self-hosted open models, with the documentation a DPIA and an enterprise security review need. Custom engineering starts from $40 an hour. To review your chatbot's data flows or plan a compliant build, contact Pixel Web Solutions.
Frequently Asked Questions
Is ChatGPT GDPR compliant for business use?
The consumer app is not designed for business personal data. OpenAI's API and business products come with a DPA, do not train on API data by default and offer EU data residency for eligible customers. Compliance still depends on your lawful basis, retention, transparency and DPIA.
Which LLM provider is best for GDPR?
The best provider is one that signs an Article 28 DPA, processes in the EU, offers short or zero retention and lists its subprocessors. Mistral hosts in the EU by default; OpenAI, Azure and Bedrock offer EU processing options; Anthropic models are available in EU regions through Bedrock and Google Cloud.
Is a GDPR compliant LLM API possible with a US provider?
Yes. If the provider is certified under the Data Privacy Framework, transfers rest on the EU-US adequacy decision; otherwise standard contractual clauses apply. Choosing EU-region processing reduces transfer risk further.
Do I need consent to use an AI chatbot on my website?
Not for answering the user's own question, which usually rests on contract or legitimate interests. You need consent for marketing, often for training on conversations, and for non-essential device storage by the widget.
Do I need a DPIA for a chatbot?
Usually yes for public-facing AI chatbots that process free text at scale, because they involve new technology and can receive sensitive data. A DPIA is also strong evidence of accountability if a regulator asks questions.
How long can chatbot conversations be stored?
Only as long as needed for the stated purpose. Thirty to ninety days is common for support and quality review, with shorter periods where possible. Remember provider-side copies, logs, embeddings and backups.
Does GDPR apply to a Swiss or UK chatbot?
The EU GDPR applies when you offer services to people in the EU. Switzerland applies the FADP and the UK the UK GDPR, both close to the EU model with their own fines and transfer rules.
A GDPR compliant AI chatbot comes from a series of deliberate choices rather than a certified product: a lawful basis for each purpose, an EU-region model, short retention everywhere data lands, signed DPAs with a transfer fallback, and a DPIA that shows your working. Make those choices before launch and both regulators and enterprise buyers will find what they are looking for.
