Detecting and masking personal data before it reaches an LLM starts with a dedicated PII detection layer that scans every prompt in real time, combining pattern-based rules for structured identifiers such as national ID numbers, credit card numbers, and email addresses with a named-entity recognition model for less structured data such as person names, addresses, and organizations. Open-source tools such as Microsoft Presidio provide both approaches out of the box and can be self-hosted so the scanning itself never sends data to a third party. Once detected, personal data is typically replaced with a placeholder token before the prompt reaches the model, and if the application needs to restore the original values in the final response, a reversible tokenization scheme keeps a secure mapping table so detokenization only happens inside the trusted environment, never inside the model itself. Every redaction event should be logged for audit purposes, and the detection rules need regular tuning against real production prompts, since named-entity recognition models miss uncommon name formats and non-English text more often than teams expect. This masking layer should sit before the prompt leaves the organization's own infrastructure, particularly when the model is a third-party API rather than a self-hosted one. Nanobase AI builds PII detection and masking into the prompt pipeline for clients sending data to any external LLM provider.
Two detection techniques, and neither one alone is enough
Detecting personal data in a prompt before it reaches an LLM requires combining two fundamentally different techniques. Pattern-based detection uses regular expressions and validation rules to catch structured identifiers with a predictable format, such as national ID numbers, credit card numbers, email addresses, and phone numbers. Named-entity recognition uses a trained model to catch unstructured personal data that has no fixed pattern, such as person names, physical addresses, and organization names embedded naturally in free text. Relying on pattern matching alone misses names and addresses entirely, while relying on NER alone misses structured identifiers that a simple regex would catch instantly and reliably.
A practical detection and masking pipeline
| Stage | What happens | Example tooling |
|---|---|---|
| Pattern detection | Regex and checksum validation for structured identifiers | Custom rules, or Presidio's built-in recognizers |
| Named-entity recognition | ML-based detection of names, addresses, and organizations | Presidio with spaCy or transformer-based NER models |
| Confidence scoring | Each detected entity assigned a confidence score | Presidio's analyzer output |
| Masking or redaction | Replace, tokenize, or generalize detected entities | Presidio's anonymizer, or custom tokenization logic |
| Reversibility decision | Determine whether masked data needs to be restored later | Tokenization with a secure lookup table, or irreversible redaction |
Microsoft's open-source Presidio project implements the first four stages out of the box and can be self-hosted, keeping the entire detection pipeline inside the company's own infrastructure rather than sending prompts to a third-party PII detection API before they even reach the main LLM. Self-hosting the detection layer itself matters, since routing prompts through an external PII API before masking defeats much of the purpose of masking in the first place.
Choosing between redaction, masking, and tokenization
Redaction removes the detected entity entirely, replacing it with a generic placeholder like "[PERSON]," which is simplest but loses information the model might legitimately need for the task. Masking partially obscures the value, such as showing only the last four digits of an identifier, useful when partial context genuinely helps the model's response. Tokenization replaces the real value with a reversible token mapped in a secure lookup table, allowing the original value to be restored in the final output for the calling application while the LLM itself never sees the real data. Tokenization is generally the strongest option for applications that need to preserve full functionality while keeping raw personal data out of the model's context and any downstream logs.
- Run pattern-based detection first, since it is fast and highly reliable for structured identifiers.
- Run NER-based detection on the remaining text to catch names, addresses, and other unstructured personal data.
- Apply tokenization for identifiers the application needs to reference later, and redaction for identifiers that add no value to the model's task.
- Log only the masked or tokenized version of the prompt, never the raw version, if logs are retained beyond the immediate request lifecycle.
- Periodically audit detection accuracy against a labeled sample, since NER models can drift in accuracy as the application's actual language patterns evolve.
Where this pipeline commonly falls short
Detection accuracy is never perfect, and two failure modes recur across implementations: false negatives on names that resemble common words or that appear in unusual formatting, and false negatives on personal data embedded in uploaded documents or images rather than typed text, which requires OCR or document-parsing integration before the detection pipeline can even see the content. Building the masking layer as a mandatory gate before any prompt reaches the model, rather than an optional pre-processing step a developer can bypass, closes off the most common way these pipelines get silently skipped in practice. A masking pipeline that a developer can bypass with a direct API call provides no real protection, regardless of how accurate its detection is.
Frequently asked questions
Does masking PII before sending to an LLM satisfy GDPR on its own?
It significantly reduces exposure and supports the data minimization principle, but it does not replace the need for a lawful basis, a data processing agreement with the LLM provider, and a defined retention policy, covered together in our guide to making an LLM application GDPR compliant.
Can this pipeline run for languages other than English?
Presidio and most NER-based tools support multiple languages, though detection accuracy for unstructured entities like names varies by language and by how much training data the underlying NER model had for that language, so results should be validated per language rather than assumed to transfer evenly.
Does masking hurt the model's response quality?
It can, if entities the model needs for reasoning are redacted rather than tokenized. Choosing tokenization for identifiers that matter to the task, and redaction only for identifiers that do not, minimizes this tradeoff.
Should this run client-side or server-side?
Server-side is strongly preferred for reliability and to prevent the masking step from being bypassed, though a lightweight client-side check can provide faster user feedback for the highest-confidence pattern matches before the server-side pipeline runs its full analysis.
How Nanobase AI helps
Nanobase AI, a Silicon Valley-headquartered enterprise AI engineering company, builds PII detection and masking pipelines using tools like Presidio, integrated as a mandatory gate before prompts reach any LLM, whether commercial API or self-hosted model. This is part of our AI security and compliance practice, closely connected to the guardrail architectures we implement across the same client deployments.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.