Home

/

Keep PII Out of Your LLM

/

The hybrid that does not work

The hybrid that does not work

Chapter 4
Part II
6
min read

The hybrid that does not work

If a model gets 0.54 and regex gets 0.17, the obvious move is to run both and take the union. Two independent methods, complementary strengths, better coverage.

The benchmark tested it. Adding regex detection to the model-based detectors produced:

  • Piiranha: +0.012 F1
  • GLiNER v1: +0.001 F1
  • Presidio: +0.001 F1

Nothing. And it occasionally made things worse, because regex matches displaced correct model detections with false positives.

That result kills a reflex worth killing. The models have already internalised the easy structural patterns. Layering rules on top adds noise, not recall. Rules earn their place for a different reason, which Chapter 5 is about, and the reason is precision on checksummed identifiers rather than incremental F1.

What the benchmark does not prove

Applying the chapter's own standard to itself.

Three of the four datasets are synthetic. Only CoNLL-2002 carries human annotations of real text, and it only covers two of the six shared entity types. Synthetic PII data has regularities that real data does not.

The sample is small. A paired t-test across the four datasets found no statistically significant difference between the top three models (p well above 0.10). Piiranha at 0.542 and Presidio at 0.481 are not reliably distinguishable on this evidence. Do not use this table to pick a winner by decimal places.

Span matching used a ±5 character tolerance, which is a judgement call that moves the numbers.

And these are six entity types. A production system usually wants twenty or more, including ones with no public benchmark at all, like your internal customer reference format.

None of that rescues the headline. The caveats affect the ranking. They do not touch the finding, which is that cross-domain PII detection lands somewhere around 0.5 rather than somewhere around 0.95, and that the gap between published and achieved is large enough to invalidate a design that assumes the published number.

What 0.54 means on a Tuesday

F1 is a harmonic mean of precision and recall, which makes it a poor number for making decisions, because it hides the trade-off you actually care about.

Take a detector with recall of 0.85 on your traffic, which would be a good day. You process 10,000 prompts. Each contains an average of three personal data entities. That is 30,000 entities, and 4,500 of them go through untouched.

Not 4,500 catastrophes. Most will be a name in a context where the name was harmless. Some proportion will be the account number, the medical detail, the home address.

Now raise the threshold to catch them. Recall goes up, precision goes down, and you begin redacting things that were not personal data: the product name that looked like a surname, the order reference that looked like a national ID, the word "Paris" in a sentence about an office. Your summaries get worse. Users notice, and users route around controls that make their tools worse, which is where Chapter 1 came in.

There is no threshold that makes both problems go away. That is the nature of a probabilistic classifier, and pretending otherwise is how teams end up surprised.

The right conclusion

The wrong conclusion is that detection is pointless. The benchmark's own author, having produced these numbers, still chose Presidio for production. Not on accuracy, on architecture: a complete framework, a replaceable NER backend, a working anonymisation and de-anonymisation pipeline, active maintenance, and 8 to 11 times the speed of the transformer detectors (15.1 ms versus 118 to 198 ms per text on CPU).

That is exactly the right reasoning, and this book follows it. You pick a detector for how well it fits an architecture you can improve later, not for a decimal place you cannot reproduce.

The right conclusion is that detection changes job. It is not the wall. It is the second net: the thing that catches what slipped past a design that was already trying not to send the data. A second net that catches half of what reaches it is genuinely valuable, as long as you sized the rest of the system knowing that is what it does.

Every defensive decision in Part IV follows from this chapter. Fail closed when the detector is unavailable, because you cannot assume it was catching much. Minimise at source, because the field that never entered the prompt cannot be missed. Keep the identifier out of band, because then a miss is a miss on a token rather than on a person. Filter the output as well as the input, because the model may surface what the detector let through.

Detection is a net, not a wall.

Knowing that, build the best net you reasonably can. Start with the one layer that genuinely is close to certain.

Sources for this chapter

Everything quantitative here comes from two independent sources. Both are worth reading directly if you intend to act on the conclusion.

  • The cross-domain F1 table, latency figures, degradation percentages, the regex-hybrid result and the 64% Presidio reversibility rate — A. Sikkema, Benchmarking Open-Source PII Detection Across Domains, June 2026: https://albertsikkema.com/python/security/privacy/2026/06/01/benchmarking-open-source-pii-detection.html · Method: five approaches, four datasets (AI4Privacy EN+NL, Gretel Finance EN+NL, Nemotron-PII, CoNLL-2002 NL), six shared entity types, ±5 character span tolerance. The caveats in this chapter are the benchmark author's own, reproduced rather than paraphrased.
  • PIIBench: 82 entity types across ten datasets; fine-tuned DeBERTa F1 0.6476; strongest published comparator 0.1723 — P. Jha, arXiv 2605.25816, 25 May 2026: https://arxiv.org/abs/2605.25816
  • Multilingual PII extraction, for context on the model landscape — GLiNER2-PII, arXiv 2605.09973: https://arxiv.org/pdf/2605.09973
  • Vendor-claimed F1 of 0.92–0.99, and a commercial filter reported dropping 0.96 → 0.18 out of distribution — secondary reporting, labelled as such in the text. These are the subject of the argument, not evidence this book verified.

The worked example of 10,000 prompts and 4,500 missed entities is arithmetic on an assumed recall of 0.85, presented as illustration. "Demo gap" is this book's coinage for a phenomenon the sources describe but do not name.

the-leak-you-cant-see
blast-radius
what-counts-as-pii
the-five-doors
the-accuracy-reckoning
the-hybrid-that-does-not-work
deterministic-detection
npi-in-c
the-three-way-choice
calling-the-analyzer-from-c
measuring-your-own-demo-gap
choosing-the-operating-point
the-ladder-of-safeguards
pseudonymisation
the-round-trip
restoring-safely
when-masking-breaks-the-task
plausibility-hazard
the-architecture-that-holds
the-reference-architecture
dont-send-it-at-all
structure-beats-prose
the-gateway
failure-is-a-policy-decision
the-sidecar-you-can-trust
egress-deny-it-at-the-network
rag-and-agents
de-identify-before-you-embed
dual-model-separation
the-boring-controls
evidence-and-the-first-thirty-days
week-two-the-chokepoint-and-the-fast-layer
entity-catalogue-and-c-validators
mbi-positional-rules
tooling-at-a-glance
azure-ai-language-pii-in-detail
container-trust-checklist
sources
azure-ai-language
provider-retention

Download the full PDF for free?

Free download — no account required

Get the PDF
Get the PDF
Related Chapters
Free Download
Get the full PDF
All pages, including all code examples, diagrams, and the appendix reference card.
No spam. Unsubscribe at any time.
Your email won't be shared.
Oops! There's a problem with your request. We're working on fixing it. Please try again later.