PII in RAG Pipelines: Protect at Ingest and at Retrieval
Retrieval-augmented generation moves your documents into two new places: a vector index and, on every query, the model's context window. If personal data is in the source documents, it ends up in both — and most prompt filters never see it, because the sensitive text is injected by the retriever, not typed by the user.
Two control points, not one
- Ingest: before a document is chunked and embedded, detect and tokenize personal data so the index never stores raw values
- Retrieval: before chunks are added to the prompt, scan them again and enforce who is allowed to see what
Ingest protection shrinks the blast radius of the index itself. Retrieval protection handles everything ingest cannot: legacy indexes, documents that changed after indexing, and users who should not read every chunk the retriever finds relevant.
Privaro Ingest
POST /v1/proxy/protect-document accepts text, and the /upload variant accepts PDF, DOCX, XLSX, CSV and EML files. It returns the protected text plus the entity map, so you embed the sanitized version and keep originals in the encrypted token vault, reversible only through audited reveal.
Privaro Retrieval Guard
POST /v1/proxy/protect-retrieval receives the chunks your retriever selected and applies the pipeline policy to each one, with per-chunk access control. Chunks the caller should not see are dropped or masked before they reach the LLM, and every decision is logged against the request.
Why embeddings of tokens still work
Semantic search depends on meaning, not on the exact name or IBAN. Consistent tokens preserve structure ("[PERSON_1] signed the contract with [ORG_2]"), so retrieval quality stays close to the raw baseline while the index stops being a second copy of your customer database.
Next step
Full request examples are on the RAG PII protection page and in the API reference.