PII Detection

Modern PII detection moves beyond static regex patterns to transformer-based NER models that understand linguistic context. This prevents false positives where a common word matches a pattern (e.g., 'May' as a month vs. a name) and catches unformatted sensitive data.

• Regex-only failures: Misclassifies '3B' as a credit card or 'Dr. Smith' as an address.
• Contextual models: Distinguish 'John saw a bat' (animal) from 'John swung a bat' (object).
• Entity types detected: Names, addresses, SSNs, credit cards, IBANs, medical record numbers, and custom entity types defined by the enterprise.

Two primary strategies exist for handling detected PII. Redaction permanently removes the text span, replacing it with a placeholder like [REDACTED]. Masking replaces the value with a realistic but fictitious surrogate to preserve data structure for the LLM.

• Redaction: SSN: [REDACTED] — safest, but may break prompt formatting.
• Masking: SSN: 123-45-6789 → SSN: 000-00-0000 — preserves format, useful for SQL generation.
• Tokenization: Replace with a reversible token that maps back to the original value in a secure vault for downstream systems.

PII detection can be positioned at two critical points in the RAG pipeline. Post-retrieval detection scans chunks after they leave the vector store but before they enter the model prompt. Pre-LLM guardrails act as a final safety net, scanning the fully assembled context window.

• Post-retrieval: Catches PII in retrieved documents before prompt assembly.
• Pre-LLM: Final scan of the complete prompt, including user query and system instructions.
• Defense-in-depth: Both layers should be implemented for zero-trust architectures.

Enterprise environments require detection beyond standard PII types. Organizations must define custom entity types like project code names, internal revenue figures, or proprietary chemical formulas. Policy engines then apply different actions per entity type and user role.

• Custom regex + dictionary: Combine pattern matching with internal term lists.
• Policy examples: 'Redact all SSNs for external users, mask for internal analysts.'
• Entity linking: Connect detected entities to a data catalog for lineage tracking.

PII detection adds latency to the retrieval pipeline. Streaming detection processes text as it arrives, and batch processing scans multiple chunks in parallel. Model quantization and ONNX runtime deployment reduce the overhead of NER models.

• Streaming: Begin redaction before the full document is retrieved.
• Batch: Process multiple chunks simultaneously on GPU.
• Caching: Cache detection results for frequently accessed chunks to avoid redundant scanning.

PII detection in RAG must integrate with existing Data Loss Prevention (DLP) infrastructure. Every detection event should generate an immutable audit log entry capturing the user identity, the specific entity type detected, the action taken, and the document source.

• SIEM integration: Stream detection events to Splunk, Datadog, or Elastic.
• Compliance: Supports GDPR 'right to erasure' and CCPA data subject access requests.
• Alerting: Trigger real-time alerts on anomalous PII access patterns.

A data obfuscation technique that replaces sensitive information in retrieved text with realistic but fictitious data before it is presented to the language model. Unlike redaction, masking preserves the semantic structure of the original text, allowing the LLM to understand the context without accessing the actual PII.

• Format-preserving masking: Replaces a real SSN (123-45-6789) with a structurally valid but fake SSN (987-65-4321)
• Tokenization: Substitutes sensitive values with non-sensitive placeholder tokens that can be reversed by authorized systems
• Dynamic masking: Applies different masking rules based on the user's role or clearance level

The permanent removal or blacking out of sensitive text spans from a document chunk during post-retrieval processing. Redaction is irreversible and ensures that the generation model never sees the original sensitive content.

• Pattern-based redaction: Uses regex to identify and remove structured PII like credit card numbers or email addresses
• NER-driven redaction: Leverages named entity recognition models to locate and remove unstructured PII such as names and locations
• Bounding box redaction: Applied to visual documents where PII regions are physically obscured in images or PDFs before OCR processing

A fine-grained authorization mechanism that masks or redacts specific sensitive fields within a retrieved document before it is passed to the large language model. Unlike document-level security, which blocks entire files, field-level security allows the retrieval of non-sensitive portions while protecting PII at the attribute level.

• Schema-driven enforcement: Security policies are defined at the data schema level, specifying which fields contain PII
• Conditional access: Fields may be visible to some roles but masked for others based on ABAC or RBAC policies
• Integration with DLP: Field-level rules often sync with enterprise Data Loss Prevention systems to ensure consistent PII handling

An authorization technique where initial search results are re-ranked or redacted after the vector similarity search completes. This security layer inspects the full text of retrieved chunks and applies PII detection models to strip out sensitive content before the prompt is assembled.

• Two-phase architecture: Retrieval runs unrestricted for maximum recall, then a security filter removes unauthorized or sensitive content
• PII confidence thresholds: Configurable sensitivity levels determine whether a detected entity is masked, redacted, or allowed through
• Latency considerations: Post-retrieval PII scanning adds computational overhead and must be optimized for real-time RAG applications

A strategy for monitoring and blocking the exfiltration of sensitive corporate data by inspecting the content of prompts and the context retrieved for RAG generation. DLP systems integrate with PII detection to prevent regulated data from leaving the enterprise boundary through model inputs or outputs.

• Content inspection: Scans both user prompts and retrieved documents for PII patterns before transmission to external LLM APIs
• Policy-based blocking: Automatically rejects queries that would retrieve documents containing PHI, PCI, or other regulated data classes
• Egress monitoring: Tracks what data is sent to third-party model providers to ensure compliance with data residency requirements

Programmable safety and policy filters that sit between the retrieval engine and the LLM to validate outputs, block toxic content, and enforce enterprise compliance rules. PII detection is often implemented as a specific guardrail that scans both input context and generated output for sensitive data leakage.

• Input guardrails: Validate that retrieved context does not contain unredacted PII before prompt assembly
• Output guardrails: Scan model responses for hallucinated PII that the model may have generated
• Orchestration frameworks: Tools like NeMo Guardrails or Guardrails AI allow declarative definition of PII detection rules as part of the RAG pipeline