It depends on how you mask. Blank redaction removes the clues the model reasons with. Consistent, typed tokens keep who is who, so answers stay close to the original.
SOC 2 Type II · ISO 27001 · Works with any LLM provider
Same model, same prompt
“Who should we call before the renewal?”
[REDACTED]
Wrong“The notes do not say.”
[PERSON]
Which one?“Call [PERSON] before Dec 1.”
Protecto tokens
Matches“Call Daniel Osei before Dec 1.” Real name restored for approved users only.
Masking PII can reduce LLM accuracy, but most of the loss comes from how the data is masked, not from masking itself. Independent research and our customer results point the same way.
When every name becomes [REDACTED], the model cannot tell people apart or link an action to the right person. It guesses, and the answer reads fine but is wrong.
[PERSON] keeps the sentence shape. Two different customers become the same word, and the answer cannot be mapped back to the right name.
Each person, email or account gets its own token, the same one every time. The model keeps who did what, and approved users see the real values in the answer.
Amounts, dates, product names and diagnoses often carry the answer and identify no one on their own. Mask what identifies a person, by policy, and leave the rest readable.
Run the same prompts on original and masked text and compare the answers. With Protecto, Bank Muscat scored 85% on RARI, our accuracy metric, with 99% recall and 96% precision on sensitive data.
Bank Muscat let employees use AI on sensitive data with Protecto masking prompts in the path
RARI score on masked prompts, our accuracy metric, with 99% recall and 96% precision (Bank Muscat)
Live enterprise tenants protected, each with its own policy (Automation Anywhere)
Long texts masked per day for AI use (SaaS company)
A customer success team asks an AI assistant to prepare renewal calls from account notes. The notes hold names and emails, so they are masked before they reach the model.
The question is simple: “Who should we call before the renewal, and when is it?” The right answer is Daniel Osei, before Dec 1, because Priya is away. Switch the views to see what the model receives and how it answers each time.
Same model, same prompt. Only the masking changed. With Protecto, the model never saw a real name or email, and its answer matched the answer on the original notes.
Renewal notes, masked three ways
Question: Who should we call before the renewal, and when is it?
Account notes in the CRM (fictional)
Priya Nair (priya.nair@northwind.io) asked for a refund on Oct 3. Her colleague Daniel Osei approved the upgrade on Oct 10 and wants a call before the renewal on Dec 1. Priya is out until Nov 20.
Model’s answer: Call Daniel Osei before the renewal on Dec 1. Priya is out until Nov 20.
What the model receives after blank redaction
[REDACTED] ([REDACTED]) asked for a refund on [REDACTED]. Her colleague [REDACTED] approved the upgrade on [REDACTED] and wants a call before the renewal on [REDACTED]. [REDACTED] is out until [REDACTED].
Model’s answer: The notes do not say who to contact or when the renewal is.
What the model receives with generic placeholders
[PERSON] ([EMAIL]) asked for a refund on Oct 3. Her colleague [PERSON] approved the upgrade on Oct 10 and wants a call before the renewal on Dec 1. [PERSON] is out until Nov 20.
Model’s answer: Call [PERSON] before the renewal on Dec 1.
Three mentions share one label, so nobody can tell whether that means Priya or Daniel.
What the model receives with Protecto in the path
<PERSON>Kx7 Wq2</PERSON> (<EMAIL>0gN3SkjL@0ffM3CDS</EMAIL>) asked for a refund on Oct 3. Her colleague <PERSON>Rb4 Tn8</PERSON> approved the upgrade on Oct 10 and wants a call before the renewal on Dec 1. <PERSON>Kx7 Wq2</PERSON> is out until Nov 20.
Model’s answer: Call <PERSON>Rb4 Tn8</PERSON> before the renewal on Dec 1. <PERSON>Kx7 Wq2</PERSON> is out until Nov 20.
Account manager sees: Call Daniel Osei before the renewal on Dec 1. Priya Nair is out until Nov 20.
Marked values identify a person. The dates do not.
The tool removed the dates too, so the answer was lost with the names.
The sentence shape survives, but the model cannot say which person it means.
The model never saw a real name or email. A user without permission sees the same answer with tokens. Example tokens are illustrative.
Two recent studies tested masked prompts against the originals. Both found the method matters more than the masking.
Reversible beats irreversible. Researchers ran five LLMs on eleven benchmarks with original and anonymized inputs. Anonymization generally lowered scores, and a retrieval benchmark fell hardest, by 30 to 60 points for most models. Methods that kept a separate, unique stand-in for each person held up better than redaction or generalization. Telling the model the data was anonymized did not help (Deußer et al., arXiv, September 2026).
Small loss when done well. A study of personal writing tasks masked 97% to 99% of entities and lost about one point of answer quality on a ten-point scale. The best method varied by model (Pasch and Cha, PrivateNLP 2025).
For a CTO, the risk is not masking. It is blank masking that quietly turns correct answers into confident wrong ones, which no error log will catch.
A model answers from patterns in the text. Blank masking removes three of them.
Who is who. Answers about people depend on telling them apart. When every name is the same blank, “she approved it” could point to anyone, and the model picks one.
What kind of value it is. A card number masked to XXXX no longer looks like a card number, so a tool or agent step that checks the format fails or skips it. Format-preserving tokens keep the shape.
What matters to the task. Over-masking removes dates, amounts and product names that identify no one. The answer was in them.
Six common ways to mask personal data in prompts, scored only on what they do to the answer.
| Approach | Keeps who is who | Keeps format for tools | Same token across prompts and sessions | Real values back for approved users | Typical effect on answers |
|---|---|---|---|---|---|
| Blank redaction[REDACTED] | No | No | No | No | Largest loss. Wrong or “not found” answers on questions about people |
| Partial masking***-**-1234 | Basic. Only when the visible part differs | Basic | No | No | Fine for display. Loses the value for any step that needs it |
| Generic placeholders[PERSON] | No. Every person shares one label | No | No | No. Answers cannot be mapped back | Sentence shape kept, people merged |
| Numbered placeholders per request[PERSON 1], [PERSON 2] | Yes, within one prompt | No | No. Numbering restarts per request | Basic. Your app keeps the map | Good within one prompt. Breaks across chat turns, agents and stored documents |
| Rewrite or generalize“a customer in Ohio” | Basic | Not available | No | No | Good for text that is sensitive as a whole, such as deal terms. Loses exact values. Protecto does this through CBAC |
| Protecto consistent tokens<PERSON>Kx7 Wq2</PERSON> | Yes | Yes, format-preserving for structured values | Yes. The same value always gets the same token, in any session | Yes, unmasked by role. Others keep seeing tokens | Closest to the original. 85% RARI score at Bank Muscat |
Whatever you choose, run your own prompts on masked and original text and compare the answers before you trust it.
Protecto masks what identifies a person, keeps what the task needs, and restores real values only for people allowed to see them.
Protecto’s agentic detection and classification engine labels each value by type across 50+ entity types (PII, PHI, PCI) plus your custom entities. A missed name leaks; an over-masked word costs accuracy.
Mask names, emails and account numbers. Leave dates, amounts or product names readable when the task needs them. For text that is sensitive as a whole, Context-Based Access Control (CBAC) rewrites it so the model keeps the meaning without the detail.
The same value always gets the same token, in any prompt, session or agent step. Structured values keep their format, so downstream tools still accept them.
Any LLM provider. The model reasons over who did what without seeing real values. Protecto runs in front of assistants, RAG and agents, and in pipelines through Snowflake, Databricks, Kafka or Spark.
Approved users get the answer with real values; everyone else sees tokens. Compare answers on masked and original text with RARI, our accuracy metric, and tune the policy where the score drops.
<PERSON>Rb4 Tn8</PERSON> before the renewal on Dec 1.It can. Blank redaction and generic placeholders remove the clues a model uses to tell people apart, so answers about people get worse. Consistent, typed tokens keep most of the accuracy. With Protecto, Bank Muscat scored 85% on RARI, our accuracy metric.
Usually, yes. A token stands in for one specific value, so the model can still follow who did what. Independent research found that methods keeping a unique stand-in per person held up better than redaction or generalization.
Send the same prompts with original and masked text, restore the masked answers, and compare them to the original answers. Our accuracy metric, RARI, scores that similarity; Bank Muscat scored 85%. Use your own prompts, since the effect varies by task and model.
No. Over-masking is an accuracy problem. Mask values that identify a person, such as names, emails and account numbers. Keep dates, amounts and other task details readable when they identify no one on their own. Protecto sets this as a policy per entity type.
Blank masking often does, because a question about a person can no longer be matched to that person’s documents or tool results. Protecto gives the same value the same token everywhere, so a tokenized question still finds the tokenized records about that person.
Token masking does not fit there, because the whole sentence is the secret. Protecto’s Context-Based Access Control (CBAC) rewrites that text so the model keeps the meaning, such as “an acquisition is under review”, without the confidential detail.
No. The model sees tokens. Real values are restored in the answer only for users whose role allows it. Everyone else sees the tokens.
No. Tokens are pseudonyms, and whoever holds the mapping can reverse them. Tokenization lowers exposure to the model provider. It does not make the data anonymous under laws such as GDPR.
Bring a set of real prompts. We will mask them with Protecto, run them on your model, and compare the answers with the originals.