GDPR compliant chatbot: what it really takes

Nearly every vendor puts “GDPR compliant” on its home page. So do we. But a badge a vendor awards itself doesn’t tell you much. Whether a GDPR compliant chatbot actually runs cleanly on your website comes down to a handful of concrete points. The vendor handles some of them, you handle the rest. This post walks through them one by one and says who is responsible for each.

One thing up front: this is not legal advice. We describe how our product works and which questions you should be asking. For your specific case, talk to your data protection officer or a lawyer.

Two roles: you are the controller, we are the processor

The most important point first, because everything else follows from it. When you put a chatbot on your website, you are the controller. You decide what the bot is for, what it knows and whom it answers. We, as the vendor, are your processor under Article 28 GDPR. We only process your visitors’ data on your instructions.

Which means no software can “make you GDPR compliant”. It can give you the building blocks. Whether you use them properly is up to you.

The data processing agreement (DPA)

You can’t do without one. With Mignuti Chatbot you accept it when you set up your account. We log when you accepted which version, and you can ask us for a countersigned PDF. The full text is on our DPA page.

What it covers, and what to look for with any vendor:

• Instructions: the vendor only processes what you set out in the contract and your settings.
• Technical and organisational measures: described concretely, not just “state of the art”.
• Breach notification: with us, without undue delay and no later than 48 hours after we become aware.
• Help with data subject rights: which tools the vendor gives you.
• Deletion at the end of the contract: with a deadline.
• No training: we don’t train AI models on your data or your visitors’ data, and we only use model providers that are contractually barred from doing so.

Sub-processors: who else sees the data

An AI chatbot is never just one company. Behind it there are servers, a language model, a search service, an email service. Each of these is a sub-processor and belongs on a public list. Ours is on the sub-processors page. The main ones:

• netcup GmbH, Germany: servers for the database, files, sign-in and the processing itself. No managed database provider.
• Anthropic PBC, USA: the language model that writes the answers.
• OpenAI, USA: embeddings for semantic search, meaning text turned into number vectors.
• Microsoft (Azure OpenAI), EU: the fallback model if the main one fails.
• Stripe, Cloudflare, Resend: billing, delivery of the widget, and email.

We announce new sub-processors at least 30 days in advance, and you can object on substantial data protection grounds.

International transfers: the part many vendors skip

This is where AI chatbots get uncomfortable, to be honest. The capable language models almost all come from US companies. With us too, chat messages go to Anthropic in the USA for the answer and to OpenAI in the USA for search.

What that means:

• Servers in Germany do not mean everything stays in the EU. The database and files sit with netcup in Germany. The model call itself leaves the EU.
• The legal basis is standard contractual clauses. Transfers to Anthropic and OpenAI rely on the EU standard contractual clauses 2021/914 (Article 46(2)(c) GDPR). Neither provider is certified under the EU-US Data Privacy Framework. If someone tells you otherwise, ask them to show it.
• We redact first. Before a message goes to the language model, we replace recognisable personal data using rules: email addresses, phone numbers, IBANs, card, ID and tax numbers, IP addresses. Street addresses and names with a title are caught by patterns. What it can’t do: a bare name without “Mr” or “Ms” in front of it slips through. Redaction lowers the risk; it is not a substitute for a legal basis.

If your rules don’t allow any US provider at all, you can connect your own language model per project. We’ll cover that in a separate post next week.

Consent in the widget

Our widget stores a random session ID in the browser so the conversation survives a page change. For storing that in the browser, we ask for consent (under Germany’s TDDDG, which implements the ePrivacy rules). By default the widget therefore starts no session and writes nothing to the browser until the visitor has agreed.

You have two options:

1. The widget asks. Before the first chat it shows a consent button and links to your privacy policy.
2. Your cookie banner asks. You connect the consent in your banner to the widget. The documentation shows how.

Which legal basis you rely on for actually answering the question is your decision as controller. On our own website we base the answer on our legitimate interest in providing product information. That is our assessment for our case, not a template for yours.

Retention and deletion

A chat log that sits around forever is a risk with no upside. We use fixed periods, applied automatically every day:

• Messages: 90 days, then the content is anonymised. Figures remain, the text is gone.
• Session data: we only store IP address and browser identifier as a hash anyway, and these go after 90 days too.
• Log of security-relevant events: 2 years, 7 years where compliance requires it.

Shorter is always possible: you can delete individual conversations yourself at any time.

Access and erasure requests

If a visitor asks what you hold about them, or wants it deleted, you need to be able to act. You have:

• “Delete my conversation” in the widget: visitors delete their own chat, with no account and no request to you.
• Export: download your organisation’s data as a ZIP of JSON and CSV files.
• Deleting individual conversations in the dashboard.
• Deleting the whole organisation: within 30 days, except invoice data you’re legally required to keep.

If a request from one of your visitors reaches us directly, we pass it on to you rather than answering it ourselves. You’re the controller.

What you have to do yourself

This is the part no vendor can take off your hands:

• Update your privacy policy. Visitors need to know that a chatbot is running, what data it processes, who receives it and that data goes to the USA (Article 13 GDPR). You enter the address of your policy in the platform, and the widget links to it.
• Choose a legal basis and add the processing to your record of processing activities.
• Check your knowledge base. If your PDFs or pages contain personal data about third parties, the bot may answer questions about it. Only upload what you’re allowed to process.
• Don’t plan for special categories. Under the DPA, health data and the like are not part of the processing. If your bot runs for a medical practice, word the greeting so nobody types in their test results.
• Don’t target children. The widget isn’t meant to address people under 16.
• Secure your own integrations. If you forward requests by webhook to your CRM or an automation tool, you need a separate DPA with that service.
• Don’t hide the AI notice. The widget shows it permanently anyway, and it can’t be switched off. What Article 50 of the AI Act requires is covered in AI chatbots and AI Act Article 50.

Checklist for a GDPR compliant chatbot

Run through this before the bot goes live:

• DPA with the vendor in place
• Sub-processor list read; international transfers and their basis understood
• Legal basis for the answers decided
• Consent before the chat set up, in the widget or through your cookie banner
• Privacy policy updated for the chatbot and linked in the widget
• Retention periods checked and added to your record of processing
• Process for access and erasure requests agreed
• Knowledge base checked for personal data about third parties
• Greeting asks visitors not to share sensitive data

Honestly

An AI chatbot where no data at all leaves the EU doesn’t exist today with the big language models, not without extra work on your side. What does exist: a vendor that tells you openly where the data goes, names the legal basis, redacts first, keeps retention short and gives you the tools for access and erasure.

That’s how we want to run Mignuti Chatbot. How the data flows in detail is on our trust page. If your data protection officer has questions, send them over. We’d rather answer them before you sign than after.