How to mask PII before sending data to an LLM.
PII masking for LLMs replaces personal and business-sensitive values before prompts, documents, CRM records or application data reach an external model. A reliable implementation preserves task context, validates the response and restores approved values only inside the customer environment.
Eight implementation steps
- Define the boundary. Document which application data may reach the external model and which data must stay customer-side.
- Classify sensitive data. Include direct PII, account data, internal identifiers and business-specific combinations.
- Detect values in context. Combine structured patterns, dictionaries, entity detection and application rules where appropriate.
- Choose a replacement method. Redact, generalise, tokenize or use controlled pseudonyms according to the task.
- Preserve reference consistency. Repeated mentions may need the same substitute so the model can follow the request.
- Send only masked content. Check prompts, attachments, metadata, tool parameters and logs, not just the visible message.
- Validate the returned result. Bind the response to the active request and apply the restoration policy.
- Test and monitor. Measure false positives, missed values, model utility and restoration failures against realistic customer-side samples.
Where PII masking goes wrong.
Using regex as the complete solution
Regular expressions help with structured values such as phone numbers and account formats. They do not reliably identify contextual names, project references or indirect combinations that become sensitive in a particular workflow.
Masking so much that the model loses the task
Replacing every entity with the same token can destroy relationships that the model needs. Substitute design must preserve the minimum useful structure without exposing the original values.
Protecting the prompt but leaking through metadata
Files, tool calls, traces, cache keys and logs can contain the same values as the prompt. The protected boundary must cover the complete external call path.
Restoring without validation
A response should not automatically receive original values. The implementation should confirm that the result belongs to the active request and that restoration is allowed for that output and destination.
Why Herkus delivers this as a custom service
The difficult work is not adding one masking function. It is identifying application-specific data, handling exceptions, maintaining reference consistency, connecting the model provider, testing model usefulness and defining safe restoration. Herkus configures and integrates that complete path with the customer team.
Frequently asked questions
Is a regular expression enough for PII masking?
Regular expressions are useful for structured patterns, but they can miss contextual identifiers and create false positives. Production masking usually needs several detection methods plus application-specific rules and tests.
Should masked values be consistent within one prompt?
Yes when the model must understand that repeated mentions refer to the same person, account or organisation. Consistent substitutes can preserve that relationship without exposing the original value.
Where should restoration happen?
Restoration should happen inside the customer-controlled application path after the returned result is validated and the active policy allows restoration.
Related: what AI data masking means · customer-side AI data masking · Herkus AI Data Masking
Test the complete masking path on one real workflow.
Herkus works through the rule design, integration edge cases and validation with your technical team.
Please do not send production data, credentials or sensitive samples by email.