Sanitising Documents for RAG and AI Ingestion

Key takeaway: Access control decides who can retrieve a document. It says nothing about what is inside it. Before a consulting deliverable enters a knowledge base or vector store, it needs sanitisation at content level: nearly every consulting deliverable contains confidential client material, and some contain material from a different client than the one on the cover.

Last updated: July 2026

What does sanitising documents for RAG mean?

Sanitising documents for RAG means removing or replacing confidential content in source documents before they are chunked, embedded and indexed, so that nothing sensitive can surface in a generated answer. It is a different problem from prompt-injection security, which protects the pipeline from hostile inputs. Sanitisation protects you from your own corpus.

You will also see this called redaction, scrubbing, blinding, anonymisation or de-identification. In consulting knowledge management, sanitisation is the working term, with redaction referring specifically to removing visible sensitive content.

Why isn't access control enough?

Because RAG dissolves the document boundary that permissions are built on. Once a deck is chunked and embedded, the file stops being the unit of anything.

• Retrieval returns passages, not files. A user's query pulls chunks from decks they would never have opened. The permission model checked the file. The answer is built from fragments.
• Synthesis blends sources. The model combines chunks from multiple projects into one fluent answer. Provenance disappears at exactly the moment it matters.
• Cross-client contamination is invisible to permissions. Consulting deliverables sometimes contain content from a different client than the one the file relates to: a benchmark slide reused from another engagement, a template that kept its old numbers. A perfectly permissioned document can still leak the wrong client's data.
• Embeddings persist. Content lives on in the vector store after the source file is restricted or deleted, until the index is rebuilt.
• The consumer is a model. Manually sanitised decks are routinely still re-identifiable by AI from context. The same class of model you are feeding your knowledge base to is the one that reassembles identity from what remains.

	Access control	Sanitisation
What it governs	Who can retrieve a file	What content exists to be retrieved
Unit of protection	Document, folder, library	Words, figures, charts, embedded objects
Cross-client contamination	Invisible	Detected and removed
After chunking and embedding	Boundary lost	Protection travels with the content
Hidden file content (notes, embedded data)	Unaffected	Cleansed

Both layers are needed. Access control is necessary. It is simply not document-level safety.

What must be sanitised before a deck enters a knowledge base?

Everything that identifies a client, directly or in combination. In practice, for a consulting deck, that means:

1. Client identifiers, direct (names, logos) and contextual (an industry, geography and metric combination that narrows to one company).
2. Financial and M&A material, from client models and margin data to deal terms.
3. Speaker notes, which carry the candid commentary that never made the slide.
4. Embedded workbooks and chart data caches, where the full model behind a single summary chart travels with the file.
5. Code-level traces such as logo URLs, external links and file paths inside the file's XML.

Much of this sits below the rendered layer of the file: see what hides inside a PPTX file for the full anatomy. Knovari's proprietary sensitivity framework covers the full spectrum of confidential content found in consulting deliverables, scoring sensitivity rather than applying binary flags. That grading matters for RAG: over-redaction strips the insight your retrieval was meant to serve, and under-detection puts client data in the index.

How should a consulting firm prepare a deliverable library for AI ingestion?

Five steps, in order. Classification comes before ingestion, not after an incident.

1. Inventory the deliverable estate: every source your assistant or pipeline can reach.
2. Classify content by sensitivity, at content level rather than document level.
3. Sanitise with a per-class treatment: redact, replace, obfuscate or keep. Semantic replacement preserves the storyline of the document, so retrieval answers stay useful.
4. Log every change. An audit trail of what was changed, where and why is what turns a cleansing exercise into something a compliance team will sign off.
5. Then ingest. Only sanitised versions enter the knowledge base or vector store.

Manual sanitisation cannot feed this pipeline at volume. At hours per deck, the library never gets processed, which is why most firms run AI on a thin pre-approved layer of their knowledge, the confidentiality wall in action. Automated sanitisation processes a deck in minutes and gives firms far more IP to ground their AI on.

Related reading: Building AI-ready knowledge bases · What is document sanitisation?