GDPR and RAG: What to Check Before You Put Documents Into a Knowledge Base

If your retrieval-augmented generation (RAG) system ingests contracts, emails, HR files or customer records, GDPR almost certainly applies, even if your company is based in the United States. The regulation follows the data subject, not the server's zip code, so any EU resident's personal data flowing through your knowledge base triggers obligations around legal basis, processor agreements, retention and hosting. This checklist walks through what to verify before you put a RAG pipeline into production with real documents.

Why GDPR Reaches US Companies Running RAG

GDPR's extraterritorial scope (Article 3) catches any organization that processes personal data of people located in the EU, regardless of where the company is incorporated. If your knowledge base answers questions using documents that mention EU customers, job applicants, or website visitors, you are processing their data under GDPR, not just under US frameworks like HIPAA or state privacy laws such as the CCPA. The practical trigger is simple: do any of your source documents, upload folders, or chat logs contain information about an identifiable person in the EU? If yes, treat the project as a GDPR project from day one rather than retrofitting compliance after the demo works. For background on how RAG retrieves and grounds answers in documents, see What Is RAG (Retrieval-Augmented Generation)? A Practical Guide.

Personal Data Often Hides Inside "Business" Documents

Teams frequently assume their corpus is "just technical manuals" or "just contracts," then discover personal data scattered through metadata, footers, and attachments. Before indexing anything, scan for:

• Names, emails and phone numbers in email threads, meeting notes or support tickets
• Employee records: performance reviews, salary bands, disciplinary notes, medical leave details
• Customer identifiers: account numbers, order history, addresses, loyalty IDs
• Health or biometric data in HR, insurance or clinical documents
• Document metadata: author names, reviewer comments, tracked changes, and revision history embedded in Word or PDF files
• Signatures and ID scans attached to contracts or onboarding packets

A quick redaction or classification pass at upload time is far cheaper than discovering, months later, that a chatbot can surface someone's home address because it was buried in a PDF footer.

Picking a Legal Basis Before You Index Anything

GDPR requires a lawful basis for every processing activity, and "we needed it for the AI feature" is not one. For internal RAG tools built on employee or vendor documents, legitimate interest (Article 6(1)(f)) usually fits, provided you document a balancing test showing the interest doesn't override individual rights. For RAG tools that answer questions using customer data tied to a contract (support tickets, order history), performance of a contract (Article 6(1)(f) or 6(1)(b)) is often the right fit. Consent is rarely practical for a knowledge base built from thousands of historical documents, since you would need to trace and obtain consent from every person mentioned. If the corpus includes health data, biometric data, or data about children, you are in special-category territory and need an explicit exception plus, in most cases, a Data Protection Impact Assessment (DPIA) before launch.

Processors, Sub-Processors and the Fine Print

Most companies building a RAG pipeline are the data controller, and whichever platform stores, chunks, embeds and queries the documents is the data processor. That relationship needs a Data Processing Agreement (Article 28 GDPR) covering what the processor can do with the data, breach notification timelines, audit rights, and deletion on termination. Check three things with any RAG or vector database vendor: whether they sign a DPA at all, what sub-processors they use (embedding model APIs, cloud hosting, logging tools), and whether those sub-processors are disclosed and can be objected to. On Kopik, a private knowledge base is queried only by its owner and their API keys, which keeps the controller-processor relationship narrow and makes the DPA easier to scope. If you're integrating a knowledge base into your own product, Adding a Knowledge Base API to Your App: A Developer's Guide covers the technical side of that integration.

Retention: Chunks, Embeddings and Query Logs

Storage minimization applies to every artifact a RAG pipeline produces, not just the original file. Deleting a source document should cascade to its chunks, its embeddings, and any cached passages returned in past answers. Query logs deserve their own retention policy too: if users type personal data into questions ("what's the policy for John Smith's leave request"), that text is now personal data living in a log file.

EU Hosting and International Data Transfers

If personal data leaves the EU/EEA to be processed by a US-based vendor, you need a transfer mechanism, typically Standard Contractual Clauses (SCCs) plus a transfer impact assessment following the Schrems II ruling. The simplest way to reduce this burden for EU-related data is to keep hosting and processing inside the EU where the underlying platform supports it. When you create a knowledge base, confirm where documents, chunks and embeddings are actually stored, not just where the company is headquartered. A private base keeps the data flow contained to you and your own systems or API keys, which simplifies the transfer analysis considerably compared to a public, multi-tenant setup.

Public vs Private Knowledge Bases: What Changes

Kopik lets anyone publish a knowledge base to a public catalogue where other users pay per question, or keep it private so only the owner and their API keys can query it. The GDPR calculus is different for each:

• Public bases should never contain personal data belonging to third parties, since you cannot control who asks questions or what legal basis they have to receive that data back as an answer
• Private bases are the right home for HR files, contracts, or customer records, since access is restricted to the controller
• Even private bases still need a DPA with the hosting platform, a retention policy, and a record of the legal basis for processing
• If you plan to monetize expertise rather than personal data, strip names and identifiers before publishing, or build a separate private base for the sensitive version

For a deeper look at building a compliant internal assistant rather than a public one, see A Private ChatGPT for Your Company Documents: What 'Private' Really Means and Build a GDPR-Compliant Chatbot on Your Documents: A Checklist for US Companies. If your use case is legal, HR or compliance specifically, RAG for Legal, HR and Compliance Teams: Use Cases, Pitfalls and a Safe Rollout Plan walks through sector-specific pitfalls in more detail.

A Practical Pre-Launch Checklist

1. Classify the corpus: flag any document containing personal data or special-category data before upload
2. Identify the legal basis for processing and document the balancing test if relying on legitimate interest
3. Run a DPIA if special-category data, profiling, or automated decisions are involved
4. Sign a Data Processing Agreement with every vendor touching the data, and list their sub-processors
5. Confirm hosting location for documents, chunks, embeddings and logs; use SCCs if data leaves the EU/EEA
6. Set a retention schedule that cascades deletion across source files, chunks, embeddings, and cached answers
7. Decide public vs private before indexing, not after; keep personal data out of public, pay-per-question bases
8. Give data subjects a way to request deletion, and make sure that request actually propagates through the index
9. Log who queried what, for how long, and under what access controls (API keys, user accounts)

If you're building the integration yourself, the developer documentation covers API keys and access scoping, which is where most of the practical access-control work for GDPR actually happens. You can also browse existing knowledge bases in the catalogue to see how public, non-personal-data bases are typically scoped (product documentation, regulatory texts, technical manuals) compared to what belongs in a private base instead.

A Note on UK GDPR, DSGVO and RGPD

The checklist above applies whether the relevant regulation is called UK GDPR (for data about UK residents, now diverging slightly from EU GDPR), DSGVO (the German-language term for GDPR) or RGPD (the French and Spanish term). The mechanics are nearly identical: lawful basis, processor agreements, data minimization, retention limits, and transfer safeguards. If your company serves customers across the EU, UK, and US simultaneously, the safest approach is to build to the strictest applicable standard (usually EU GDPR or UK GDPR) and treat US state privacy laws as a secondary, generally less demanding layer on top.