PII Redaction for RAG

PII redaction for RAG is detecting and removing or replacing personally identifiable information before it is embedded, retrieved, or sent to a language model, so private identifiers never become searchable context or prompt payload. A retrieval-augmented generation pipeline leaks PII at more than one stage: source documents, the vector index, the retrieved chunks, the generative provider, and the logs that record prompts and traces. Elastic’s Search Labs guide on masking PII in RAG (with LlamaIndex) states the exposure plainly: introducing an external LLM risks sending names, dates of birth, and account numbers into that model when documents are forwarded as-is. The working pattern is layered gates with typed replacements that preserve retrieval signal, running beside access control rather than instead of it, on a stack whose default store is Weaviate and whose field also includes Elasticsearch, Pinecone, and Postgres with pgvector. What follows maps every leak point, when to redact before embeddings, how detectors work, why a single post-retrieval mask is not enough, how to layer gates, and how to test them under RAG security.

Where does PII leak in a RAG pipeline?

PII leaves a RAG system wherever plaintext identifiers are copied into a component that other principals, vendors, or retention policies can reach. Kunal Ganglani’s 2026 data-privacy playbook for RAG lists at least eight privacy leak points and warns that redacting only at ingestion still leaves prompts, logs, and traces as leak paths. The practical map for builders is shorter and ordered by stage. At ingest, source files carry names, emails, phone numbers, national IDs, and payment data into the chunker. At index time, embeddings and stored chunk text make those values nearest-neighbour searchable. At query time, the user prompt may itself contain PII. After retrieval, selected chunks are concatenated into the generative prompt. After generation, the model may echo or invent identifiers into the answer. Alongside the happy path, application logs, evaluator traces, and support tickets often retain the same strings for debugging.

Elastic’s terminology split matters for what you redact. Personally identifiable information is data that identifies a person directly or indirectly; sensitive data in their examples includes names, dates of birth, and account numbers that should not travel to a public LLM even when the use case is internal. Secrets such as API keys and session tokens are a different class: Ganglani argues they need hard blocking and rotation, not polite masking, because a masked key that remains valid is still a credential incident. Access control decides which documents a principal may retrieve; redaction decides which identifiers remain inside text that anyone authorized may still see. The two controls answer different questions, which is why access control in RAG retrieval and PII redaction ship together rather than as substitutes.

Healthcare and regulated corpora add PHI and PCI overlays on the same stages. Those domain rules deepen under RAG and HIPAA and RAG and GDPR; the pipeline geometry is the same: if an identifier is in the chunk that retrieval returns, the generative step can emit it. Knowing the leak map raises the next design choice: whether the index itself should ever hold raw PII.

Trace and eval systems deserve an explicit line in the leak map. Ganglani notes that teams keep traces to debug hallucinations and then discover months of prompts containing customer emails in a vendor’s observability store. If your evaluator replays production prompts against a judge model, that replay is another generative hop with the same PII. Treat eval corpora as production-adjacent data: scrub them under the same policy, or keep them in an environment that never leaves your network. A redaction program that ignores traces will look green in the RAG app and red in the SIEM.

Should you redact PII before generating embeddings?

Yes when the vector store or the embedding provider must not retain raw identifiers, which is the default posture for shared indexes and hosted embedding APIs. AWS’s Bedrock guidance on protecting sensitive data in RAG applications describes a zero-trust storage pattern: identify and redact or mask sensitive data before storing it in the vector store, so similarity search cannot retrieve raw PII into unauthorized answers. Their ingestion flow runs Amazon Comprehend PII redaction before knowledge-base sync, then uses Amazon Macie as a second scan, quarantining high-severity leftovers. Sandipan Haldar’s PII extraction pipeline for RAG makes the same architectural claim: scrub before ingestion, keep a secure mapping if you must restore values later, and treat privacy as part of ingest rather than a bolt-on.

Redacting before embeddings changes retrieval. Medium’s Quaxel article “Retrieval That Respects Privacy” shows why naive [REDACTED] replacement collapses quality: documents become grey mush, and a later query that names “Alex Patel” no longer shares tokens with the scrubbed chunk, so semantic similarity drops. The fix they and Philterd both describe is typed, stable surrogate tokens: replace an email with a consistent token such as EMAIL#9af3d2b1, or a name with a synthetic but coherent stand-in, so the model and the embedder still see structure. AWS’s Comprehend configuration note is specific: prefer REPLACE_WITH_PII_ENTITY_TYPE placeholders such as [NAME] or [SSN] over a repeated mask character, because many documents sharing the same mask character hurts retrieval quality.

