Handling Personal Data When Sending Text to LLMs

The data does not stop at the model call

Most conversations about privacy and LLMs focus on one moment: the text leaving your servers for a model provider. That moment matters, but it is rarely where the real exposure sits.

Follow a customer email through a typical AI feature. It is logged in full for debugging. It is embedded into a vector index. It is cached. It is copied into an evaluation spreadsheet. A developer pastes it into a playground to investigate a bug. Six months later, when the customer asks for their data to be deleted, nobody can say where all the copies are.

Handling personal data well means designing the whole flow. Our GDPR basics for software projects covers the general principles; this post is specific to LLM features.

Step one: send less

Data minimisation is a GDPR principle and also simply good engineering. The model rarely needs everything.

• Strip signatures, disclaimers and quoted history from emails before processing
• Send only the fields the task needs. Classifying a complaint does not need the customer's phone number or address
• Pass IDs, not records. Let tools fetch account details only when the task genuinely needs them
• Truncate long histories to the relevant window
• Avoid special category data such as health, religion or ethnicity unless the purpose truly requires it and you have a lawful basis

Redaction and pseudonymisation

Detection uses a mix of pattern matching for structured identifiers such as emails, postcodes and account numbers, and named entity recognition for names and addresses. Neither is perfect. Names that are also common words, addresses written informally and identifiers inside attachments slip through, so treat redaction as risk reduction and test its miss rate on your own data.

Note that pseudonymised data is still personal data under UK and EU GDPR. It lowers risk; it does not take the processing out of scope.

Choosing and configuring the provider

1. Use business or enterprise API terms, not consumer chat products, for anything involving customer data
2. Sign a data processing agreement and confirm the provider does not train on your inputs
3. Check retention: how long prompts and outputs are stored for abuse monitoring, and whether zero or reduced retention is available
4. Check data location and the transfer mechanism for data leaving the UK or EU
5. Record the provider and any sub-processors in your records of processing and privacy notice
6. Consider self-hosted or EU-hosted models where contracts or sector rules demand it

For higher-risk uses, carry out a data protection impact assessment before launch. It is often required anyway, and it forces the useful conversation about what the feature really needs.

The places data leaks afterwards

• Application logs. Log prompt IDs, versions, token counts and outcomes by default; log full text only where needed, redacted, with short retention.
• Observability tools. LLM tracing platforms often capture full prompts. Configure masking and check where they host data.
• Vector indexes. Embeddings of personal data are personal data. Store the source ID so deletion requests can remove the vectors too.
• Caches. Scope by user and expire promptly.
• Evaluation datasets. Redact before cases leave production systems.
• Developer machines and playgrounds. Set a clear rule: no real customer data pasted into consumer tools.

If you cannot delete a customer from your AI feature, you do not have a privacy design yet. You have a hope.

A practical example: summarising support calls

Take a home insurance broker with around 1,500 recorded calls a week, transcribed and summarised for case notes. Illustratively, a sensible design redacts card details and bank numbers from transcripts before they reach the model, keeps names because the case note needs them, runs through an enterprise API with no training and short retention, stores summaries in the existing case system under its access rules, and keeps full transcripts out of application logs. Deletion requests remove the transcript, summary and any embeddings together, keyed on the case ID.

None of that prevents the feature from working. It just means the privacy notice and the system agree with each other.

How SpiderHunts handles it

SpiderHunts maps the personal data flow on every AI project before building: which fields enter, where copies land, who can see them and how deletion works. Redaction is tested with its own evaluation set, because a redaction step that misses a third of names is worse than none, as it creates false confidence.

If you run a customer-facing assistant, chatbot data privacy and GDPR goes further on consent and transparency, and our AI integration projects include the data flow review as standard. This post is general guidance, not legal advice; for a specific system, involve your data protection lead.

Frequently asked questions