Why anonymizing legal documents for AI is (actually) hard

Before a legal document can be analyzed by a generative AI model, it needs to be stripped of every identifying detail: party names, addresses, national ID numbers, IBANs, company registration numbers... This is the first step of our pipeline, and the one that protects your clients before a single request ever reaches a language model.

On paper, this sounds like a fairly standard named-entity-recognition task. In practice, we spent several weeks proving otherwise.

The problem isn't "find a name," it's "find every name"

A general-purpose entity detector easily spots "Maître Dubois" the first time it appears. The real challenge comes next: in an 8-page ruling, that same person will often be referred to again simply as "Dubois," or "Mr. Dubois," without the full name ever repeating. A model that only recognizes the full name leaks every one of those partial references.

We measured this precisely against our internal test set: the majority of missed person-name detections were exactly this case — a partial reference to an entity already detected elsewhere in the same document. The fix wasn't "more training data," it was a propagation mechanism: once a full name is detected, each of its components (first name, last name) is actively searched for throughout the rest of the text. This single fix crossed a reliability threshold that no amount of model tuning had reached.

Organizations don't show up the same way everywhere

A commercial contract and a court ruling don't talk about organizations the same way. A model trained mostly on business data (public tenders, company registrations, legal notices) becomes very good at spotting "Dupont Construction LLC" in a contract — and much less reliable at recognizing how an organization is mentioned in a civil court judgment.

We found this imbalance came directly from our training data mix: it covered business law well, but almost no real court decisions. The fix was twofold: source more real court decisions from public data (Judilibre), and split long documents into overlapping text windows that respect the model's technical limit instead of silently truncating them.

False positives cost as much as false negatives

An over-aggressive detector damages a document just as much as an overly timid one leaks it. We found a revealing bug: when a VAT number and a national ID number have the exact same character length and overlap in the text, our detection-merging logic arbitrarily picked one of the two labels — sometimes the wrong one. The fix: on a tie, the more reliable detection (a validated regular expression, not a model prediction) should always win for structured categories like IBANs or VAT numbers.

This kind of bug doesn't show up in a quick smoke test. It only surfaces with a rigorous testing methodology — real documents, cross-cutting categories, and individual failure analysis rather than a single reassuring aggregate score.

What this means in practice

After several cycles of training, measurement and correction, our detection system now reaches, on our internal test set of several thousand annotated entities:

• 85.5% recall on individuals (+19 points over the generic starting model)
• 95.7% recall on organizations
• 95.7% recall on structured data (IBANs, VAT numbers, company IDs)

These numbers didn't come from a single magic tweak — they came from a method: measure precisely where the system fails, understand why instead of blindly throwing more data at it, and fix the actual root cause — whether it lived in the model, the data, or the production code.

Want the full technical story — model training, hypotheses tested and rejected, the numbers behind every iteration? We wrote up the complete engineering deep-dive for anyone who wants to dig in.