DEV Community: Tom Fairey

Detecting Data: Different Approaches

Tom Fairey — Thu, 29 Oct 2026 19:45:15 +0000

So, in my last piece I talked about how your de-identification is only as good as your detection. Detection is the first building block of de-identifying data in a way that keeps its context. It also opens a whole new can of worms. What are the approaches, how do they work, and why do they so often fail?

It can look straightforward. Categorise identifying data, build a set of rules to find that data, and highlight every example. But categorising identifiers is hard in itself. Our founding researcher likes to point out how difficult names are: the same word can be a proper noun in a name and a common noun anywhere else. “Hannah Grey” has the shape of a full name, but “grey” in lower case reads as a colour.

Approaches
Regex is fast and predictable, and it’s strongest when paired with checksum verification. Machine learning models, including named entity recognition (NER), learn from training data to predict whether a span is sensitive. LLMs bring broad pretraining to the same job and can read context.

Teams often pick one of these and stretch it across a whole dataset. But the better approach is to look at what kind of data you’re treating, and what it needs for the purpose you’re using it for. Data treated with attention to its meaning and context performs very differently from data treated in bulk.

Rules
Some identifiers carry their own proof. Card numbers end in a Luhn check digit. An IBAN is only valid if a mod-97 calculation leaves 1. UK NHS numbers use mod-11, and a result of 10 means the number can’t exist. For these, a rule plus a checksum is fast, cheap and quite robust.

But a checksum is a filter, not a proof. Roughly one in ten random digit strings of the right length passes Luhn, so false positives grow with your data. Presidio, for example, had to fix a case where 13-digit timestamps were being read as card numbers.

Some identifiers have no checksum at all. US Social Security numbers have been randomly assigned since 2011, so you can only reject a handful of impossible values. UK National Insurance numbers have a fixed shape but no check digit. Both need context before you can trust a match, and that means needing a second approach. Rules also can’t find what has no fixed shape; names and free-text addresses defeat regex entirely.

Models
Models can read context, and they rely on it. In OpenAI’s Privacy Filter model card, overall recall rises from 58% when a value appears on its own to 86% when a cue such as “this is my home landline number” comes before it.

Headline scores need care too. Privacy Filter reports a token-level F1 of 0.96 on PII-Masking-300k, a synthetic benchmark. On SPY, a separate synthetic benchmark of legal questions and medical consultations, scored with exact span matching, five open PII models, including Privacy Filter averaged between 0.37 and 0.47 F1. How you score matters as much as what you score. On a credentials dataset, Privacy Filter’s own card reports 0.84 F1 counted by tokens, but 0.62 counted by exact spans, because partly detected spans get the boundaries wrong.

In combination?
The answer could be to “use both”. In a 2026 stress test, researchers at Halmstad University ran spaCy, Presidio and a small LLM over deliberately messy text, and each failed differently. Presidio’s regex caught every SSN and IP address. spaCy found 95% of names. The LLM coped best with typos, but still labelled nearly half of the card numbers as SSNs. The researchers settled on recommending running all three and merging the results.

A public CV benchmark from this year shows what using in combination buys you, and where it stops helping. Default Presidio, which pairs regex with a spaCy model, found 65% of the personal details and leaked something in 39 of 40 CVs. Swapping spaCy for GLiNER inside Presidio barely moved that. The biggest single gain came from a policy layer written specifically for CVs: the best stack, three GLiNER-family models plus that layer, reached 0.97 recall but still leaked details in 10 of 40 CVs.

The same pattern shows up on the Text Anonymization Benchmark (TAB), built from European Court of Human Rights judgments. TAB separates direct identifiers from quasi-identifiers, so it tests contextual reasoning rather than pattern matching. A Longformer model fine-tuned on TAB’s training data caught every direct identifier in the test set. Presidio caught under half, partly because nothing in its rules or its general-purpose model covered court case numbers, which identify the applicant.

