GDPR for AI features: what changes when data meets a model
Adding an LLM to a product adds a processor, a data flow and new retention questions. The engineering checklist I use for EU and UK builds.
Adding a chat, search or summary feature to a product that already handles personal data changes its GDPR picture more than teams expect. There is a new processor, a new international data flow, a new place where data is stored, and a new kind of output that users might rely on. None of it is hard to handle, but it has to be handled on purpose.
I'm an engineer, not a lawyer. This is the technical side I build and check; your DPO or legal counsel signs off on compliance.
Know exactly what goes into the prompt
Start with a data flow: which fields from which tables end up in a prompt, and why. Generated code often sends the whole user record because it was convenient. Data minimisation (Article 5) means sending only what the task needs. A support summary rarely needs the customer's address or date of birth.
Where personal data isn't needed for the answer, redact it before the call: replace emails, phone numbers and names with placeholders, and map them back afterwards if the output needs them.
Treat the model provider as a processor
The provider receiving your prompts is processing personal data on your behalf, so you need a data processing agreement with them (Article 28) and they belong in your privacy notice and records of processing. Check three things in their terms, in writing:
- Training: the major API providers don't train on API traffic by default, but confirm it for the plan and endpoint you use.
- Retention: many providers keep prompts and outputs for a period for abuse monitoring. Know how long, and whether zero-retention options exist for your account.
- Location: if data leaves the EU or UK, you need a transfer mechanism. Several providers offer EU data residency or EU-region endpoints, either directly or through AWS Bedrock, Google Vertex or Azure. Use them when you can.
Your own stores count too
Chat history, traces, eval datasets and vector stores all hold personal data. Embeddings of personal data are still personal data. Give each store a retention period and a job that enforces it, and make sure "delete my account" and "export my data" reach them. Deleting the user row while their chats live on in a vector index and a tracing tool is a common gap.
Traces are the easiest to forget. Tools like Langfuse are invaluable for debugging and evals, so redact or mask personal data before it is logged, and set retention there as well.
Tell users they are talking to an AI
The EU AI Act's transparency obligations (Article 50) apply from August 2026: people should know when they are interacting with an AI system, and AI-generated content should be identifiable as such. In practice that means a clear label on the chat or assistant, and honest UI copy about what it can and can't do.
If the feature makes or heavily shapes decisions about people (credit, hiring, access to services), GDPR's rules on automated decision-making (Article 22) come into play, and that is a conversation to have with counsel before building, not after.
The checklist in short: minimise and redact what goes into prompts, sign a DPA with the provider, confirm training, retention and region in writing, put retention and deletion on every store including traces and vectors, and label the AI clearly.
Built in from the start, this adds days to a project. Retrofitted after a customer's security questionnaire or a regulator's letter, it adds weeks.
Got a demo that needs to survive real users?
Tell me what you have and what has to ship, on a call or by email with a link to the repo or the live app. I'll tell you honestly whether I can help, and what I'd look at first.