PII Anonymization Models in 2026: What Actually Works

Regex is boring. You still probably need it.

For structured identifiers, regular expressions remain difficult to beat. Credit-card numbers, IBANs, national identifiers, email addresses and other values with relatively predictable structure can often be detected cheaply and deterministically. Checksums make this even stronger: Luhn validation can help distinguish plausible payment-card numbers, while IBANs can be validated using their checksum rather than trusting the pattern alone.

The nice thing about this layer is that there is almost no mystery. You can inspect the rule. You know why it fired. You can test the weird edge cases. It is fast enough to run almost everywhere.

Its weakness is equally obvious: regex understands structure, not meaning.

• 4111 1111 1111 1111 looks like a card number because of its structure.
• "Send the documents to my daughter at the house behind the pharmacy" requires a completely different kind of reasoning.

This is why regex is useful as a layer rather than a complete anonymization strategy.

Presidio is better thought of as infrastructure than as a model

Microsoft Presidio is one of the most useful open-source building blocks in this space because it does not assume that PII detection has to come from one mechanism. Its analyzer can combine recognizers using patterns, checksums, NLP models and custom logic, and the anonymizer then applies transformations to the spans that were detected.

That architecture has aged well.

What I would not do is treat the default configuration as an accuracy benchmark. Presidio deliberately allows the underlying NLP engine and recognizers to be replaced or extended. The framework itself even documents using transformer-based PII models alongside its existing recognizers.

So "Presidio versus transformer X" is often the wrong comparison. In a real system, Presidio can be the orchestration layer around transformer X.

This becomes especially important outside English. Presidio ships predefined recognizers, but coverage varies considerably by entity and locale, and custom recognizers are part of the intended design.

GLiNER made open-ended entity detection much more interesting

Traditional NER has an annoying property: the entity taxonomy is usually baked into training. If your model was trained to find people, organizations and locations, asking it tomorrow to detect "customer account aliases" is not necessarily useful.

GLiNER took a different direction. It made entity categories something you can describe, which made zero-shot and low-data extraction much more practical.

That is particularly attractive for privacy because PII is not one clean taxonomy. It changes by country, industry and application. A hospital, a gaming platform and a financial application may all say they detect PII while meaning quite different things.

The research has now moved beyond generic GLiNER models. In May 2026, GLiNER2-PII introduced a 0.3B-parameter model specifically adapted to 42 PII entity types and reported the strongest span-level F1 of the five systems evaluated on the SPY benchmark.

There are also domain-specific examples showing how far specialization can go. One 2025 clinical study fine-tuned GLiNER for psychiatric records and reported a micro-F1 of 0.98 on its own evaluation set, substantially above the other systems it tested.

That number is impressive. It is also a good example of why PII benchmarks need to be read carefully.

A 0.98 F1 and a 0.14 F1 can both be true

This is probably the most important thing to understand about the current PII-detection literature.

In April 2026, PIIBench combined ten public datasets into a much broader benchmark covering 48 normalized PII types. Eight existing systems were evaluated.

Every system scored below 0.14 span-level F1. Presidio was the strongest baseline at 0.1385.

At first glance that seems incompatible with papers reporting F1 scores around 0.9 or higher. It isn't. They are measuring different problems.

A specialized model evaluated on data similar to its training domain can perform extremely well. A model thrown across languages, domains, annotation conventions and rare entity categories is solving a substantially harder generalization problem.

So I would be suspicious of any PII product whose main argument is simply:

"Our F1 is 97%."

My next questions would be: on what data, which entities, which languages, what matching criterion, and how similar is that dataset to mine?

For privacy systems, the benchmark is not the product. Your traffic is the benchmark.

Roblox is one of the more useful production case studies

There are relatively few public descriptions of PII detection operating at genuinely large scale, which is why Roblox's 2025 release is worth looking at.

Their problem is slightly different from classical redaction. Roblox is not only trying to find literal spans such as phone numbers. It also wants to identify conversations in which users are trying to exchange or solicit PII, including deliberately obfuscated attempts.

Roblox fine-tuned an XLM-RoBERTa-Large encoder for this task.

