How do you handle PII in an LLM system, from prompt to logs?
- 2 min — where PII flows in an LLM system
- 4 min — inline vs async redaction, tokenisation, retention
- 4 min — regional obligations and erasure via a data map
- 2 min — ownership and failure modes
Personal data flows through more places in an LLM system than in a typical app: user prompts, retrieved documents, provider requests, logs, traces, eval datasets, caches, vector indexes and fine-tuning data. PII redaction — detecting and masking or tokenising personal data — is applied at defined boundaries, together with access control, retention limits, provider data-processing terms, and the ability to find and delete a person's data on request.
The gateway runs fast pattern detectors (emails, phone numbers, card and account numbers, national IDs per region) inline, replacing values with reversible tokens held in a vault before logging — and, for tenants who require it, before the provider call, re-inserting real values in the response. A heavier NER model (e.g. Microsoft Presidio with a transformer recogniser) runs async on traces before they land in the long-term store. Raw traces keep a 30-day TTL; redacted traces 13 months. Eval datasets built from production pass through redaction before annotators see them; retrieval enforces document ACLs so the model never sees what the user couldn't.
Detection is imperfect: pattern detectors are near-perfect on structured identifiers and miss free-text details ('my neighbour's son, who has diabetes'); model-based detectors are slower and probabilistic. Redaction lowers risk; it does not remove it, so minimise what you log in the first place. Budget inline redaction at ≤20 ms p99 and push heavy detection async. Region matters: GDPR erasure (Art. 17), India's DPDP Act, UAE and Singapore PDPA each impose consent, residency or deletion duties — which means a data map of every store (logs, caches, vector index, eval sets, fine-tune corpora) keyed by subject so an erasure request can be executed within a month. Use zero-data-retention endpoints for regulated tenants. Ownership: privacy engineering owns the detectors, vault and data map; the gateway team owns enforcement; feature teams can't opt out. Where it breaks: a semantic cache keyed on query text serving one user's answer to another, and redacting so aggressively that the model loses the context it needs.
Inline pattern detection on a 3k-token prompt: single-digit ms on one CPU core, within a ≤20 ms p99 budget. Async NER at 5M calls/day: if a CPU worker handles ~50 traces/s, 5M / 86,400 ≈ 58/s mean needs 2 workers; size 6 for peak and backlog.
What the answer sounds like at each level
Mask personal data like emails and phone numbers before logging or sending it to the model.
Redact at defined boundaries with reversible tokens, run heavier detection async, set retention per store, enforce ACLs in retrieval, and redact eval data before annotation.
I own a data map of every store keyed by subject for erasure, set a latency budget for inline redaction, apply per-region policies and ZDR routes, and make enforcement central so no team can opt out.
Follow-ups the interviewer will push
1A user in the EU requests erasure. Where is their data?
Gateway traces, the token vault, semantic and prompt caches, any vector index built from their documents, eval sets sampled from their sessions, and any fine-tune corpus. The data map lets you find each by subject id; caches and indexes need delete-by-key, and fine-tunes may need retraining or documented legal basis.
2Redaction is breaking answers — the model can't tell which account the user means. Fix?
Use consistent per-session tokens ('ACCOUNT_1', 'ACCOUNT_2') instead of a generic mask, so the model can reason about identity without seeing values, and re-insert values in the response.
Red flags interviewers listen for
- Logs full prompts and responses indefinitely 'for debugging'.
- Assumes a regex redactor catches all personal data.
- Has no way to find a person's data across caches, indexes and eval sets.
How it's scored
| Dimension | What strong looks like |
|---|---|
| Data-flow coverage | Names logs, traces, caches, vector indexes, eval sets and fine-tune data. |
| Engineering design | Inline budgeted redaction, async heavy detection, reversible tokens, TTLs. |
| Compliance realism | Erasure via a subject-keyed data map; per-region rules; ZDR for regulated tenants. |
Sources
- Presidio: data protection and de-identification SDK — Microsoft, 2025docs
- GDPR Art. 17 — Right to erasure — European Union, 2016spec