GDPR in the Age of Prompt Logs

GDPR has been broadly stable since 2018. That is worth stating plainly, because it means the growing difficulty organisations have with it is not a legal development. It is an architectural one.

The regulation did not move. The systems underneath it did.

What 2018 looked like

Personal data sat in a production database, a data warehouse, and a handful of SaaS tools. A capable person could hold the map in their head. Compliance tooling built for that world made a reasonable assumption: enumerate the systems, scan the columns, produce the inventory.

That assumption is now false at almost every company of meaningful size.

What 2026 looks like

The same organisation runs forty internal services, event streams, a dozen analytics pipelines, a vector database, fine-tuning datasets, feature stores, and inference logs. Most of it was stood up faster than anyone documented it, because that is what shipping quickly looks like.

Tooling designed for the earlier shape cannot see most of the current one. Not because the vendors are careless, but because the categories did not exist when the products were designed.

Three of the new categories deserve naming individually.

Embedding stores. Vector representations derived from personal data are still derived from personal data. A vector database holding embeddings of customer support conversations is a personal data store, and it is almost never in the inventory.

Fine-tuning datasets. Whatever went into training went into training. That is a processing activity requiring a lawful basis and a register entry, and it carries a hard problem underneath it: deleting the source record does not remove its influence from the resulting weights.

Prompt and inference logs. This is the one I find most consistently, and the easiest to fix.

The prompt log problem

Teams building AI features log full request payloads. This is completely reasonable engineering practice — you cannot debug a model integration without seeing what was sent.

Those payloads contain customer data. Names, account details, whatever the user typed, whatever context the application retrieved and injected.

The retention policy is usually some version of "they're just logs, we keep them". Under GDPR, that describes an indefinitely retained processing activity with no documented lawful basis, no retention limit, and no register entry.

It is not a subtle finding. It is simply one that nobody looked for, because logs were mentally filed as engineering output rather than as a data store.

The fix is genuinely small: identify the sinks, set a retention period, enforce it with a scheduled job, add the entry to the register. A week of work that closes a real exposure.

The deletion problem is harder

If a model was trained on someone's data and they request erasure, deleting the source record does not remove their influence on the weights. Machine unlearning is a research field, not a production capability.

The defensible position today is documented retraining cadences plus exclusion lists, disclosed honestly in your impact assessment. Do not claim erasure from model weights that you cannot actually perform. Regulators are increasingly well informed on this specific point, and an unsupportable claim is worse than a disclosed limitation.

For everything that is not a model, the patterns do work. Crypto-shredding — encrypting each subject's data under their own key and destroying the key on erasure — makes every copy unreadable, including immutable backups you cannot rewrite. That is the single most useful architectural decision available, and it is cheap early and brutal to retrofit.

Where AI helps rather than complicates

The same technology creating these gaps also closes the oldest one.

Traditional scanning finds data with a shape — email addresses, card numbers. It does not find a support ticket describing a medical condition in free text, or a transcript containing an address. Those are language problems, and language models handle them well.

This matters because unstructured stores hold somewhere between 30 and 60 percent of an organisation's real exposure and close to none of its documented inventory. It is the largest single blind spot in conventional tooling and it is now genuinely addressable.

The practical takeaway

Two things to check this month, both cheap.

First, list every log sink that touches an AI feature and confirm each has a retention period actually enforced by a job. Most companies find at least one that does not.

Second, check whether your model providers, transcription services, and AI tooling appear in your processor register. Several were probably adopted on a corporate card without procurement involvement, and every one handling personal data needs a contract, a transfer assessment, and an entry.

Neither takes long. Both close findings that are otherwise discovered by someone else, at a worse moment.

The full engineering treatment — the four capability layers, discovery, consent enforcement, rights-request pipelines, deletion patterns, and budgets — is here: GDPR Software in 2026: A CTO's Build vs Buy Playbook.

We build privacy infrastructure alongside LLM integration work, because in practice the AI surface and the privacy surface turn out to be the same surface.

Frequently Asked Questions

Are LLM prompt logs subject to GDPR?

If they contain personal data, yes. They are a processing activity requiring a documented lawful basis, a retention period, and a record of processing entry. They are among the most commonly missed stores because teams categorise them as debugging output rather than as personal data storage.

Is a vector database holding embeddings personal data?

If the embeddings were derived from personal data, treat them as personal data. Vector stores built from customer conversations, documents, or profiles belong in your inventory and your register, and they need a deletion story like any other store.

Can you remove someone's data from a trained model?

Not reliably in production today. Deleting the source record does not remove its influence on the weights, and machine unlearning remains a research area. The defensible approach is documented retraining cadences plus exclusion lists, disclosed as a limitation in your impact assessment.

Are AI vendors sub-processors?

Yes, when they process personal data on your behalf. Model providers, transcription services, and AI tooling all require contracts, transfer assessments, and register entries. Many were adopted without procurement involvement, which is why they are so frequently missing.

How do you delete personal data from immutable backups?

Crypto-shredding: encrypt each subject's data under a key unique to them, and destroy the key on erasure. Every copy of the ciphertext, including backups you cannot rewrite, becomes permanently unreadable. It is cheap to adopt early and expensive to retrofit.

Where does AI genuinely help with privacy work?

Classifying personal data in unstructured content such as tickets and transcripts, where pattern matching finds nothing. That is where 30–60% of real exposure sits, and it is the largest coverage gap in traditional tooling.