OpenAI saw the same effect with Privacy Filter on SPY. Out of the box it scored 0.55 F1. After training on 10% of SPY’s training data, it scored 0.96.

The real divide isn’t approach versus approach, but whether the detector has seen and been trained on labelled examples of your kind of data and been able to train.

But labelling is slow and expensive, and not many teams have a few thousand labelled examples to hand. It also means people reading the very data you’re trying to protect, and the result can work well on one domain without necessarily transferring to the next.

Regex and checksums hold up for a different reason. They behave the same way every time, they can be audited, and they only change when you change them. A rule can be explained to a compliance lead and tested against known examples until you know where its edges are. A predictable rule that finds card numbers in log files is worth more than a few points of F1. When the data belongs to someone else, knowing where your pipeline leaks matters more than its average score.

Hybrid doesn’t always win. It helps when each part suits your data: rules for identifiers with a fixed shape, and models trained on text like yours for everything else. The only score that tells you how a detector will behave on your text is one measured on a labelled sample of it.

Sources:
Mind the Gap: Robustness Risks in PII Detection Systems (arXiv, Sep 2026)
CV-PII-Bench (GitHub)
OpenAI Privacy Filter model card
GLiNER2-PII (arXiv, May 2026)
The Text Anonymization Benchmark (TAB)
Bootstrapping Text Anonymization Models with Distant Supervision (TAB test results)
Presidio release 2.2.359

Your Redaction Pipeline Is Only As Good As What It Finds

Tom Fairey — Thu, 22 Oct 2026 16:19:27 +0000

Last week, I wrote about what over-redaction does to your tool’s architecture: blanking out too much strips away the context the model needs and destroys your blueprint. Your data is valuable because it’s yours, and that specificity is the first thing that redaction removes.

I recently spoke to a founder who had closed his business and sold the company’s data as part of this closing process. His team de-identified it by hand, and the buyer rejected it three times. Each time, the buyer said either the personal information hadn’t all been found or it hadn’t been de-identified well enough. He also told me the most valuable data was from before 2020, because it was more human and not yet saturated with AI.

There’s an irony there – proprietary data is worth so much because people wrote it, and it’s being sold to train the models that make new data less human.

But the part that made me think was about the detection: even careful human detection still wasn’t good enough for the buyer.

It made me look at the protection process from the start. Redaction has a huge effect on how well data performs, but detection comes first, and it sets the ceiling. Nothing can be protected unless it’s identified first.

We’re drawn to high numbers, like which vendor beats which or who tops the latest benchmark. The gap below 100% gets less attention. When Hou and colleagues compared four ways of detecting private details before text reached a larger model, the best one caught 65.7% of the names, places and organisations in it. Roughly one in three went to the model untouched.

Whatever slips through is just leaked, obviously. A company can face regulatory consequences for that, but the bigger failure is to the people whose data is now exposed.

So why doesn’t everyone have perfect detection? Most teams start with Presidio, a spaCy NER model or a prompt to a small LLM. The best performer in the Hou study was an off-the-shelf BERT NER model, the same kind of tool many of us already run. Each of these catches the obvious cases, and each misses in its own way.

Part of the problem is definition. “Personal” and “identifiable” aren’t straightforward terms and pinning them down means first sorting identifiers into direct and indirect. Direct identifiers point to one person on their own: a name, a home address, a National Insurance number. Indirect identifiers, also called quasi-identifiers or contextual identifiers, only point to someone in combination. A date of birth, a job title and a town might be harmless one at a time, but identifying together.

Take a line like “I spoke to the only paralegal in our Leeds office, who joined in March.” Since there’s no name in it, a detector looking for names would return nothing. To anyone at that firm, it describes exactly one person.

Those indirect details are exactly what models are good at piecing together. Patsakis and Lykousas took descriptions of 20 UK public figures that had already been run through an anonymisation tool, with names, places, jobs and dates stripped out. GPT-3.5 still named the right person about 73 times in 100. Human readers, in an earlier study on the same texts, managed about 26. The researchers then removed every word the model itself identified as giving the person away. It still identified 59 out of 100 of the texts it had named before.