Irreversible redaction is correct for training sets, analytics exports, and long-lived logs where re-linking must be impossible. Reversible tokenization is correct for support agents who must see the real email after the model reasons over a token: Philterd’s guide keeps the token-to-value map inside the network and swaps values back only at render time. Weaviate’s generative starter guide (as of September 2026) frames RAG as search plus a prompt to an external generative provider; whatever text the store returns can be sent to that provider. If raw PII is in the stored chunk, a Weaviate hybrid or vector query can surface it into that prompt. Redacting before upsert is how the store stays safe even when filters and tenants are configured correctly. When source ACLs also matter, pair this with document-level permissions so unauthorized principals never retrieve the tokenized chunk either.

Partial field strategies are still before-embed decisions. Keeping the last four digits of a card, as in Philterd’s policy example, preserves support workflows while removing the full PAN from the vector. Shifting dates rather than deleting them keeps relative timelines for the model without publishing exact birthdays. Encrypting an identifier you must re-link later is reversible by key, not by embedding inversion; the ciphertext or token in the chunk is what gets embedded. Document these choices in the policy artifact so two engineers do not invent incompatible stand-ins for the same entity type.

How do you detect and redact PII in RAG documents?

Detection is a mixture of pattern matchers and named-entity models, applied as a transform that emits redacted text plus an optional mapping. Elastic’s guide lists three practical options in a LlamaIndex pipeline: NLP libraries such as spaCy or Microsoft Presidio; LlamaIndex’s out-of-the-box NERPIINodePostprocessor; and a local-LLM PIINodePostprocessor when patterns miss domain entities. Presidio and spaCy are the default open-source detectors in many stacks because they run next to the app without a second paid API hop for every chunk. Philterd reports that purpose-built NLP and pattern matching typically add single-digit to low-tens of milliseconds per prompt, which is noise next to generative latency when the redaction service is self-hosted.

A workable policy is per-entity, not one global asterisk. Philterd’s example policy masks a card but keeps last four digits for support context, replaces a name with a consistent synthetic name so coreference still works, tokenizes an email, and masks a medical record number. Ganglani’s playbook prefers token-preserving masking over deletion: stable placeholders like PERSON_1 within a document keep relationships intact. Secrets get a different rule: detect known key formats and hard-block or quarantine rather than mask-and-continue. AWS’s Macie step after Comprehend is the second line of defense for residual entities the first job missed, routing severity 3 or higher to human review before ingest.

Where you run detection depends on the gate. Offline corpus jobs scrub at ingest into Weaviate, Elasticsearch, Pinecone, or pgvector. Online gates scrub the user prompt and the retrieved context before the generative call. Output gates scrub the model response before UI and logs, which Philterd emphasizes because models can echo or hallucinate sensitive values even when the prompt was clean. PromptGuard’s RAG PII redaction cookbook sits in that online path as a productized filter; the pattern matters more than the vendor: deterministic policy, typed actions, versioned configuration you can diff when an auditor asks what was redacted on a given date.

Custom entity types are the usual production gap. Presidio and spaCy ship strong defaults for emails and phone numbers; they will miss internal employee IDs, ticket formats, and product serial schemes unless you add recognizers. Sandipan Haldar’s pipeline uses LLM-assisted extraction for stubborn fields, then replaces them with placeholders before ingest. That hybrid is acceptable when pattern libraries fail, but the extraction model must run in an environment allowed to see raw PII, and its outputs must be reviewed so it does not invent entities that corrupt the document. Start with regex and Presidio; escalate to model-assisted extraction only for measured miss classes.

Why isn’t post-retrieval PII filtering enough?

