Home/Blog/PII Detection in LLMs

PII Detection in LLM Applications:
Beyond Regex

Regex-based PII detection misses up to 40% of personally identifiable information in LLM outputs. Names in narratives, obfuscated contacts, and quasi-identifier combinations all slip through. Here's how to build detection that actually works.

July 11, 202610 min read

Why This Matters Now

1.LLMs memorize and regurgitate training data — including PII from public datasets.
2.Users paste sensitive information into prompts that gets logged and processed.
3.GDPR fines for PII mishandling reached €2.1B in 2025. Regulators are watching AI.
4.Enterprise buyers require PII controls before deploying AI-powered features.
5.A single PII leak in a customer-facing AI response can destroy user trust permanently.

The PII Detection Spectrum

Not all PII is created equal. Some types are easy to detect with patterns. Others require understanding context, combinations, and intent.

Direct Identifiers

Regex: High

Full namesEmail addressesPhone numbersSSN/National IDsCredit card numbers

Regex works for structured formats (SSN, credit cards). Fails for names in natural language context.

Quasi-Identifiers

Regex: Very Low

Age + ZIP code + genderJob title + company + cityMedical condition + provider

Not PII in isolation. Becomes identifying when combined. Requires contextual analysis.

Contextual Identifiers

Regex: None

"The CEO of Acme Corp""My neighbor on 5th Street""Patient in room 302"

Only identifiable in context. No pattern to match. Requires semantic understanding.

Embedded in Narratives

Regex: Low

PII woven into storiesData in code commentsContact info in generated emails

LLMs generate PII in varied formats and contexts. No single extraction pattern works.

Where Regex Fails: Real Examples

These are actual patterns from production LLM outputs where regex-only detection failed.

“My doctor, Sarah Chen at Mount Sinai, diagnosed me last Tuesday”

✗Missed: Sarah Chen (name), Mount Sinai (healthcare provider), medical context

⚠Names and providers don't match fixed patterns. Medical context makes this high-sensitivity PII.

“Contact me at rashid dot khan at gmail dot com or call five five five, twelve thirty-four”

✗Missed: Obfuscated email and phone number

⚠Humans naturally obfuscate. Regex only matches canonical formats.

“The 34-year-old software engineer from 94105 was involved in...”

✗Missed: Age + occupation + ZIP = quasi-identifier combination

⚠Individually harmless. Together, narrows to ~3 people in that ZIP code.

“As discussed in our meeting, John's performance review noted concerns about...”

✗Missed: Name + employment context = sensitive HR data

⚠The sensitivity depends on surrounding context (performance review), not the data format.

Building a Production PII Pipeline

Effective PII detection requires multiple stages, each catching what the previous missed.

Normalization

Convert obfuscated patterns to canonical form before scanning

✓Expand dot-separated emails (rashid dot khan → rashid.khan)
✓Convert spelled-out numbers to digits (five five five → 555)
✓Decode character substitutions (@ → at, # → number)
✓Normalize unicode homoglyphs and zero-width characters

Pattern Matching

Apply regex for well-structured PII types (first pass)

✓SSN, credit cards, phone numbers in standard formats
✓Email addresses, URLs with query parameters
✓Date of birth patterns, IP addresses
✓National ID formats (passport, driver's license patterns)

NER + Context Analysis

Named Entity Recognition to catch names, organizations, locations

✓Person name detection in natural language context
✓Organization names linked to individuals
✓Location data that narrows identity (address fragments)
✓Relationship terms that create linkable records

Sensitivity Scoring

Classify detected PII by risk based on context and combination effects

✓Single identifier vs quasi-identifier combination scoring
✓Context sensitivity (medical, financial, legal, employment)
✓Re-identification risk based on population size estimation
✓Regulatory classification (GDPR special category, HIPAA PHI, CCPA)

Action Enforcement

Apply the appropriate response based on policy and sensitivity

✓Block: reject the response entirely for critical PII leaks
✓Redact: replace PII with tokens ([NAME], [EMAIL], [PHONE])
✓Flag: log for human review without blocking (low-confidence detections)
✓Pass: allow through with audit trail for compliant contexts

Implementation with Overrule

Overrule's PII detection policy implements this full pipeline as a single policy you can attach to any governed LLM call:

from overrule import Guard

async with Guard() as guard:
    response = await guard.chat(
        model="gpt-4o",
        messages=messages,
        policies=["pii-detection"],
        policy_config={
            "pii-detection": {
                "action": "redact",      # block | redact | flag
                "sensitivity": "high",   # low | medium | high
                "types": ["all"],        # or specific: ["email", "phone", "name"]
            }
        },
    )

    # Output: "Contact [NAME] at [EMAIL] for..."
    # Original PII never reaches the user
    # Violation logged with redacted content for audit

The policy runs in the response path — after the model generates output but before it reaches the user. This catches PII the model generates from its training data, not just PII the user provides.

Regulatory Compliance Mapping

GDPR (EU)

Articles 5, 25, 32

Minimize processing of personal data. Implement data protection by design.

CCPA (California)

Sections 1798.100-199

Allow consumers to know what PII is collected. Provide opt-out of sale.

HIPAA (US Healthcare)

45 CFR 164.502

Protect PHI. Minimum necessary standard for use and disclosure.

EU AI Act

Articles 13-15

High-risk AI must be transparent about data processing and enable oversight.

Protect user data in every AI response

Add production-grade PII detection to your LLM application. Redact, block, or flag — your policy, enforced at runtime.

Get Started Free View SDK on GitHub

PII Detection in LLM Applications:Beyond Regex