GDPR and LLMs

GDPR does not ban the use of large language models. It does require that any personal data processed through an AI workflow has a lawful basis, an appropriate data-processing arrangement with the provider, and reasonable technical and organizational measures to protect it.

For an LLM-powered application, that usually translates into a handful of concrete questions: what personal data ends up in the prompt, where does that prompt go, who retains what, and how quickly can the data flow be changed if something goes wrong.

This page is educational. It is not legal advice. It describes patterns teams use in practice and where a privacy-first LLM gateway like Privian fits in.

The prompt is the new data-export surface. Anything in the prompt is, by definition, sent to a third party. For most teams this is the first place where personal data crosses an organisational boundary without going through the usual review.

Prompts also have unusual properties: they are often built dynamically from records, they frequently include free-text written by end users, and they are shaped by individual developers under deadline. A field that nobody intended to expose can end up in a prompt simply because it was on the same object as something that was needed.

Policy and training matter. They set expectations and create the shared vocabulary a team needs. In practice, teams that handle sensitive data also add technical controls — not because their colleagues are careless, but because people inevitably paste information into tools that help them move faster.

The same pattern shows up across other data-protection disciplines: secret scanning in source control, DLP in email, masking in analytics pipelines. Each one assumes that a written rule is necessary but not sufficient, and that a technical check is what catches the long tail.

Prompt-level controls follow the same logic. They do not replace policy or governance — they sit underneath them and handle the cases where intent and behavior diverge.

There is no single answer. Most privacy-sensitive AI stacks combine several of the following, weighted to the team's constraints:

Privian is designed for teams that want to keep using managed models — GPT, Claude, Gemini and others — while reducing sensitive-data exposure in the prompts they send. It is one layer in a broader stack, not a replacement for governance, self-hosting or provider-side controls.

Prompt-level data protection is a narrow idea: apply controls to the prompt itself, at the moment it is built or sent, rather than relying on what happens after it reaches the provider.

The mechanics are simple:

• Detect supported personal and sensitive values in the inbound prompt.
• Mask each detected value with a deterministic placeholder, scoped to the request.
• Route the masked prompt to the provider using the organization's own key.
• Rehydrate placeholders in the response so the calling application sees the original values it submitted.
• Retain nothing beyond structural counters — model, latency, masked entity counts.

None of this is a substitute for data minimisation upstream of the prompt. The most reliable way to keep something out of a provider's hands is not to put it in the prompt at all.

Trust matters more than claims. Privian explicitly does not claim any of the following:

• GDPR certification or "GDPR compliant AI".
• Legal compliance guarantees or legal advice.
• HIPAA, SOC 2 or PCI certification.
• Prompt-injection or jailbreak prevention.
• Control over downstream provider behavior or provider-side retention.
• Isolation equivalent to a self-hosted or on-premise model.
• Coverage of every possible sensitive value — detection is bounded to a supported entity set that evolves over time.

See the LLM security pillar for the broader picture, or the AI Security Layer category for the architectural framing.