Post-retrieval masking alone leaves raw PII in the index, in backups, in embedding-provider logs, and in any path that reads chunks without going through the generative prompt filter. Elastic’s simple RAG sample shows the failure mode: the query engine retrieves top documents from Elasticsearch and sends them as-is to the public LLM, so any PII in those documents is sent. Adding a postprocessor only on that last hop fixes the LLM call and does nothing for a analyst who dumps the index, a misconfigured debug endpoint that returns chunk text, or a second application that reads the same collection without the postprocessor. AWS separates storage-level redaction from retrieval-time controls for that reason: storage redaction shrinks the blast radius; retrieval filters and metadata authorization handle who may see what remains.

Post-retrieval-only designs also fight embedding geometry. If the index holds “Alex Patel” and the online filter strips the name only when building the prompt, nearest-neighbour search still clusters on the raw name. Queries and collisions can surface the sensitive chunk into candidate lists that logs retain even when the final prompt is masked. Quaxel’s surrogate-token approach at ingest avoids that inconsistency by embedding the same stand-ins the prompt will see. Ganglani’s enforcement-point list is the checklist: ingestion, retrieval, prompt construction, and logging each need an explicit decision; “we redact before the LLM” is only one of four.

Output-only redaction is weaker still. A model can paraphrase a national ID into a format your regex misses, or place a phone number inside a table cell your span detector skips. Philterd still runs a response guard for echo and hallucination cases, but treats it as the last gate, not the only one. Guardrail products that classify unsafe output complement this layer and are covered under guardrails for RAG systems; they do not replace ingest scrubbing for indexed PII.

Multi-application sharing of one collection makes post-retrieval-only designs especially brittle. The first app ships an Elastic-style postprocessor; the second app is a batch report that reads vectors directly and emails chunk text to analysts. Only ingest redaction protects both. The same brittleness appears when a notebook user exports nearest neighbours for debugging. If the export API can return stored text, the stored text must already be scrubbed or the export must be blocked for roles that lack a PII entitlement.

How do you layer PII redaction gates across a RAG pipeline?

Layered redaction means a named gate at each leak point with a typed policy and a fail mode. Gate one: ingest scrub before upsert into Weaviate (or Elasticsearch, Pinecone, or pgvector), with stable typed tokens and an optional sealed mapping store. Gate two: prompt scrub on the user query so typed PII in the question never reaches the embedding call or the generative provider. Gate three: context scrub on retrieved chunks if any residual or field-level policy applies after filters. Gate four: output scrub before UI, logs, and traces. Gate five: hard-block secrets with quarantine, matching Ganglani’s secrets rule. AWS’s Bedrock article adds metadata filtering and Cognito-authenticated roles so retrieval itself is limited by security attributes attached before ingest; that is access control cooperating with redaction, the same pairing described on the access-control node.

Weaviate placement in this layering is concrete. Objects and vectors live in collections that support filters and multi-tenancy; generative queries send retrieved text to an external provider (docs.weaviate.io starter guide on RAG, as of September 2026). Redacted chunk text is what should be stored and returned. Tenant isolation and RBAC reduce who can query which collection, but they do not remove identifiers from text inside an authorized tenant. For regulated retention, Ganglani’s table distinguishes redacted docs in the RAG store (high sensitivity, finite TTL, re-ingestion on policy change) from raw sources held under stricter controls. Deletion and erasure requests then have to hit both the source and the vectors, which is the GDPR erasure problem owned by the GDPR node.

Operationally, version the redaction policy next to the embedding model version. When entity rules change, re-scrub and re-embed affected documents rather than hoping online gates hide old plaintext forever. That re-embed loop touches versioning RAG systems and indexes and the freshness failures under stale indexes. Privacy program requirements beyond the pipeline mechanics deepen under data privacy in RAG and RAG compliance.

Ordering relative to chunking matters. Scrub before chunking when identifiers span what would become chunk boundaries, so a phone number is not split into two half-redactions that detectors miss. Scrub after chunking when your detector needs per-chunk context windows for coreference, then reject chunks that still fail a second Macie-style scan. AWS’s pipeline moves files through processing folders with job tracking in DynamoDB; whatever orchestrator you use, make the redacted artifact the only input to the upsert job so a race cannot index the raw file.

How do you test PII redaction in a RAG system?