The subjects were celebrities, which makes guessing easier, but anyone holding background data on customers is in a similar position. Catching names isn’t enough if what’s left still describes someone.

Part of good detection is training. Getting a model to catch every form of an entity means a lot of fine-tuning and building domain-specific ontologies, and that work has to be repeated for every entity type. For sensitive data, the engine also can’t send requests out to an external service, which rules out third-party LLMs for this step.

Then there’s the opposite failure: if you push sensitivity too far false positives might climb. Over-detection does the same damage as over-redaction. The data turns sterile, and a person has to go back through it by hand.

Detecting well means defining identifiers for your own domain, training on semantic ontologies you outline and define, keeping the whole process in-house, and holding false positives down while you do it. None of this is quick. It can also be unglamorous.

The AI Data Paradox: The Safer You Make the Data, the Worse the AI Gets

Tom Fairey — Wed, 14 Oct 2026 12:05:35 +0000

AI engineers spend enormous amounts of time tweaking small things to achieve bigger gains. Energy is poured into analysing model performance, rewriting prompts, tuning retrieval and building elaborate evals. But in enterprise settings, model performance is often most affected by what happens before that work even begins, by what goes into the pipeline first.

Data isn’t something that a system solely consumes; it is part of the architecture itself. It is as structural as the model or prompt — the blueprint for the structure. In most enterprises, where data is so sensitive, this blueprint arrives with sections missing.

Enterprises have the most delicate pain point. The data is richest here because it is proprietary, intrinsically tied to each organisation. And this richness of context requires the most cleaning. Compliance and security teams, working to either internal or external policy, run data through protection tools that detect sensitive information and then redact, mask, or tokenise it. Their job is to make sure nothing sensitive is exposed or leaked, not to check whether the data is still useful.

A paradox is created: an enterprise’s dataset is valuable because of its specificity and its representation of a company’s customers, successes, failures. Yet the data carrying these signals is the first to go, leaving a mottled blueprint.

If data is a blueprint, then redaction is a black marker taken to the plans. The room layout survives, but the dimensions, load-bearing walls and materials are incomplete or damaged. Even with the best builder, or developer, the building will still stand on shaky foundations. You can’t expect it to be the most beautiful, sturdiest building on the block if it was built from partial plans.

The richer the data, the more aggressively it is stripped. This produces technically safer but sterile data that is rarely useful for generating insight. This cost is measurable: a recent study from the University of Bonn and Fraunhofer IAIS found that a model scored 0.73 on a reasoning benchmark using the original text, but this dropped to 0.52 once personal details were redacted. Replacing them with consistent pseudonyms brought it back to 0.70.¹

Starting a pipeline with incomplete records puts a burden on developers and engineers to improve other aspects and fix a problem that started before them.

Every option to preserve safety gives something up. Self-hosted models keep data in-house but demand infrastructure and talent many teams lack or cannot budget for. Aggregated data smooths away the edge cases that are often the most insightful, and doesn’t work when single records need to be reasoned with.

An adaptive approach would not look at “what is sensitive?” but “what needs to be kept for the model to perform best?” Identity and context might seem inseparable, and in many ways they are. But providing relevant or equivalent context while protecting individuals behind data is one way models can be given a more complete blueprint.

Models, prompts, and retrieval are already seen as things to design. Privacy measures should be seen like this too. A requirement or restriction that has to be adhered to can be an opportunity for innovation and creativity.

The combination of a safety requirement and the need to stay attuned to an organisation’s specific data produces fertile ground for new approaches — and this shouldn’t fall only on engineers. Look at data as part of the system architecture, and its treatment becomes a crucial first step in achieving high performance.

Tobias Deußer et al, ‘On the Impact of Anonymisation on Large Language Models’, September 2026, https://arxiv.org/html/2609.11335. ↩