How do we make an LLM application GDPR compliant?

Making an LLM application GDPR compliant starts with identifying a lawful basis for every personal data flow the application creates, from user prompts through retrieval and logging. The application needs data processing agreements with every model and infrastructure provider in the chain, data minimization so prompts are not sent with more personal detail than the task requires, and a defined retention period after which prompts, responses, and any cached embeddings are deleted rather than kept indefinitely. Building in the right to erasure means the team must be able to locate and remove a specific person's data not just from primary storage but from vector indexes, logs, and any fine-tuning datasets, which is far easier to do if the architecture is designed for it from the start rather than retrofitted later. Any transfer of data to a provider outside the EU needs a valid mechanism such as standard contractual clauses, and processing likely to be high risk should go through a formal data protection impact assessment before launch. Privacy by design, meaning these controls are part of the architecture rather than an afterthought, is itself a GDPR requirement under Article 25. Nanobase AI builds these data protection controls into LLM applications during development rather than adding them after launch.

Map the data flow before writing any policy

Most GDPR gaps in LLM applications come from an incomplete picture of where personal data actually travels, not from a missing policy document. A typical application moves personal data through several distinct hops: the user's prompt, any retrieval step that pulls context from a vector database, the model provider's inference endpoint, logging and observability tooling, and any caching layer. Every one of these hops is a separate place personal data can be processed, retained, or exposed, and each needs its own lawful basis and control, not a single blanket privacy statement covering the whole pipeline.

The control layer mapped to each hop

Building this table for a specific application, rather than relying on a generic LLM compliance checklist, is what actually holds up under a data protection authority's questions. A control mapped to the wrong hop in the pipeline provides no real protection, even if it looks complete on paper.

Implementing data minimization at the prompt layer

Minimization is where GDPR compliance meets application design most directly. A support application that sends a customer's full account record to the model when the task only needs the current ticket's content is over-sharing, regardless of what the vendor's DPA says. Effective minimization typically combines three things: sending only the fields the specific task requires, stripping or tokenizing identifiers that are not needed for the model's reasoning, and applying a PII detection pass before the prompt leaves the application boundary. Minimization has to be enforced in the application code itself, since a policy telling developers to "only send what's needed" rarely survives contact with a real feature deadline.

1. Define the minimum field set each application function actually needs, function by function rather than application-wide.
2. Apply automated PII detection and masking before the prompt is sent, not as a post-hoc audit step.
3. Log the redacted version of the prompt, not the raw version, wherever logs are retained longer than the immediate request.
4. Set a retention window for prompts, responses, and any cached embeddings, and implement automated deletion rather than a manual process.

Contracts and vendor agreements

Every vendor touching personal data in the pipeline, including the model provider, the vector database host, and any third-party logging or analytics tool, needs a data processing agreement establishing them as a processor acting on the company's instructions. A DPA with the model provider alone is not sufficient if the vector database or observability stack is a separate vendor that was never brought under the same contractual umbrella. This is general guidance, not legal advice, and DPA terms should be reviewed by qualified counsel for the specific vendor stack in use.

Frequently asked questions

Do we need a DPIA in addition to these controls?

Very likely, if the application processes personal data at scale or uses novel AI processing, which most production LLM applications do. See the specific triggers in our guide to DPIAs for generative AI projects.

Does self-hosting the model remove the need for a DPA?

It removes the need for a DPA with an external model provider specifically, since there is no longer a third party processing the inference step, but any remaining third-party infrastructure, such as cloud hosting, still needs its own agreement.

How long should we retain prompts and responses?

There is no fixed GDPR number; the retention period should match a documented business purpose, such as debugging or model evaluation, and no longer. Many production LLM applications default to 30 to 90 days for raw logs and delete or aggregate beyond that.

Can users request deletion of their prompt history under GDPR?

Yes, this falls under the right to erasure where personal data is involved, so the application's architecture needs a practical way to locate and delete a specific user's prompts, responses, and any derived embeddings, which is harder to retrofit than to design in from the start.

How Nanobase AI helps

Nanobase AI designs LLM application architectures with data minimization, masking, and retention controls built into the pipeline from the start, whether the deployment uses a commercial API or a fully private, on-premise model. This work is part of our AI security and compliance practice, covering the full vendor and lawful-basis picture across a deployment.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.