An AI chatbot collects personal data from the very first message. People type their names, email addresses, order numbers and sometimes health or money details into the box. Those messages then go to an LLM provider, get stored in a database and are often pushed on to a CRM or help desk.
If your users are in the UK, all of that falls under the UK GDPR. Most of the compliance work is the client's job (lawful basis, privacy notice, contracts), but a lot of it only works if the developer builds it in. Here is the checklist we use, mapped to what it means in code. It is based on the Information Commissioner's Office (ICO) guidance and is general information, not legal advice.
1. Say it's an AI, and link the privacy notice, in the widget itself
The ICO's guidance on AI and transparency says people must be told, at the time you collect their data, your purposes, how long you keep it and who you share it with. The widget is where collection happens, so:
- Show a short line in the chat window such as "You're chatting with an AI assistant. How we use your messages", linking to a privacy-notice section that names the AI provider.
- Give people a visible "Talk to a person" option from the first message, not only after the bot fails.
2. Collect less, on purpose
Under the data minimisation principle, personal data must be adequate, relevant and limited to what's necessary. In practice:
- Put rules in the system prompt telling the bot not to ask for card numbers, passwords or health details, and to send people to a secure channel instead.
- Add a server-side filter that spots obvious card numbers or similar patterns and masks them before you log or forward the message. Don't rely on the prompt alone.
- Only ask for the contact fields the follow-up actually needs.
// Very rough example: mask likely card numbers before storing a transcript
const maskCards = (text) =>
text.replace(/\b(?:\d[ -]?){13,19}\b/g, '[card number removed]');
3. Give transcripts an expiry date
The storage limitation principle says you can't keep personal data for longer than you need it, and the ICO expects you to review and erase or anonymise data on a schedule. Build:
- a
retain_until(or similar) column on conversation records and a scheduled job that deletes or anonymises expired rows; - deletion that also reaches copies: vector stores, analytics events, help-desk tickets and log files;
- a way to find and export or delete one person's conversations for access and erasure requests. That means storing a user or contact key against each conversation from the start.
4. Know what the LLM provider does with prompts
The provider processing your users' messages is normally a processor, and Article 28 requires a written contract (usually the provider's data processing addendum). Your job as the developer is to make sure the integration matches what that contract and the provider's settings promise:
- OpenAI's platform docs say API data hasn't been used for training since 1 March 2023 unless you opt in, and that abuse-monitoring logs may be kept for up to 30 days by default.
- Google's Gemini API terms say content sent to unpaid services may be used to improve products and read by human reviewers. They also say only paid services may be used when offering apps to users in the UK.
So: use paid or API tiers for anything customer-facing, switch off optional data-sharing settings, and write down what you chose so the client can include it in their records.
5. Flag the international transfer
Most LLM APIs process data outside the UK. When your client sends personal data to a separate organisation abroad, it's a restricted transfer. It must be covered by adequacy regulations, appropriate safeguards (such as the UK IDTA or the UK Addendum, usually with a transfer risk assessment) or an exception. You don't sign these, but you should tell the client which provider, which region and which company they're contracting with. Where a provider offers regional processing, make it a config option rather than hard-coding it.
6. Help the client decide on a DPIA
A data protection impact assessment is required when processing is likely to be high risk. The ICO's list includes innovative technology such as AI combined with other risk factors, like large-scale processing or vulnerable people, and recommends doing one if in doubt. Bots that touch health, finance or children are strong candidates. A short architecture diagram showing data flows, providers and retention makes the DPIA much easier to write.
7. Don't let the bot make "significant decisions" on its own
Most website bots answer questions. If yours decides something with a legal or similarly significant effect, such as approving credit, the automated decision-making rules apply. Since the Data (Use and Access) Act 2025 these sit in Articles 22A to 22D of the UK GDPR, and the safeguards include letting people get information about the decision, make representations, get human intervention and contest the result. In code, that means designing the agent to recommend and having a person decide, with an audit log.
8. Secure it like any other app that holds personal data
- Encrypt in transit and restrict, log and review access to transcripts.
- Use individual staff logins with MFA on the chatbot dashboard.
- Red-team the prompt: make sure users can't extract the system prompt, other people's data or internal endpoints.
- Give any tools the bot can call the narrowest permissions possible, using a dedicated, limited API key rather than an admin token.
- Hand over to a person with the conversation history, so the customer doesn't have to repeat themselves.
FAQ
Does a website chatbot need consent?
Not necessarily. Each purpose needs a lawful basis. Answering enquiries can often rely on legitimate interests or contract, while things like adding someone to a mailing list usually need consent.
Can I use a US-based LLM API for UK users?
Yes, with a processor contract and a valid transfer mechanism for the restricted transfer.
Is a DPIA mandatory for every chatbot?
No. It's required where processing is likely to be high risk, but the ICO recommends doing one if you're unsure.
If you're scoping a chatbot for a UK client and want a second opinion on the architecture, our team builds GDPR-aware AI chatbots for UK businesses.
Originally published on the Dzimark blog.
Top comments (0)