How to Build a GDPR-Compliant Chatbot on Your Documents (UK GDPR Checklist)

To build a GDPR chatbot in the UK, you need to know which personal data reaches the bot, justify each use under the UK GDPR, bind every supplier with a processor contract, keep only what you need for as long as you need it, and tell users plainly what happens to their messages. None of this requires exotic technology; it requires decisions made before launch and written down. This checklist takes you through them in order. It is practical guidance, not legal advice, and the ICO's own guidance remains the reference.

Which rules apply to a UK document chatbot?

In the UK, personal data is governed by the UK GDPR together with the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025. The regulator is the Information Commissioner's Office (ICO), which publishes detailed guidance on AI and data protection. If your chatbot also serves customers in the EU, the EU GDPR (Regulation (EU) 2016/679) applies to that activity as well, and so may the EU AI Act's transparency rules. Many UK organisations therefore design to both standards at once.

Start with a simple inventory. Personal data enters a document chatbot through three doors:

• The documents you index: staff handbooks with named contacts, case files, signed contracts, complaint logs, minutes of meetings.
• What users type: a council resident may paste their address and benefit details; a customer may share a medical condition to explain a return.
• What your systems record: chat transcripts, user IDs, IP addresses, analytics and supplier-side logs.

1. Lawful basis and purpose

Article 6 of the UK GDPR lists six lawful bases. Pick one per purpose and record it. For most document chatbots the choice is straightforward:

Special category data (health, ethnicity, religion, trade union membership) also needs an Article 9 condition and, often, an appropriate policy document under the Data Protection Act 2018. The cleanest approach for most organisations is to keep such records out of the knowledge base and to warn users not to share them in the chat.

2. Processors and contracts

A chatbot is rarely one supplier. There is usually a hosting provider, a retrieval service or knowledge base platform, a language model API and possibly a widget vendor. Each of them that processes personal data on your behalf is a processor, and Article 28 requires a contract with prescribed terms. For each supplier, confirm:

1. A data processing agreement covering instructions, confidentiality, security, sub-processors, assistance with rights requests, deletion or return at the end, and audits.
2. Whether your prompts and documents are used to train or improve their models, and how to opt out.
3. How long they keep prompts, outputs and logs, including copies kept for abuse monitoring.
4. Where the data is processed, and which transfer tool applies if it leaves the UK.
5. How they notify you of a breach, so you can meet the 72-hour deadline for reporting to the ICO.

3. Minimisation and retention

Data minimisation is the area where a document chatbot gives you the most control, because you decide what is indexed. Retrieval can only surface what is in the base, so a careful upload policy prevents most leaks before they can happen.

• Index reference material (policies, guides, product documentation, public regulations) rather than records about individuals.
• Redact names, signatures and contact details from templates and worked examples.
• Create separate bases for separate audiences: a public one for customers, a restricted one for HR, another for finance.
• Set a retention period for transcripts, such as 30 days, and automate deletion. Apply the same expectation to suppliers.
• Remove superseded documents promptly; an outdated policy is both a quality and an accuracy problem.

4. International transfers and security

If personal data leaves the UK, you need a transfer mechanism. The UK has adequacy regulations for the EU and EEA, and the UK Extension to the EU-US Data Privacy Framework (the "data bridge") covers certified US organisations. Otherwise, the usual tools are the ICO's International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, supported by a transfer risk assessment. If you also handle EU customers' data, the EU side has its own rules; the official EU texts on transfers are gathered in the GDPR and international data transfers knowledge base.

For security under Article 32, focus on the basics that chatbots tend to expose: encryption in transit and at rest, role-based access to who can upload and who can query, API keys held as secrets and rotated, and monitoring for prompt injection through uploaded content. Cyber Essentials certification is a common baseline in the UK and a useful frame for these controls.

5. Transparency, rights and the DPIA

Under Articles 13 and 14, people must be told how their data is used, at the point it is collected. For a chatbot, the ICO's approach points to a layered notice: a short message at the chat box, with a link to the full privacy notice. The short message should say:

• That the user is talking to an automated assistant, and how to reach a person.
• What happens to their messages, who receives them and for how long they are kept.
• Not to share sensitive information such as health or financial details.
• How to exercise their rights of access, erasure and objection.

Be ready to locate and delete a user's transcripts on request, across your systems and your suppliers'. If the bot contributes to decisions with legal or similarly significant effects, keep meaningful human review. Finally, consider a data protection impact assessment: the ICO treats innovative technology combined with personal data as a strong indicator that one is needed, and a DPIA is a good place to record every decision from this checklist.

Using a private knowledge base as the bot's source

A practical way to keep control is to hold the documents in a private knowledge base and let your chatbot query it. On Kopik, a private base is accessible only to its owner and the owner's API keys, through the website, the REST API or the MCP server. Your bot sends a question with your key and receives an answer grounded in your documents with numbered citations, or only the relevant passages if you prefer to write the answer in your own pipeline. The broader trade-offs of this approach are covered in RAG as a service.

Kopik then sits in your supplier list like any other platform: review its terms and privacy information, record it in your processing records and keep personal records out of the uploads. If your team also uses Claude day to day, the same base can be connected to it; see giving Claude access to your company documents.

The checklist on one page

1. Inventory personal data in documents, messages and logs.
2. Record a lawful basis per purpose, plus Article 9 conditions if needed.
3. Sign Article 28 contracts with every processor; check training use and retention.
4. Index reference material only, redacted, split by audience.
5. Set and automate transcript retention.
6. Document transfer tools (adequacy, data bridge, IDTA or Addendum).
7. Secure access, keys and breach reporting to the ICO within 72 hours.
8. Publish a layered notice at the chat box.
9. Prepare for access and erasure requests; keep humans on significant decisions.
10. Complete a DPIA and review it when the bot changes.