PII redaction for LLM prompts: methods, limits and how to measure them

As of 13 November 2026. General information, not legal advice. This guide describes methods; it gives no detection rates for any tool, because a rate measured on someone else's documents says little about yours.

What does PII redaction for LLM prompts actually do?

PII redaction finds personal details in text before it is sent to a language model and replaces or removes them. "PII" (personally identifiable information) is mostly a US term; in the EU the legal concept is "personal data", defined in Article 4(1) GDPR as any information relating to an identified or identifiable natural person, directly or indirectly.^[2] Detection tools usually look for a narrower list: names, addresses, account numbers, identifiers. Whatever the tool does not look for, it will not replace.

The task has two halves. Detection decides what is personal. Replacement decides what the model sees instead, and whether the original can be put back into the answer afterwards. Both halves can fail in different ways, so this guide first compares the methods, then looks at why German text is harder, then shows how to measure a tool on your own sample, and finally lists what redaction cannot do.

Which detection and replacement methods exist?

Five approaches cover most products and projects. They are not exclusive; a robust set-up usually combines several. The table says what each catches, what it tends to miss and where the mapping between original and replacement lives. The mapping matters legally and operationally: whoever holds it can reverse the replacement.

The open-source project Presidio, started at Microsoft, is an example of a toolkit that combines several of these. Its README describes it as a context-aware, pluggable and customisable PII de-identification service for text and images, with predefined or custom recognisers that use named-entity recognition, regular expressions, rule-based logic, checksums and surrounding context. The README also says that because detection is automated, Presidio cannot be relied on to find all sensitive information, and that additional systems and protections should be used.^[1] That statement applies to every automated tool in this table, not only to that project.

On-device masking in the browser is the approach Ainym takes: it is an extension in closed beta with pilot teams that detects personal data on the user's own device and asks the user to confirm every match before anything is sent. For how the approaches compare against buyer criteria, see PII masking tools for AI chats.

Placeholders or realistic surrogates?

Use placeholders when you value clarity, and surrogates when the text has to stay natural. A placeholder such as [PERSON_1] cannot be mistaken for a real person and makes it plain what was replaced. A surrogate such as an invented but plausible name keeps sentences readable, which can matter for letters, minutes or documents where tone and structure carry meaning.

Whichever you choose, three rules follow from how the mapping works. Replace the same value with the same stand-in throughout one document or conversation, otherwise the model cannot follow who did what. Keep the mapping outside the model provider's reach. And check that a surrogate is not accidentally the name of a real person your reader knows; invent from pools that do not collide with the real data. The step-by-step method for doing this by hand is described in Anonymise data before ChatGPT.

A terminology warning: "tokenisation" means two different things. In language models, tokens are the pieces of text the model reads. In data protection, tokenisation means replacing a value with a token that can be mapped back. This guide uses the second meaning only when it says so.

Why are names in German and other non-English text harder to find?

Detection models are shaped by the text they were trained on, and several features of German make names harder, which we state qualitatively here rather than with figures. In English, a capitalised word in mid-sentence is a strong hint that it is a name; in German every noun is capitalised, so that hint disappears. Compound words can hide names: a street name, a company name or a product name may be fused with common words into a single long word that the model does not recognise as containing a name. Many surnames are also ordinary words (occupations, colours, animals), so "a Baker" or "a Wolf" cannot be told apart from the noun without context. Names also change form in inflected text and appear in forms of address and titles that vary by country.

Similar issues arise in any language with a different naming tradition from the one the model mostly saw: given name and family name in another order, one-word names, transliterated names. The practical conclusion is not that a particular model fails, but that you should not assume that a tool tested on English text behaves the same way on yours. Test it on your own language and document types, using the recipe below, and look at misses by category.

How do you measure recall and precision yourself?

Recall answers "of all the personal data really in the text, how much did the tool find?". Precision answers "of everything the tool marked, how much was really personal data?". Recall protects you from leaks; precision protects you from useless text full of needless replacements. A tool can be strong on one and weak on the other, so always look at both.

