UK GDPR and RAG: What to Check Before You Build a Knowledge Base

A retrieval-augmented generation (RAG) system is, from a legal standpoint, just another way of processing personal data, so UK GDPR applies the moment your documents contain names, emails, case notes or anything else that identifies a living person. Before you upload a folder of contracts or support tickets into a knowledge base, you need answers to six questions: what personal data is actually in there, what lawful basis covers it, who counts as your processor, how long the data (and its embeddings) should live, where it is hosted, and whether the base will be public or private. This article works through each one with a practical checklist at the end.

Why UK GDPR applies to RAG, not just to chatbots

It is tempting to treat RAG as a technical problem (chunking, embeddings, retrieval quality) and leave data protection for later. That ordering causes problems. A RAG pipeline typically ingests raw documents, splits them into chunks, generates vector embeddings for each chunk, stores both the text and the vectors in an index, and then logs every question and answer for debugging or billing. Every one of those steps is 'processing' under UK GDPR if the source documents contain personal data: extraction and chunking is processing, embedding is processing, storage is processing, and returning an answer with a cited passage is processing too. The fact that a language model sits in the middle does not create an exemption. If you would need a lawful basis to email a spreadsheet of customer names to a colleague, you need one to index that same spreadsheet into a knowledge base.

This matters most for internal tools built on HR files, customer support tickets, medical correspondence, or legal case files, where the whole point of the system is to surface personal details on demand. If you are building this kind of assistant, our guide on how to build a GDPR-compliant chatbot on your documents walks through the UK GDPR checklist in more detail than we can cover here, and our piece on a private ChatGPT for your business documents is useful if you are weighing a fully private deployment against a shared one.

Step 1: Find the personal data hiding in your documents

Most organisations underestimate how much personal data sits in 'ordinary' business documents. Contracts name signatories and their job titles. Support tickets include customer emails and sometimes payment details typed into free-text fields. Case notes, HR files and clinical correspondence contain special category data under Article 9 (health, in particular) that needs extra justification. Even meeting minutes or Slack exports can contain names tied to opinions, appraisals or disciplinary matters.

• Run a quick audit of the document set before you index it: sample a handful of files from each folder and note what categories of personal data appear.
• Flag anything that looks like special category data (health, union membership, criminal records, biometric data) separately, since it needs a stronger lawful basis and often a Data Protection Impact Assessment.
• Decide whether names and identifiers are actually needed for the use case, or whether they can be redacted or replaced with references before indexing.
• Remember that embeddings are a compressed representation of the text, not an anonymisation technique. A vector generated from a paragraph containing someone's name and medical history is still personal data in the eyes of the regulator.

How you split documents into chunks also affects what ends up adjacent in the index. A chunking strategy that keeps a sensitive sentence isolated with little surrounding context can make it easier to retrieve out of context and harder to justify. Our article on chunking strategies for RAG covers the trade-offs between fixed-size, sentence-level and structure-aware chunking, which is worth reading alongside your data audit.

Step 2: Pick a lawful basis, and write it down

UK GDPR gives you six lawful bases, but in practice most RAG projects rely on one of three: legitimate interests, contract, or consent. An internal knowledge base that helps staff answer customer queries faster usually sits on legitimate interests, provided you can show the processing is necessary and proportionate and you have completed a legitimate interests assessment. A system that answers questions for the data subjects themselves (an account self-service assistant, for example) may rely on contract performance. A public, paid knowledge base that includes personal case studies or client testimonials almost always needs explicit consent from the people named.

Step 3: Clarify who is the controller and who is the processor

If you use a third-party platform to host your knowledge base (whether that is a RAG-as-a-service marketplace, a vector database vendor, or a cloud AI service), you are almost always the data controller and the platform is your processor. Article 28 UK GDPR requires a written data processing agreement covering the scope of processing, security measures, sub-processor arrangements, and assistance with data subject rights. Before you sign up to any platform, check three things: does it offer a DPA you can actually read and sign, does it list its sub-processors (cloud hosting, embedding model providers), and does it let you delete a document and have that deletion propagate through the index, not just the original file store.

When you create a private base on a marketplace like Kopik, only you and your API keys can query it, which narrows the processing to your own organisation, but the platform is still a processor for the documents it stores and indexes. For regulated sectors such as law firms, this distinction matters a lot: our guide on RAG for law firms and legal teams covers how to keep client files out of shared infrastructure and when a private base is the only acceptable option.

