When teams first think about PII protection in AI pipelines, they tend to reach for the most obvious solution: block requests that contain sensitive data. A user mentions an email address or a social security number, the request gets rejected, and the data never reaches the model.
Clean. Simple. And terrible for the user experience.
The right approach is not to block requests containing PII. It is to protect the data in transit while preserving the experience on both ends.
The problem with naive blocking
Blocking PII-containing requests creates a category of things your AI system simply cannot help with, and that is often exactly the category where users need help most.
A healthcare AI assistant that cannot discuss patient symptoms. A financial AI that cannot reference account numbers. A legal AI that cannot process documents containing names. These are not edge cases. They are the core use cases.
The problem is not that sensitive data is in the request. The problem is that sensitive data should not leave your infrastructure in clear text, and it should not be stored in third-party model provider logs. Both of those are solvable without blocking the request.
Redact, execute, rehydrate
The pattern that works in production is redact-execute-rehydrate.
Step 1: detect and redact before execution. Before the request reaches any external model, scan it for PII. Replace each detected entity with a structured placeholder: [PERSON_NAME_1], [EMAIL_1], [SSN_1]. Store the mapping between placeholder and real value in a secure, ephemeral store scoped to that request. The request that leaves your infrastructure contains no real PII, only placeholders.
Step 2: execute normally. The model receives the redacted request. It processes the placeholders as if they were real values. It generates a response referencing the same placeholders. From the model's perspective, nothing unusual is happening.
Step 3: rehydrate after execution. The model's response comes back with placeholders intact. Before returning it to the user, replace each placeholder with the original value from the mapping. The user sees a response that references their actual data. The model never saw it. Third-party logs contain only placeholders.
The user experience is identical. The data protection is real.
What to detect
A production PII detection layer should cover at minimum: direct identifiers (names, email addresses, phone numbers, physical addresses); government identifiers (SSNs, passport numbers, driver's license numbers, tax IDs); financial data (credit card numbers, bank account numbers, IBANs); health data (diagnoses, medication names in context, patient IDs); and credentials (API keys, passwords, tokens, which are both PII and security risks).
Detection quality matters more than theoretical coverage. A system that catches 90% of PII reliably is more useful than one that claims 100% coverage but generates false positives that break legitimate requests. False positives are the biggest operational problem with PII detection in production: a pattern that is too aggressive will redact things that are not sensitive and produce responses that read as broken.
Tuning for false positives
Good PII detection is configurable per tenant and per context. A financial services tenant needs aggressive financial identifier detection. A general-purpose assistant needs more conservative thresholds. A healthcare platform needs PHI detection tuned to its specific data patterns.
Start conservative and tune based on real traffic. Instrument your detection layer to surface candidates it was uncertain about. Review them periodically. Adjust thresholds per tenant. The tuning work is ongoing. Data patterns change, and detection quality degrades silently if you do not maintain it.
Audit without creating new exposure
Your audit trail needs to record that PII was detected and handled, without storing the PII itself. This is a requirement that often gets overlooked, and it matters most for HIPAA and GDPR contexts where storing sensitive values in audit systems creates its own compliance obligations.
Audit records should log that PII was detected in the request, which types were found (categories, not values), that redaction occurred, and the request outcome. They should not log the actual sensitive values, even in the audit system.
A useful minimum log structure:
request_id
tenant_id
pii_detected: true/false
pii_types: [email, phone, id_number]
redaction_applied: true/false
policy_decision: allow / block / review
timestamp
Detection vs. redaction
It is worth being precise about the distinction, because it matters operationally. PII detected means the system found sensitive data in the request. It does not say what happened to it. PII redacted means the system found sensitive data and replaced it with a placeholder before the request was forwarded.
Both generate audit events. But only "redacted" guarantees the data did not reach the model. Detection without redaction is a monitoring tool. Detection with redaction is protection. Your metrics and your audit reporting should distinguish between the two clearly; otherwise you cannot tell whether your pipeline is actually protecting data or just observing it.
Where to start
Enable PII redaction in observation mode on real traffic first. Review false positives by type and tune thresholds per tenant before switching to enforcement. Move to enforcement only when the false-positive ratio is under control for each tenant's traffic pattern.
This is not a one-time setup. Treat PII detection quality as an ongoing operational metric, not a checkbox. The teams that do this well review their detection precision monthly and treat false-positive spikes as incidents worth investigating.