Why Desensitization Must Precede Embedding

The short version: desensitization must happen before chunking and embedding. The embedding itself is a leakage surface—baking sensitive fields into vectors writes the secret into your vector database, and post-hoc filtering cannot undo an embedding that already leaked.

1. Where the RAG leakage surface is

Many assume "just filter out sensitive documents at retrieval." But once a vector is generated, the sensitive information is already encoded in high-dimensional space. A blurred original may hide a name, yet its vector can still be matched by similarity search, exposing that such a sensitive document exists. The leakage surface is not at the output; it is at the embedding step.

Concretely, there are three paths. First, similarity search hits the sensitive vector; even if the original is withheld, the signal that a high-match sensitive document exists is itself valuable. Second, vectors are long-lived data, not transient computation—database operators, backup files, and export endpoints can all touch them. Third, post-retrieval filtering eats Top-K slots: a filtered document already occupied a retrieval slot, capping the relevance ceiling of what you return. One solution covers all three paths: keep sensitive content out of the vectors in the first place.

2. When to desensitize

The correct order is parse, clean, desensitize, compress, chunk, govern, evaluate. Desensitization precedes chunking and embedding, so every block entering the vector store is already a desensitized copy. This order is rigid, not advisory: any desensitization placed after embedding merely patches vectors that already leaked.

Compression belongs in the same order. Compression should prefer the desensitized copy as its source, averaging roughly 60% storage savings—saving space while preventing pre-desensitization originals from leaking a second time through compressed archives. In healthcare and finance, a single high-resolution original with a patient-name screenshot sitting in an archive directory is often all it takes to trigger a compliance incident.

3. What sensitive targets are detected

Embedded-image sensitive-region detection covers 11 classes: face, license plate, text OSD, seal/signature, QR code, screen, table, watermark logo, subtitle bar, ID number segment, and distant small objects. Handling includes Gaussian blur, mosaic, and black box, chosen per target type and sensitivity level: Gaussian blur for faces to keep visual context, black box for ID segments so nothing is left to reconstruct.

In enterprise-document contexts it is often described as 13 classes (including official seals and ID photos). Fine-grained classes exist for a reason: seals in scanned financial reports, whiteboard photos in training decks, bank-account tables in vendor contracts live in different target types, and lumping them together makes thresholds interfere. Finer classes mean false positives and misses stay controllable.

4. Relation to permission tagging

Desensitization handles "what sensitive content is written," while permission tagging handles "who can see this block." They are two complementary lines of defense: desensitization erases irreversible sensitive pixels; permissions control the access boundary. Permission tagging must also finish before retrieval—pre-retrieval filtering is what prevents post-hoc filtering from eating Top-K slots and leaking the existence of sensitive documents.

Divide by sensitivity level: public content gets permission tagging only, keeping full information; internal and above gets desensitized before ingest, with permissions as the second gate. Both defenses take effect before retrieval, so what retrieval touches is already a safe subset.

Desensitization is the first gate of data security. For pre-retrieval permission filtering see Permission Tagging in RAG; for preserving AI features in images see AI-Aware Image Compression; for chunking after desensitization see Chunking Strategies. To make desensitization a pipeline default rather than an afterthought, look at UGLYPEAR AI.

Real-World Scenario: Acceptance Criteria in Regulated Industries

When is desensitization good enough? Regulated industries usually apply three criteria. First, detection coverage: 11 categories of sensitive regions embedded in images (faces, license plates, text OSD, seals and signatures, QR codes, screens, tables, watermark logos, subtitle bars, ID-number strips, and distant small objects), commonly reported as 13 categories in enterprise documentation (adding official seals and ID photos). Second, handling options: Gaussian blur, mosaic, and black-box masking chosen per region rather than one blanket black box. Third, auditability: every detection and handling step is logged, so legal and security sign-off has evidence in hand.

A recent project covering two listed issuers — including a nationwide commercial bank — processed 859 documents with zero failures, which was only possible because desensitization logged every document and met every criterion. And the ordering rule bears repeating: desensitization must happen before chunking and embedding, because vectors themselves are a leak surface. For image-safe compression afterward, see AI Feature-Preserving Compression; for the permission-side defense, see RAG Permission Tagging.

FAQ

Q1: Why not desensitize at retrieval time?

Once a vector is generated, sensitive info is already encoded in high-dimensional space; post-hoc filtering cannot undo a leaked embedding. Similarity search can still hit the sensitive vector, exposing that a sensitive document exists and eating Top-K slots.

Q2: Which sensitive targets can be detected?

Embedded-image detection covers 11 classes: face, plate, text OSD, seal/signature, QR, screen, table, watermark logo, subtitle bar, ID segment, distant small object; enterprise contexts often describe 13, including official seals and ID photos.

Q3: How do desensitization and permission tagging differ?

Desensitization erases irreversible sensitive pixels (faces, seals); permission tagging controls who accesses which block. Public content may need tagging only; internal and above should be desensitized first. Both finish before retrieval.

Q4: What is the order of compression and desensitization?

Parse, clean, desensitize, compress, chunk. Compression should prefer the desensitized copy as source, averaging roughly 60% storage savings, and keeps originals from leaking through compressed archives.