|Ben @ Grepture

PII Detection Best Practices for AI Pipelines

A practical guide to identifying and handling personally identifiable information in LLM requests and responses.

The PII problem in AI

When applications send prompts to large language models, they almost always include user-generated content — support tickets, form submissions, chat messages. This content frequently contains personally identifiable information that should never reach a third-party API.

The risk is not hypothetical. Customer names end up in model training data. Email addresses get cached in provider logs. Medical details from support conversations flow through APIs with no retention guarantees. Under GDPR and CCPA, sending unprotected PII to a third-party processor without proper controls is a compliance violation — regardless of whether the provider promises not to train on it.

What counts as PII?

PII includes any data that can identify an individual, directly or indirectly:

  • Direct identifiers: Names, email addresses, phone numbers, social security numbers, passport numbers, driver's license numbers
  • Quasi-identifiers: Dates of birth, ZIP codes, job titles, IP addresses (can identify when combined)
  • Sensitive data: Medical records, financial information, biometric data, racial or ethnic origin, religious beliefs

The EU AI Act and GDPR treat these categories differently, but the safest approach is to detect and handle all of them before data leaves your infrastructure.

Detection strategies

Pattern matching (the foundation)

Regular expressions catch structured PII like emails, phone numbers, and credit card numbers. They're fast, predictable, and run at proxy speed with zero external dependencies. A well-maintained regex library covers the majority of structured PII patterns.

For example, email detection is straightforward:

[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

Credit card numbers, phone numbers (with country code variations), SSN formats, and IP addresses all follow predictable patterns that regex handles well. Grepture ships with 50+ regex patterns out of the box (80+ on Pro plans), covering the most common structured PII, secret formats, and code fingerprints.

The big advantage of rules: every detection traces back to a specific pattern. When your compliance team asks "how do you ensure PII isn't sent to third-party AI providers?", you can point to an auditable, deterministic rule set — not a probability score from a model.

AI-powered detection (for what regex can't catch)

Here's the thing — regex is great at structured data, but some PII doesn't follow a pattern. Names in freeform text. Addresses woven into a paragraph. Company names that could be anything. This is where AI-powered detection fills the gap.

Grepture runs local AI models on our infrastructure to detect:

  • Person names — first names, last names, full names in natural language
  • Locations — cities, countries, addresses in unstructured text
  • Organizations — company names, institutions

The key detail: these models run on Grepture's servers, not on some external API. Your data doesn't get forwarded anywhere else in the process of protecting it. That would kind of defeat the purpose.

Beyond PII: other threats worth detecting

While you're scanning traffic, there are a few other things worth watching for:

  • Prompt injection — adversarial inputs designed to hijack model behavior. Grepture scores requests for injection risk and can block or log them. See our prompt injection prevention guide for a deep dive.
  • Toxicity — toxic, threatening, or hateful content. Useful if your users interact with AI features directly.
  • Data loss prevention (DLP) — source code, credentials, internal documents, and financial data that shouldn't leave your network.
  • Compliance domain flagging — healthcare (HIPAA), financial (KYC/AML), legal (privileged communications), and insurance data that may trigger regulatory requirements.

Rules and AI: complementary, not competing

We're sometimes asked: rules or ML? The honest answer is both, and they're good at different things.

Rules give you:

  • Transparency — every detection traces to a specific pattern
  • Auditability — you can enumerate exactly what's covered
  • Determinism — same input, same result, every time
  • Speed — sub-millisecond per rule, no warm-up, no model hosting

AI gives you:

  • Freeform detection — catches names, locations, and entities that don't follow patterns
  • Semantic understanding — recognizes PII by meaning, not just format
  • Threat detection — prompt injection and toxicity aren't pattern problems

Use rules as your baseline — they're fast, cheap, and cover most structured PII. Layer AI on top for the stuff regex misses. That's how Grepture is designed to work, and it's what we'd recommend for any detection pipeline.

Handling detected PII

Once detected, you have several options:

  • Redact: Replace with placeholder tokens ([REDACTED]). The LLM processes the prompt without real PII. Clean and simple.
  • Mask: Partially obscure (j***@example.com). Useful when the LLM needs to understand the data type but not the actual value.
  • Mask and restore: Replace with secure tokens, store originals in a vault with a TTL, and swap them back into the response. The LLM never sees the real values, but your application gets complete data back. Best of both worlds. Learn more in our mask and restore deep dive.
  • Block: Reject the entire request. Best for high-sensitivity scenarios where any PII exposure is unacceptable.
  • Log: Allow through but record for audit. Useful during initial rollout to understand what PII flows through your system before enforcing strict policies.

The right choice depends on your use case. Most teams start with logging to get visibility, then progressively tighten policies as they understand their data flows. If you're not sure where to start, log everything for a week and review what you find — it's almost always more than you expect.

Building a detection pipeline

A practical PII detection setup for AI pipelines should follow this order:

  1. Inventory your data sources — Identify every input that feeds into LLM prompts. User messages, database records, file contents, internal docs.
  2. Classify sensitivity levels — Not all PII requires the same treatment. A name in a public bio is different from a SSN in a financial record.
  3. Deploy detection at the proxy layer — Catching PII at the network level means every AI call is protected, regardless of which team or service made it. No per-service integration work.
  4. Start with logging, then enforce — Run in observe mode first. Understand your baseline before blocking requests. The playground in Grepture's dashboard is great for testing rules against real-looking traffic before you flip them on.
  5. Layer in AI detection — Once your regex rules are solid, enable AI-powered detection for names, locations, and entities that slip through pattern matching.
  6. Monitor and tune — Review detection logs regularly. Add custom rules for patterns specific to your data. Check for false positives and adjust thresholds.

Compliance considerations

GDPR, CCPA, and the EU AI Act all impose requirements on how personal data flows through AI systems. Automated PII detection is quickly becoming a baseline expectation. For a developer-focused breakdown of the EU AI Act's August 2026 deadline, see our EU AI Act compliance guide.

Key requirements to be aware of:

  • GDPR Article 5 — Personal data must be processed lawfully, with purpose limitation and data minimization
  • GDPR Article 28 — Processors (including AI providers) must provide sufficient guarantees of appropriate technical measures
  • EU AI Act Article 10 — Training and validation datasets must be subject to appropriate data governance
  • CCPA Section 1798.100 — Consumers have the right to know what personal information is collected and shared

Build detection into your pipeline from day one — retrofitting is always harder. Grepture makes this straightforward with drop-in SDK integration, 50+ built-in regex patterns (80+ on Pro), and AI-powered detection for the things patterns can't catch.