Those numbers are impressive, but the context is essential. This is a classifier optimized against Roblox's definition of PII-related conversation, trained using its own labeled production data and synthetic examples. It should not be interpreted as "XLM-RoBERTa gets 98% recall on PII."

The real lesson is more useful anyway. A model becomes dramatically better when the detection problem, training data and production traffic actually match.

That is less exciting than discovering a universal PII model, but much more actionable.

What about using an LLM?

You can ask an LLM to redact PII directly. Sometimes it works extremely well.

LLMs are particularly attractive when the sensitive information is contextual rather than structurally obvious. They can reason about phrases and relationships that a regex will never understand.

Research on LLM-based PII redaction is active, including work comparing redaction quality, semantic preservation, leakage, latency and computational cost.

But putting a large autoregressive model in front of every other model request is usually an expensive architecture. You have increased latency, increased inference cost, introduced another model whose behavior has to be evaluated, and — if it is an external API — potentially created the exact data-sharing problem the redactor was meant to solve.

That doesn't make LLM-based detection useless. It makes it a tool I would use selectively rather than blindly.

The architecture I find more convincing is a cascade

The strongest practical design is increasingly not "which detector should we choose?" but "which detector should handle each class of uncertainty?"

Start cheap. Use deterministic rules for things that genuinely have deterministic structure. Then use a contextual NER or encoder model for names, addresses and other ambiguous entities. Add domain-specific detectors where the cost of a miss justifies them. And evaluate the union of the system against representative traffic.

structured validation
→ contextual detection
→ domain-specific detection
→ entity-resolution / pseudonymization
→ policy
→ audit

Hybrid approaches are already producing interesting results. A multilingual study published in 2025 found that its combined method substantially improved weighted recall over standalone NER and zero-shot LLM baselines.

This does create a second problem: disagreements. One detector says Jordan is a person. Another thinks it is a country. A regex recognizer sees nothing. The surrounding text might make either interpretation correct.

Production systems therefore need policy above detection: thresholds, priorities, overlap resolution and usually some entity-specific tolerance for false positives. That policy is part of the privacy system. It should be tested like one.

Redaction is not always the right transformation

There is another issue that gets lost when people reduce anonymization to [PERSON].

Imagine this prompt:

Compare Alice's account with Bob's account and tell me whether Alice has paid Bob.

Turn both names into [PERSON] and you have protected the identifiers while damaging the task.

A better representation might be:

Compare [PERSON_1]'s account with [PERSON_2]'s account and tell me whether [PERSON_1] has paid [PERSON_2].

Now the model can still reason about relationships without seeing the original identities.

This is where pseudonymization becomes more useful than simple redaction. Presidio itself supports both anonymization and deanonymization operators, and current gateway designs increasingly use scoped mappings between surrogate identifiers and original values.

But the distinction matters legally as well as technically. Pseudonymized data is still personal data under the GDPR when it can be linked back to an individual. Truly anonymized data is different: the link to the person has to be effectively removed. Calling reversible tokenization "anonymization" does not make it anonymous.

Differential privacy solves a different problem

Differential privacy often appears in the same conversation, but it belongs to another layer.

PII detection asks: Can I identify and transform sensitive information in this record?

Differential privacy asks something closer to: Can the output of this computation reveal too much about whether a particular person contributed to the underlying dataset?

Those are not interchangeable guarantees. For an API request containing someone's email address, differential privacy is not a replacement for finding the email address before transmission. For aggregate statistics, model training or releasing datasets, it may be exactly the privacy mechanism you need.

This distinction becomes more important as anonymization research gets better at showing how apparently harmless fragments can be linked together. The EDPB's 2026 work on anonymization frames this explicitly in terms of whether records can still be isolated, linked or used to infer information about individuals.

So what would I build today?

Not one model. I would build a pipeline. Something like:

structured validation → contextual detection → domain-specific detection where needed → entity-resolution/pseudonymization → policy → audit

And then I would measure it on the data it is actually going to see.

The right configuration for customer-support tickets is probably not the right configuration for clinical notes. The right configuration for English is probably not the right configuration for six European languages. And the detector that wins a benchmark may not be the detector that gives you the best latency-recall trade-off in production.

That, I think, is where the field is in 2026. The individual models are getting much better. The harder problem now is engineering the system around them.