Why GDPR and LLMs collide
Most LLM vendor APIs were built for a US-first market: prompts and completions routed through US data centers by default, retained for abuse monitoring, and sometimes used for further model training unless a client explicitly opts out. None of that is automatically illegal under GDPR — but every one of those defaults needs a deliberate decision, not a shrug.
Data residency first
For clients handling EU personal data, we default to an EU-region inference endpoint (or a self-hosted open-weight model when the vendor has none) rather than treating a US endpoint as acceptable "because it's encrypted in transit."
The compliance checklist
- Confirm the vendor's data processing agreement covers sub-processors, retention period, and training opt-out
- Strip or mask personal data from prompts before they leave your infrastructure wherever the use case allows it
- Log which model version answered which request, for a defensible audit trail
- Give users a documented way to request deletion of anything an LLM feature generated about them
Consent and audit trails
A feature that reads a customer's support history into a prompt needs the same consent basis as any other processing of that data — an LLM in the pipeline doesn't create a new legal basis, it just adds another processor to disclose.
What we recommend
Treat every new LLM feature as a data-processing decision first and a product decision second — the checklist above takes a day to run through per feature, and it is far cheaper than retrofitting compliance after a feature has shipped to production.