Overview
Redact at ingest, redact at retrieval, audit at egress.
Why it matters
Once PII reaches the LLM, you've lost control of it. Three layered redaction points keep you out of trouble.
Redact at ingest, redact at retrieval, audit at egress.
Redact at ingest, redact at retrieval, audit at egress.
Once PII reaches the LLM, you've lost control of it. Three layered redaction points keep you out of trouble.
Once PII reaches the model, you've lost control of it — it can be echoed, logged, or leaked. So redaction is layered at three points, defence-in-depth, not one chokepoint.
ingest: replace emails/phones with stable salted tokens before embedding
retrieval: filter chunks by viewer entitlement and purpose
generation: redact any PII not present in authorised evidence
audit: log [original_doc_id, redaction_version, viewer_role]
Redact at ingest so raw PII never enters the vector store (using stable tokens keeps records linkable without exposing the value). Filter at retrieval so a viewer only ever gets chunks they're entitled to. Redact at egress as the last backstop. Any single layer can fail; all three failing at once is what you're guarding against.
Version your redaction policy. When you change what counts as PII or how you tokenise, you must be able to prove which redactor touched which evidence — redaction_version in the audit log is what makes that defensible to a regulator.
Plan right-to-erasure into the vector store. Deleting a source record means its embeddings and tokens must be purged too, not just the original document — an often-forgotten path that quietly keeps 'deleted' PII searchable.
PII redaction is airport security in layers: ID check at the door (ingest), boarding-pass gate (retrieval), and a final scan at the jet bridge (egress). No single checkpoint is trusted alone, and there's a logbook (audit) proving who was screened by which policy.
Trace one piece of PII through your system.
Reading in progress · 0 of 4 activities done