PII Handling
Personal data sitting in prompts, logs, and training sets creates privacy and compliance exposure (GDPR, HIPAA), so you have to detect and guard it. Detection works in layers (regex for structured PII like emails/SSNs, ML/NER for names and addresses) and stays imperfect, making it one layer next to the strongest control: data minimization, meaning you do not collect or log what you do not need. AI, ML, and GenAI interviews probe it because LLM logs and training data form a major PII surface, and a leak is a legal and reputational disaster.
TL;DR: Personal data (PII) turns up in LLM prompts, logs/traces, and training data, and mishandling it violates privacy law (GDPR, HIPAA) and erodes 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. Detection stays imperfect though, so it is only one layer, the strongest control being 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?