Removing the name is not enough
The common approach is to drop name, email and address, and treat what remains as anonymous. It usually is not. Combinations of ordinary attributes are surprisingly identifying - a postcode district, a date of birth and a gender narrows most populations very sharply.
For business data the equivalent combinations are just as strong: a customer's sector, region, size band and the date of their first order may identify exactly one account.
Pseudonymisation and anonymisation are different
| Pseudonymisation | Anonymisation | |
|---|---|---|
| Identifiers | Replaced with a key | Removed, with re-identification prevented |
| Reversible | Yes, by whoever holds the key | No |
| Still personal data | Yes | No, if genuinely achieved |
| Analytical value | Largely preserved | Reduced |
| Effort | Low | Considerable |
Most projects that describe their data as anonymised have in fact pseudonymised it, which is a perfectly legitimate control but does not remove the data protection obligations. Being clear about which you have done matters.
Techniques that genuinely reduce risk
- Generalisation - replace exact values with bands: age ranges, postcode area rather than full code, month rather than date.
- Suppression - remove records or values that are unique enough to identify someone.
- Aggregation - train on group-level data where the model does not need individuals.
- Noise addition - perturb values, formalised in differential privacy with measurable guarantees.
- Minimum group size - ensure every combination of quasi-identifiers covers at least several individuals.
Each costs some information, and how much depends on the problem. Generalising dates to month may cost nothing in a model about annual patterns and a great deal in one about weekday behaviour.
Check re-identification rather than assuming
Test the result. Count how many records are unique on the combination of remaining fields - if a meaningful share are, the data is not anonymous whatever it is called.
Do this with someone motivated to break it rather than the person who built the pipeline. It is a quick check and it consistently finds more than expected, particularly in business data where the population is small.
Models can leak their training data
Anonymising the input is not the whole story. Models can memorise, and in some circumstances outputs reveal information about training records - particularly large models trained on small datasets, or any model that reproduces text.
Where the training data is sensitive, that risk needs considering alongside the input pipeline. It is another argument for holding only the data the model genuinely needs, which is the most reliable protection available. Our note on privacy-preserving techniques covers the options.
If a single row is unique across the fields you kept, you have not anonymised anything.