AI Data Privacy for LLM features that handle personal data
Map where personal data flows through your AI feature, remove what the model does not need, pseudonymise what it does, and keep logs and providers within your retention rules.
- UK GDPR and EU GDPR aware
- Works with your DPO
- Implementation included
Any AI feature that touches customer, patient, employee or applicant data
LLM features create new copies of personal data: in prompts, in provider logs, in vector indexes, in traces and in model outputs. Each copy needs a purpose, a lawful basis, a retention period and an access rule. Most teams have thought about the first copy and none of the others.
- Support, sales and HR assistants reading customer or employee records.
- Document processing of invoices, contracts, claims and applications.
- Knowledge bases over email, tickets and shared drives.
- Healthcare, financial services and HR technology deployments.
Outcomes
- A data flow map of every hop personal data takes through the feature.
- Redaction and pseudonymisation implemented in your pipeline.
- Provider terms, regions and retention settings verified and recorded.
- The technical sections of a DPIA, ready for your DPO.
Where personal data goes, and where it is removed
The pattern below is what we implement most often. Personal data is tokenised early, the model works on pseudonyms, and re-identification happens only inside your application for the authorised user.
PII handling patterns we implement
| Pattern | What it does | Use it when | Watch out for |
|---|---|---|---|
| Minimisation | Send only the fields the task needs; drop the rest before prompt assembly | Always. It is the cheapest control and the first one auditors ask about | "Just send the whole record" creeping back in as features grow |
| Redaction | Replace detected PII with a type marker such as [EMAIL] or [NAME] | The model does not need the value: classification, summarisation, routing | Detector misses on names, addresses and free text; test on your data, not samples |
| Pseudonymisation | Replace PII with a stable token per entity and keep the map in a vault | The model must refer to entities consistently across a conversation or document | Re-identification must be scoped to the authorised user and logged |
| Field-level encryption | Encrypt sensitive columns at rest in indexes and stores | Vector indexes or caches hold personal data that cannot be pseudonymised | Key management and rotation; search over encrypted fields is limited |
| Retention rules | Time-limited storage for prompts, outputs, traces and index entries | Everywhere personal data is copied; set per copy, not per system | Provider-side retention and backups outside your deletion job |
| Access scoping | Tool and retrieval calls run as the end user, never a broad service account | Agents and RAG over records with differing access rights | Service accounts that quietly accumulate scope over time |
Five questions for every model provider
- Is there a data processing agreement, and are we the controller or a processor?
- Is our data used for training by default, and have we opted out in writing?
- How long are prompts and outputs retained, including for abuse monitoring?
- In which region is the data processed and stored, and can we pin it?
- Which sub-processors are involved, and how are we told when they change?
We work with Anthropic, OpenAI, Google and open-weight models hosted on Azure, Cloudflare or your own infrastructure. The answers differ by provider and by plan; we record them in your model inventory so they are not re-researched every quarter.
We write the technical sections of a data protection impact assessment: processing description, data flow diagram, necessity and proportionality of each copy, risks to individuals and the controls applied. Your DPO or counsel completes the legal assessment and sign-off. The same material feeds the ISO 42001 impact assessment.
Map, minimise, implement, prove
Map
Every hop personal data takes: sources, prompts, providers, indexes, logs, outputs, backups. One diagram, agreed with your DPO.
Minimise
For each hop, decide: not needed, redact, pseudonymise or keep with controls. Record the reasoning.
Implement
Detection and tokenisation in the pipeline, vault and re-identification service, log redaction, retention jobs, provider settings.
Prove
Tests that assert no raw PII reaches the provider or logs, run in CI. DPIA technical sections and inventory updated.
Privacy sits inside a wider design
Frequently asked questions
Do we need a DPIA for an LLM feature?
Often, yes. A data protection impact assessment is expected where processing is likely to result in high risk to individuals, and new technology applied to personal data is a classic trigger. We produce the technical half of the DPIA: data flows, risks, controls. Your DPO or counsel owns the legal assessment.
Is it safe to send customer data to a model provider?
It can be, with the right terms and controls: a data processing agreement, no training on your data, a defined retention period, a known region, and redaction of what the task does not need. We check all five before any production call.
Redaction or pseudonymisation: which should we use?
Redaction when the model does not need the value at all. Pseudonymisation when the model needs to refer to an entity consistently, for example 'Customer 4821' across a conversation, with re-identification only in your application for authorised users.
Should we run models on-premise to avoid the question?
Sometimes. Open-weight models hosted in your own environment remove the provider transfer but add operational cost and narrow your model choice. Our on-prem versus cloud guide walks through the decision.
What about data in logs and traces?
Most privacy incidents happen in logs. We redact prompts and outputs at the logging layer, keep chunk and record identifiers instead of content, restrict access and set a retention limit that matches your policy.