PII Redaction for LLMs: Where, How and How to Test It

How do you redact PII before data reaches an LLM?

In short: decide where the control sits, detect personal data with more than one method, apply a defined operation to each match, handle files and structured data deliberately, and then measure and test the result continuously. Each step has trade-offs, and the sections below take them in order.

Two questions are covered elsewhere and are deliberately not repeated here. The choice between failing closed and failing open, and the four operations of mask, hash, tokenize and drop, are explained in our article on fail-closed PII redaction strategies. Read that first if you need to decide what happens when detection breaks.

Why redact PII at all?

Sending personal data to an external model provider is processing, and it carries the usual data protection duties: a lawful basis, purpose limitation, data minimisation and appropriate safeguards for any transfer (Regulation (EU) 2016/679). The simplest way to meet minimisation is to not send what the model does not need. A support summary rarely requires the real customer name, and a code review does not need production credentials.

Frameworks such as the NIST Privacy Framework frame this as managing privacy risk through data processing controls, and in the UAE the federal personal data protection law sets comparable expectations, so confirm the current text on the UAE government portal.

Where should you redact: client, gateway or provider?

There are three realistic placements, and they differ in coverage, control and operational cost.

• In the client. The application or browser removes personal data before anything is sent. This is closest to the source and works even if the network path is untrusted. The cost is duplication: every client needs the same detection logic and updates, and users can bypass a client you do not control.
• At a gateway. A proxy between your applications and every model provider inspects all requests and responses in one place. You maintain one policy, one detector set and one audit trail, and you can switch providers without touching applications. The cost is another component to run and a latency budget to manage.
• At the provider. Some providers offer their own filtering or data handling settings. These are useful as a second layer, but the data has already left your boundary, you cannot inspect how the control behaves, and the guarantees depend on a contract and a plan tier.

For most organisations a gateway is the primary control, with client side checks for obvious cases and provider settings as defence in depth. Browser based chat is a separate path that a server side gateway cannot see, so it needs its own control inside the browser session.

Which detection methods work best?

No single detector is enough. Strong systems layer several and accept that each has a characteristic weakness.

• Patterns and checksums. Regular expressions with validation catch payment card numbers (Luhn check), IBANs (mod 97), national identifiers, email addresses and phone numbers. They are fast and precise for rigid formats, and blind to anything free-form.
• Dictionaries and allow lists. Lists of known employees, customers, project names or internal hostnames catch values that patterns cannot, and an allow list suppresses false positives such as your own company name.
• Named entity recognition. Statistical or neural models find names, locations and organisations in free text. They handle context but make probabilistic errors, particularly on short prompts, unusual names and mixed languages.
• Context rules. A nine digit number next to the words account or passport is more likely sensitive than the same number in a build log.

Combine them with a confidence threshold per entity type. A low threshold for card numbers is sensible. A strict threshold for person names avoids turning every capitalised word into a placeholder and ruining the prompt.

Structured versus unstructured data

Structured data such as JSON, CSV rows and database exports is easier to handle. Field names tell you what a value is, so you can apply a rule by key (for example, redact every value under email or national_id) without running detection on the content. The risk is the free text column, such as notes or comments, which should be treated as unstructured.

Unstructured text depends on detection, which means it will sometimes miss. Design for that. Keep sensitive fields out of prompts by construction wherever you can, so the model only ever receives the columns it needs, and use content detection as the safety net rather than the only defence.

What about files, images and attachments?

Files widen the problem. A PDF, a spreadsheet or a slide deck must be parsed to text before detection, and the parser is part of your attack surface. Check these cases explicitly.

1. Embedded content such as headers, footers, comments, tracked changes, hidden sheets and metadata fields.
2. Scanned documents and images, which need optical character recognition before text detection, and which will be less accurate.
3. Archives and nested files, where a compressed attachment hides content from a shallow scan.
4. Size and format limits, with a clear rule for what happens to files you cannot parse. Unparseable should normally mean blocked, not passed through.

When do you need reversible redaction?

Irreversible redaction is simplest: the original value is gone. But some workflows need the real value back, for example when a model drafts an email that must address the actual customer. Reversible approaches replace each value with a stable placeholder, hold the mapping in a protected store under your control, and restore the originals in the response only for authorised callers.

Treat that mapping as sensitive data in its own right. Scope it to a session or tenant, encrypt it, expire it, and log every restoration. Note that pseudonymised data is still personal data under the GDPR, because the means of re-identification exist (Article 4(5)). The comparison of the four operations is in the fail-closed redaction article.

How do you test and measure redaction?

Redaction is a security control, so test it like one.

• Build a labelled test set from realistic but synthetic prompts, covering each entity type, each language you operate in and each file format you accept.
• Measure recall and precision per entity type. Recall tells you how much personal data slipped through. Precision tells you how much harmless text was masked unnecessarily. Report them separately, because a single accuracy figure hides the failures that matter.
• Add adversarial cases: spaced digits, homoglyphs, names split across lines, encoded strings and values embedded in code.
• Run the tests on every policy or detector change, as a regression gate.
• Track production signals such as redaction counts by type, blocked requests, detector errors and latency percentiles, and sample a small number of events for human review.

Be honest about limits. Redaction lowers risk; it does not guarantee that no personal data is ever sent. Pair it with minimisation, access controls and a review of what each model provider does with data. The OWASP Top 10 for LLM applications lists sensitive information disclosure among the risks to test against.

How Krasper helps

Krasper Raigate is a self-hosted AI governance firewall that detects and redacts PII in prompts and completions before they leave your governed perimeter, across text, structured data and documents, and logs each governed request as audit evidence. It sits at the gateway layer described above and also applies policy inside the browser session for common AI chat tools. Raigate supports your evidence for audits; it does not certify compliance.

For the policy decision behind it, including what to do when detection fails, see our article on fail-closed PII redaction strategies.