Step 4: Decide how long chunks, embeddings and logs should live

UK GDPR's storage limitation principle means you need a retention schedule for every category of data in the pipeline, not just the source documents. That includes the extracted text chunks, the vector embeddings generated from them, the query logs (what was asked and when), and any cached answers. A common mistake is deleting the original PDF when a retention period expires but leaving its chunks and embeddings live in the index indefinitely.

Right to erasure requests add a wrinkle specific to RAG: if someone asks for their personal data to be deleted, you need to be able to find and remove every chunk derived from documents mentioning them, not just the source file. This is much easier if your platform supports deleting a document and automatically re-indexing, rather than requiring you to rebuild the whole knowledge base by hand.

Step 5: Check where the data is actually hosted

International transfers remain one of the most commonly missed checks. UK GDPR Chapter V restricts transferring personal data outside the UK unless the destination has adequacy regulations, or you have appropriate safeguards in place such as the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses. Many AI platforms default to US-based infrastructure for embedding generation or model inference, which means every query potentially triggers a transfer.

• Ask any vendor explicitly where documents are stored, where embeddings are computed, and where logs are retained, not just where the company is headquartered.
• If the platform offers EU or UK hosting regions, check whether that applies to the whole pipeline (storage, indexing, inference) or only part of it.
• Where a transfer is unavoidable, confirm an IDTA or UK Addendum is in place and that the vendor can provide it on request, not just mention it in a privacy policy.
• For special category data, apply extra scrutiny: a transfer impact assessment is good practice even where adequacy or safeguards are formally in place.

Step 6: Public versus private bases need different controls

Not every knowledge base carries the same risk. A public base built from published regulations, technical manuals or your own marketing content carries little personal data risk and can safely be listed in a catalogue where others pay to query it. A private base built from client files, HR records or medical correspondence needs much tighter controls: no public listing, restricted API keys, and a documented lawful basis before a single file is uploaded.

If you are considering turning specialist knowledge into a paid product, read selling your expertise online: a paid AI knowledge base for consultants, solicitors and accountants before you upload anything client-identifiable, since public, monetised bases are the category most likely to attract scrutiny if personal data ends up in them by accident. On a platform like Kopik, choosing 'private' when you create a new base keeps it out of the catalogue entirely, visible only to you and whoever holds your API keys.

A practical pre-launch checklist

1. Audit a sample of documents for personal and special category data before indexing anything.
2. Decide and document your lawful basis for processing, and complete a legitimate interests assessment or consent record as appropriate.
3. Confirm whether a Data Protection Impact Assessment is required (likely if you process special category data at scale, or use automated decision-making on the outputs).
4. Get a signed Article 28 data processing agreement from any third-party platform, and check its list of sub-processors.
5. Set retention periods for source documents, chunks, embeddings and query logs, and confirm deletion actually propagates through the index.
6. Establish where data is stored and processed geographically, and put an IDTA or equivalent safeguard in place for any transfer outside the UK.
7. Decide public or private for each knowledge base, and default to private whenever client-identifiable material is involved.
8. Document a process for handling subject access and erasure requests that touches the RAG index, not just your document management system.

None of this is unique to RAG; it is the same discipline UK GDPR has required since 2018, applied to a newer architecture. If you want to understand the underlying mechanics before you assess the risk, how RAG works, step by step and text embeddings explained are useful background reading for a data protection lead who is new to the technology.

Common mistakes worth avoiding

Three patterns come up repeatedly in RAG projects that run into data protection trouble. First, teams index an entire shared drive without first checking what is in it, because the technical setup is quick and the audit feels like it can wait; it should not wait. Second, organisations treat a vendor's general privacy policy as sufficient, without obtaining a specific, signed data processing agreement that names them as controller and the vendor as processor. Third, nobody tests the deletion path until a real erasure request arrives, by which point it becomes apparent that chunks and embeddings were never wired up to the deletion workflow in the first place. Testing deletion on a dummy document before go-live catches this early.

If your organisation operates across the UK and the EU, remember that UK GDPR and the EU GDPR are closely aligned but not identical, and that the lawful basis, documentation and transfer rules you put in place for a UK entity may need a parallel check for any EU subsidiary querying the same knowledge base.