PII Handling
Personal data in prompts, logs, and training sets is a privacy and compliance risk (GDPR, HIPAA), so you must detect and protect it. Detection is layered (regex for structured PII like emails/SSNs, ML/NER for names and addresses) and imperfect, so it is one layer alongside the strongest control: data minimization, do not collect or log what you do not need. Applied-AI interviews probe it because LLM logs and training data are a major PII surface, and a leak is a legal and reputational disaster.
TL;DR: Personal data (PII) shows up in LLM prompts, logs/traces, and training data, and mishandling it breaks privacy law (GDPR, HIPAA) and trust. You detect it with layered methods, regex/checksums for structured PII (emails, SSNs, card numbers) and ML/NER for unstructured PII (names, addresses), then redact, tokenize, or hash. But detection is imperfect, so it is one layer, the strongest control is data minimization: do not collect, log, or retain PII you do not need. LLM logs and training sets are a major PII surface that teams often overlook.
Where PII hides in LLM systems
- Prompts: users paste personal data into requests.
- Logs and traces: observability captures inputs/outputs, which may contain PII, an easily-overlooked surface.
- Training/fine-tuning data: PII in the corpus can be memorized and regurgitated by the model (related to membership inference).
You must protect it at each. The one teams miss is logs: a chat app can redact what it shows the user while its trace pipeline (Datadog, an eval store, a prompt-replay table) quietly retains the raw, un-redacted prompt for months. The redaction has to happen before the write, not at display time.
Detecting it (layered, imperfect)
- Regex / patterns catch structured PII with predictable formats (emails, phone numbers, SSNs, card numbers, validated with checksums like Luhn for cards). High precision for those.
- ML / Named Entity Recognition catches unstructured PII with no fixed pattern (person names, addresses, organizations); regex cannot find "John from Boston." Microsoft Presidio is the common open-source stack here, pairing recognizers with a redaction/anonymization engine.
- Then redact (mask), tokenize/pseudonymize (reversible mapping when authorized downstream use is needed), or hash.
Detection has false negatives (leaks) and false positives (over-redaction), so it is necessary but not sufficient. The threshold you pick is a real tradeoff, not a formality.
Worked example: why you tune the threshold
Suppose an NER name-detector runs at recall 0.95 on a stream of 1,000,000 messages a day that contain, say, 50,000 true names. At recall 0.95 you miss 2,500 names per day, each a potential leak written to a log that lives 90 days. Push the threshold down to chase recall 0.99 and you might cut misses to 500, but precision drops from 0.9 to 0.7, so over-redaction roughly triples and analysts start seeing [REDACTED] reset [REDACTED] password where the verb mattered. There is no setting that makes both errors go to zero, which is the whole point: detection alone cannot be the control. You tune recall high for the highest-sensitivity fields, accept the over-redaction, and lean on minimization to shrink the volume that ever reaches the detector.
The strongest control: minimization
Because detection is imperfect, the most reliable protection is to not have the data: data minimization, collect and log only what you need, redact at ingestion, and set retention limits (delete when no longer needed, supporting GDPR's right to erasure). A field you never store has a 100% detection rate for free. Pair with access controls and encryption, and tenant isolation (see multi-tenancy). For training, remove/redact PII to reduce memorization (and consider differential privacy).
| Control | What it buys | Failure mode |
|---|---|---|
| Detection + redaction | catches PII already in the stream | false negatives leak, false positives over-redact |
| Minimization + retention limits | shrinks the surface to near zero | requires discipline at design time |
| Access control + encryption | limits who/what can read it | insider or token compromise |
| Tenant isolation | no cross-customer leakage | per-request scoping bugs |
Why interviewers probe this
PII handling is a compliance and trust requirement, and LLM logs especially are a PII surface teams forget. A strong answer covers layered detection (regex for structured, NER for unstructured) and the key point that detection is imperfect, so minimization (do not collect/log/retain what you do not need) plus access control and retention limits are the real protection. Naming a concrete stack (Presidio), the log-pipeline gap, and memorization as a training risk signals practical privacy awareness rather than a recited checklist.
Common misconceptions
- "Regex catches all PII." It catches structured PII; names/addresses need ML/NER, and even together detection is imperfect.
- "Redaction makes it safe." Detection has false negatives; minimization, access control, and retention limits are the stronger controls.
- "Logs are not a PII concern." LLM logs/traces are a major PII surface; redact before the write and access-control them.
- "Training data PII is harmless." Models can memorize and regurgitate it; remove/redact and consider differential privacy.
Key takeaways
- PII lives in prompts, logs/traces, and training data; protect each surface.
- Detect with layered methods (regex/checksums for structured, ML/NER for unstructured), then redact/tokenize/hash.
- Detection is imperfect (you trade false negatives against false positives), so data minimization is the strongest control.
- Add access control, encryption, retention limits, and tenant isolation; training PII risks memorization.
Check yourself before an interviewer does. Answer from memory first.
Given that detection is imperfect, what is the strongest PII control?