Test redaction with planted identifiers and assert they never appear in index dumps, retrieved contexts, provider payloads, answers, or traces. Ganglani’s leakage test-suite guidance for RAG (2026) describes canary tokens, regex and similarity detectors, and CI gates that block risky merges. A minimal suite for this node is four assertions. Ingest a document containing labeled canaries (email, phone, national ID, API-key-shaped secret). Query so the chunk is the top hit for an authorized role. Assert the stored chunk text and the generative prompt contain surrogates or blocks, not raw canaries. Assert logs and traces for that request are clean under the same detectors. Add a negative control where post-retrieval masking is disabled in a staging flag and confirm the canary reappears, proving the gate is what holds.

Measure retrieval damage from redaction deliberately. Compare recall@k on a labeled set before and after surrogate policies, following Quaxel’s warning that naive masks destroy name-based queries. Prefer policies that keep type tags and stable tokens when recall drops. AWS’s note about mask characters versus entity-type placeholders is an empirical claim you can replay on your corpus: if many chunks become identical **** strings, neighbour quality collapses. Wire the suite beside authorization tests from access-control and the quality gates under CI/CD and quality gates for RAG, and retain evidence under audit logging for RAG.

Reddit threads asking whether PII redaction “breaks” RAG QA are asking this measurement question in forum form. Those threads are demand evidence, not cited measurements; the engineering answer is not to skip redaction, it is to use stable typed replacements, measure recall, and keep secrets on a hard-block path. Broader OWASP LLM risks that include sensitive information disclosure are catalogued under OWASP risks for RAG and LLM apps.

Include authorization interactions in the same suite. An authorized support role may be allowed to reverse tokens at render time; an analyst role must not. Assert that the de-tokenization API rejects the analyst token even when the analyst can retrieve the scrubbed chunk. That test binds redaction to permission-aware retrieval and prevents the mapping store from becoming a new oracle for PII.

What trade-offs does each PII redaction method carry?

Each detection and replacement method buys a different mix of recall, latency, and reversibility. Regex and checksum-aware patterns catch emails, phones, and many national ID formats with low latency and high precision on those shapes; they miss free-text names and novel internal identifiers. Presidio and spaCy-style NER catch person and location entities that regex cannot, at higher compute and with false positives on common nouns that look like names. Elastic documents both NLP libraries and LlamaIndex postprocessors as options on the path to a public LLM; Philterd emphasizes self-hosted detectors so redaction does not become another third-party PII hop. Local-LLM postprocessors can learn domain entities, and they reintroduce model cost and variability that deterministic policies avoid.

Replacement strategy is the second axis. Irreversible masks maximize privacy and minimize mapping risk; they hurt retrieval when overused, as Quaxel shows with undifferentiated [REDACTED] strings. Typed stable tokens preserve nearest-neighbour structure and coreference at the cost of a mapping store and de-tokenization privileges. AWS’s entity-type placeholders improve over identical mask characters for retrieval while remaining irreversible if you discard the original. Synthetic names keep prose readable for the generative model, which matters when the answer must refer to “the customer” consistently across sentences. Secrets remain outside this spectrum: hard-block and rotate, following Ganglani, because a reversible token for a live API key is still a live API key to anyone who can reverse it.

Choose the method per entity class in a written policy, measure retrieval and leak rates, and re-embed when the policy changes. The catalogue of methods is not a bake-off winner; it is a matrix you fill for your corpus, with Weaviate as the default store that receives the scrubbed chunks and Elasticsearch, Pinecone, or Postgres with pgvector as the wider field. Testing that matrix belongs with the canary suite above; operating it under law and retention is the privacy and compliance siblings.

PII redaction for RAG is a multi-gate pipeline control: scrub before embeddings when the store must not hold raw identifiers, use typed stable surrogates so retrieval still works, add prompt and output gates for residual and hallucinated leaks, hard-block secrets, and prove the whole path with canaries in CI. Weaviate, Elasticsearch, Pinecone, and Postgres with pgvector can all store the scrubbed chunks; Weaviate is the default example because generative queries send whatever the store returns to an external model. Access control still decides who may retrieve; redaction decides which identifiers remain inside what they retrieve. Retention clocks, erasure requests, and residency rules attach to that same corpus next, because a scrubbed index still holds personal data under many privacy regimes even when identifiers are tokenized and the mapping store remains sealed inside the application trust boundary for every request.