AI system design interview: handle PII in an LLM application
Classify the data first, then mask PII at the input guardrail, before it reaches the model or the logs, using placeholders like <PHONE_1> and a reverse map kept server-side for the session.
Unmask only in the final response where the user should see the value, never process card numbers in chat (send users to a payment flow), store prompts and traces masked, and choose where the model runs by data class.
Question
Your support assistant receives messages with names, phone numbers, addresses and card numbers. Design the data handling.
Clarify
- Which data classes appear, and which regulations apply (GDPR, DPDP, HIPAA, PCI DSS).
- Whether data may go to a third-party model API, and under what terms.
- Retention requirements for conversations and logs.
- Whether the task needs the real value (an address for delivery) or only its presence.
Architecture
| Stage | What happens |
|---|---|
| Classification | Define data classes and what each may touch |
| Input guardrail | Detect and mask PII, keep a reverse map per session |
| Model | Sees placeholders only, hosted according to the data class |
| Tools | Receive real values server-side when the task needs them |
| Output | Unmask only where the user should see the value |
| Logs and traces | Stored masked, scanned for leaks |
| Retention | Deletion schedule, user deletion requests honoured across stores |
Deep dive: the reverse map
The model writes "I've updated the delivery address to <ADDRESS_1>", and the server replaces the placeholder before display.
If a tool needs the real address, the server passes it to the tool directly, so the value never enters the prompt.
The map lives in memory or an encrypted store with the session's lifetime.
Card numbers
Don't process them in the assistant at all. Detect them, block them, and redirect to a payment flow that's built for that, because storing or logging them puts the whole system in scope for card data rules.
Failure modes
| Failure | Mitigation |
|---|---|
| PII in logs and traces | Mask before export, scheduled log scans |
| PII in third-party prompts | Mask before the model call, hosting by data class |
| Unmasking the wrong value | Session-scoped maps, tests with several values of the same type |
| Masking breaks the task | Measure task success with masking on |
| Detector misses unusual formats | Labelled test set per data type, regex plus model-based detection |
Metrics
PII found in log scans (target zero), masking recall on a labelled set, and task pass rate with masking on.
What interviewers listen for
Masking before both the model and the logs, and data classes driving hosting decisions.
From the floor
In the inference pipeline lecture, the first component in the guardrail zone was a PII masker, and we used Presidio, Microsoft's open-source library, because credit card numbers, personal numbers and ID numbers carry no context the LLM needs, so they should be removed before the query goes anywhere else.