Compliance

GDPR-Compliant AI Development: A Practitioner's Checklist for EU Teams

The controls, data-flow patterns, and DPIA-ready architecture we use to ship AI in the UK and EU.

GDPR data-flow diagram for a RAG pipeline with PII redaction and EU-region hosting

Every UK or EU team building on LLMs eventually has the same conversation with their DPO: can we do this under GDPR? The answer is almost always yes — GDPR does not ban AI. It requires the same lawful basis, data minimization, and transparency you already owe your customers. This is the practitioner's checklist we work through when shipping AI for regulated UK and EU clients (from our London-serving team).

None of this is legal advice. Consult your DPO. But this is the engineering-side of a GDPR-safe AI build — the controls that make the DPIA a green light rather than a maze.

The three questions every AI feature must answer

  1. What personal data reaches the model? Directly, in prompts. Indirectly, in retrieved documents. In fine-tuning data. Any of those is processing.
  2. What is the lawful basis for that processing? Contract, legitimate interest, consent, legal obligation. Pick one and document it.
  3. Where does that data go, and who processes it? Which model provider. Which region. Which sub-processors. Data leaving your perimeter needs SCCs or a UK IDTA.

If you cannot answer those three cleanly for every feature, don't ship yet.

Nine controls we build into every AI engagement

1. Data minimization at the prompt boundary

Only send to the model what it needs to answer. If the user's question is "what's the return policy?", the model does not need the customer's name, email, or order history. Strip PII from prompts before they leave your service. This alone reduces your GDPR surface by 60-80%.

2. PII redaction on retrieval

For RAG systems, the retriever pulls documents into the prompt. If those documents contain PII (support tickets, medical notes, HR records), that PII travels to the model. Two options: redact at ingest (irreversible, safest) or redact at retrieval (reversible, more flexible). We usually pick redact-at-ingest for anything a support agent or third-party model would see.

3. EU-region hosting by default

AWS eu-west-1 (Ireland), eu-west-2 (London), Azure UK South, or GCP europe-west2. For any personal data. If your provider only offers US regions, you either need SCCs / IDTA in place or a different provider. UK IDTA (International Data Transfer Agreement) replaced SCCs for UK-EU transfers post-Brexit — check whether your DPA has both.

4. On-prem or open-source LLMs for high-sensitivity workloads

For legal, medical, or highly regulated finance workloads, deploy an open-source model — Llama 3, Mistral, Qwen — inside your own perimeter. No data leaves. This is often the only defensible architecture for firms with a "no customer data to third-party AI" policy. We regularly ship on-prem RAG for exactly this reason.

5. Encryption in transit and at rest, always

TLS 1.2+ everywhere. Vector store encrypted at rest. Query logs encrypted. Backup encrypted. Non-negotiable for GDPR Article 32 (security of processing).

6. Access controls scoped to purpose

Not every employee needs to see every prompt. Role-based access to model UIs, query logs, and admin surfaces. Audit trails on who saw what, when. This is what your ICO or DPA reviewer will ask about first.

7. Query and prompt logging you can defend

Log enough to debug the model and defend a subject access request. Log little enough that a breach doesn't turn into a personal data catastrophe. We usually log: prompt hash + timestamp + model + latency + user id + retrieved doc ids. We do NOT log: raw prompts containing PII, model outputs containing PII, embedding vectors of PII text.

8. Retention policies that actually run

GDPR Article 5(1)(e) requires personal data to be kept no longer than necessary. Prompt logs need a retention policy — 30 days, 90 days, whatever fits — and a cron job that actually deletes them. "We don't have a retention policy" is a red flag on a DPIA.

9. Model provider DPAs on file

Every third-party model you call is a processor under GDPR. You need a data-processing agreement with each. OpenAI, Anthropic, Google, Cohere, Mistral all publish theirs. If your team hasn't signed them, do that this week.

A DPIA-ready data-flow pattern

The architecture that reliably passes DPIA review looks like this:

  1. User submits a request through your product.
  2. Your service extracts the intent and strips PII from the prompt (redaction layer, in your perimeter).
  3. Retrieval runs against your EU-region vector store; retrieved passages have already been PII-redacted at ingest.
  4. Sanitized prompt + retrieved passages are sent to the model — either your on-prem open-source model or a third-party API with SCCs and DPA in place, in an EU region.
  5. Response is returned to your service; PII (if the model added any) is scrubbed before returning to the user.
  6. Query log stores prompt hash + metadata only; retention job runs daily.

Every arrow in that diagram maps to a control on the DPIA. That is the trick — think in terms of arrows, not features.

The EU AI Act, briefly

Beyond GDPR, the EU AI Act now regulates high-risk AI systems. Most enterprise LLM apps — support, Q&A, internal tooling — are not high-risk. But biometric ID, hiring, credit scoring, education grading, and law-enforcement uses can be. If your feature touches those, get legal review before you ship. Transparency obligations ("users must know they are interacting with AI") apply broadly.

Common failure modes

  • Prompt PII leakage. Front-end sends the whole user profile as context. Fix: server-side prompt construction, redaction layer.
  • Vector store containing PII. Every embedded doc becomes searchable. Fix: PII redaction at ingest.
  • US-only provider on EU data. No SCCs, no DPA. Fix: EU region + DPA in place, or open-source on your infra.
  • Unbounded log retention. Prompt logs from two years ago still in the store. Fix: retention policy + running deletion job.
  • No lawful basis documented. Team can't articulate which Article 6 basis applies. Fix: DPIA and lawful basis on file before ship.

Recommendation

Design GDPR compliance into the pipeline, not on top of it. Every AI feature we ship for UK or EU clients starts with the data-flow diagram above and adds features around it — never the reverse. If you're mid-build and this feels late, it's not too late — but the cost of retrofitting rises fast after launch.

If you want engineering help specifically for GDPR-safe AI, our UK-serving team ships on-prem RAG and DPIA-ready architectures as a standard offering. Talk to us for a scoped conversation with a real engineer.

Tags
GDPRAI DevelopmentRAGUKEUCompliance
Share this article