PII Leaking in Retrieved Context

The Problem

Personally Identifiable Information (PII) from ingested documents appears in retrieved chunks and gets included in AI responses, creating privacy violations.

Symptoms

• ❌ Names, emails, phone numbers in responses

• ❌ SSNs or IDs visible in context

• ❌ Private customer data exposed

• ❌ GDPR/CCPA violations

• ❌ Sensitive info in citations

Real-World Example

Knowledge base ingests:
→ Customer support tickets
→ Internal emails
→ CRM exports

Query: "How to handle refunds?"

Retrieved chunk includes:
"Customer John Smith ([email protected], SSN: 123-45-6789)
requested refund for order #5678..."

AI response inadvertently exposes PII to different user

---

Deep Technical Analysis

Ingestion-Time PII Exposure

Document Scraping:

Source systems contain mixed content:
→ Policy docs (safe)
→ Example tickets with real names (unsafe)
→ Email threads with signatures (unsafe)

Bulk ingestion:
→ No PII filtering
→ Everything embedded into vector DB
→ PII becomes retrievable

PII in Metadata:

Document metadata carries PII:
→ author: "[email protected]"
→ last_modified_by: "Jane Doe"
→ file_path: "/users/john.smith/documents/"

Metadata included in chunks:
→ PII propagates to responses

Retrieval-Time Leakage

Cross-User Data Bleed:

User A's query retrieves:
→ Chunks containing User B's data
→ No filtering by data ownership
→ PII from one user visible to another

Multi-tenant knowledge base:
→ Insufficient isolation
→ Privacy violation

Citation Exposure:

AI cites sources:
"According to ticket #12345 from [email protected]..."

Citation itself contains PII:
→ Even if response text safe
→ Source attribution leaks data

Vector DB PII Persistence

Embeddings Encode PII:

Text: "John Smith's email is [email protected]"
→ Embedded as vector [0.23, -0.45, 0.67, ...]
→ PII encoded in embedding space

Semantic search can retrieve:
→ "Find contact for John Smith"
→ Returns chunks with PII
→ PII extractable from embeddings

Deletion Challenges:

GDPR right to erasure:
→ Must delete John Smith's data
→ But embeddings distributed across vector DB
→ No direct mapping: text → specific vectors
→ Cannot fully purge

PII Detection Complexity

False Negatives:

Regex patterns miss:
→ Nicknames: "Johnny" (instead of John Smith)
→ Obfuscated: "[email protected]"
→ International formats: "[phone]"
→ Contextual PII: "the CEO" (reveals identity in context)

False Positives:

Over-aggressive filtering:
→ "John Doe" (example name, not real)
→ "555-1234" (example phone)
→ "[email protected]" (generic)

Breaks legitimate content

---

How to Solve

Implement PII detection at ingestion (regex + NER models) + redact or exclude PII-containing chunks + apply user-level access control on retrieved chunks + use synthetic data for examples + audit retrieved context pre-generation + implement vector-level deletion for GDPR. See PII Protection.