Why architecture matters here
LLM PII architecture matters because leaks are legal and reputational disasters. A single PII leak in a prompt logged to disk becomes a breach notification event. Multi-layer detection catches what any single method misses.
Cost is modest. Detection + redaction adds 10-50ms per request; storage of audit logs is small.
Reliability of detection matters directly. False negatives leak; false positives frustrate users. Layered approach balances.
The architecture: every layer explained
Walk the diagram top to bottom.
User Input. May contain PII deliberately or incidentally.
PII Detector. Multi-layer: regex for structured (SSN, credit card), NER model for names/addresses, LLM check for context-dependent PII.
Redactor. Masks (email → <EMAIL>), tokenizes (email → <EMAIL_a1b2> with reversible mapping), or blocks.
Detection layers. Each catches different classes. Regex is precise; NER catches names; LLM catches context-dependent (e.g., "my son's name is Alex").
Policy engine. Per PII class, per user role: allow, mask, tokenize, block.
Reversible tokens. For downstream services that need actual PII (say, sending an email), authorized services unmask.
Output scanning. LLM output scanned before return; PII in output blocked or masked.
Log redaction. All logs redacted before storage. Prevents leaks from log stores.
Audit trail. Who saw unmasked PII, when. Immutable.
Right to erasure. User requests deletion; all instances found + deleted; audit records the request.
End-to-end PII handling flow
Trace a request. User asks: "Send an email to john@example.com saying I got the file."
Input detector: regex catches email. NER catches "John" as name. LLM check confirms email context.
Redactor tokenizes: "Send an email to <EMAIL_a1b2> saying I got the file." Original stored in reversible map keyed by session.
LLM processes redacted input. Response generated.
Downstream email service: authorized to unmask <EMAIL_a1b2> → gets real email. Sends.
Log: redacted version written to log store. Original email not in logs.
Audit: email-service accessed unmasked PII for token a1b2 at timestamp T. Recorded.
Three months later, user requests GDPR delete. Deletion service: find all PII tokens associated with user; delete mapping; delete audit records past retention. Confirmation returned.