Skip to content
Mohamed Khelifa Zaghdidi I lead engineering teams, I run a model, I publish the measurements.

Anonymize before the model, not after

Data — written 28 August 2026, republished here 2 September 2026

Note on republication. Written and published elsewhere on 28 August 2026, before this site existed. It appears as written with one exception: the original described the system as similarity search over an index. That was inaccurate — it is a deterministic extraction pipeline followed by local classification. The argument in this note holds either way.

“We’re fine, the identifiers have been stripped.”

That sentence taught me more humility than anything else in six months.

Stripping direct identifiers is necessary. It stops being sufficient the moment you handle free text.

Identifiers do not live in the columns

They live in free text: a comment, a note, a written exchange. Which is exactly what gets sent to a model.

A clean database schema tells you nothing about what sits inside the text fields, and that is where most of what identifies a person actually is.

Three crossed attributes are often enough

A date, a geographic area, a status. The record you had neutralized is unique again.

Anonymity is not a property of a field. It is a property of the whole set, and it is lost by cross-reference.

Whatever has entered the model cannot be recalled

Logged prompt, built index, cached context: every stage keeps a copy. Cleaning up afterwards means chasing your own trail.

This is the point that changes the design rather than the procedure.

The rule I settled on

Handle the data before the model, not after. Three steps.

Detect entities upstream, inside the free text. Substitute consistent placeholders, so the model never sees the real values. Rehydrate on the way out, under control.

The protection sits in the architecture, not in trust.