In formula form, with TP for correct hits, FN for real personal data the tool missed and FP for text the tool marked although it is not personal data: recall = TP / (TP + FN), precision = TP / (TP + FP). No third party can give you these numbers for your documents; you measure them on a sample.

1. Collect a sample. Use 50 to 100 documents that look like the real ones you will send: e-mails, contracts, tickets, spreadsheets. Use invented or already cleared documents, and do not send real personal data to a service just to test it.
2. Write down the rules. Decide which categories count (person names, addresses, account numbers, dates of birth, organisations) and how to treat partial hits such as the surname only.
3. Annotate by hand. Have one person mark every real personal detail, and a second person check a subset. Disagreements show where your rules are vague.
4. Run the tool. Run it on the same documents, with the same settings you would use in daily work.
5. Count per category. For each category, tally correct hits, misses and false marks. Keep the lists of misses; they are more useful than any total.
6. Look at consequences. A missed account number matters more than an over-marked company name. Weigh the misses by what they would expose.
7. Repeat when something changes. New model version, new document type, new language: measure again on a fresh sample, because a tool tuned on one sample will look better on that sample than on the next.

Where does redaction sit in the chain, and what does it decide?

Redaction runs before the prompt leaves your device or network, and that placement is its value. After sending, you cannot observe where a provider processes, copies or stores the text. You rely on the provider’s documentation and contract, which describe their own exceptions, and on a chain of sub-processors that Article 28 GDPR permits under conditions.^[5] What has been sent cannot be recalled; a deleted chat or a changed setting acts on the future. A detector that runs locally therefore has a different risk profile from one that sends the text elsewhere first: the second adds a recipient you then have to examine in the same way.

What redaction can do is reduce what is exposed, which is why Article 32(1)(a) names pseudonymisation as a measure.^[10] What it leaves open is everything the detector misses, which is why the recall measurement below matters more than any claim, and why a human check before sending stays necessary. The provider side is set out in where your data goes when you use an AI assistant.

What can redaction not fix?

Redaction reduces what a provider receives. It does not decide three other questions.

The legal basis

Every processing of personal data needs a legal basis under Article 6(1) GDPR.^[4] The German data protection authorities say that each processing step with personal data in an AI application needs one.^[6] The Baden-Württemberg authority adds that anonymising is itself a processing operation that needs a legal basis.^[7] The redaction step is therefore part of your processing, not a way around it.

Quasi-identifiers and context

Pseudonymisation under Article 4(5) GDPR means data can no longer be attributed to a person without additional information that is kept separately and protected; pseudonymised data remains personal data where such information could attribute it to a person.^[2][3] Whether a person is identifiable depends on the means reasonably likely to be used.^[3] The DSK writes that removing names and addresses is regularly not enough, because the context can still make a person identifiable.^[6] A date, an amount, a rare job title and a small town can together point to one person, and no name detector sees that. The CJEU judgment in EDPS v SRB (C-413/23 P, 4 September 2025) held that pseudonymised data need not be personal data "in all cases and for every person", but it was decided under the regulation for EU institutions, looks at the means of the specific holder of the data, and does not change that the organisation holding the key still processes personal data.^[8] The EDPB's guidelines on pseudonymisation are, as far as we could find, still a consultation draft.^[9] The legal background is explained in Pseudonymisation vs anonymisation.

The provider contract

If an AI provider processes personal data on your behalf, Article 28 GDPR requires a binding contract, including processing only on documented instructions.^[5] Redaction does not replace it, and it does not tell you whether the provider uses inputs for training or where they are stored. Those questions are covered in Is ChatGPT GDPR compliant?. Pseudonymisation and encryption are named in Article 32(1)(a) GDPR as examples of security measures, scaled to risk; they supplement a contract and a legal basis, they do not stand in for them.^[10]

Next step

Pick 50 of your own documents, write down which categories you care about, and run the seven-step recipe on the method you are considering, looking at the misses per category before you look at any total. Then decide what the remaining human check has to cover, and write it into your AI policy. The terms used here are defined in the glossary.

This article is general information and not legal advice. It does not replace an assessment of your own case by your data protection officer or a lawyer. Last updated: 13 November 2026.