Data anonymization: what the GDPR requires and how to use AI without exposing your clients

Data anonymization is the conversation almost everyone skips and almost everyone ends up having. It shows up the day someone wants to train a model on the customer history, or send a database extract to a vendor, or let an analytics team work with real data. And then comes the awkward question: are we allowed to do this? The answer hinges on a technical and legal distinction that gets confused constantly, and confusing it is expensive: most of what companies call "anonymized data" is in fact pseudonymized personal data, fully subject to the GDPR.

This guide separates the two, explains which techniques actually exist, and gets down to what you need to do before putting client data into any AI system. No hand-waving, and no pretending that a `REPLACE` on the name column solves anything.

What is data anonymization, and how does it differ from pseudonymization?

Data is anonymized when it no longer allows anyone to identify a person by any reasonably available means, either directly or by cross-referencing other information. The moment that holds, it stops being personal data and falls outside the GDPR. It's a one-way door: done properly, there's no going back.

Data is pseudonymized when the direct identifier has been replaced by another value — a code, a token, a hash — but somewhere there exists the information needed to undo that substitution. It is still personal data. The whole regulation still applies: legal basis, data subject rights, breach notification, international transfers, all of it.

The practical confusion is this: nearly every commercial tool that advertises "anonymization" performs pseudonymization. And nearly every in-house project that swaps a national ID for an incremental identifier believes it has anonymized when all it has done is move the problem into the lookup table.

| | Anonymization | Pseudonymization | |---|---|---| | Reversible? | No, by design | Yes, with the key or mapping table | | Still personal data? | No | Yes | | Does the GDPR apply? | No | Yes, in full | | Typical use | Publication, statistics, open sharing | Internal work, test environments, risk reduction | | Main risk | Loss of analytical value | Re-identification if the key leaks | | Cost of doing it properly | High | Medium |

If you can recover who that person was, you haven't anonymized. You've reduced risk, which counts for something, but the GDPR is still watching.

This distinction isn't academic. It determines whether you need a legal basis to process the data, whether you can send it to a third party, whether an incident is a notifiable breach, and whether you can use it for a purpose other than the original one.

When does the GDPR require each one?

The regulation doesn't say "anonymize here, pseudonymize there". What it does is leave anonymized data outside its scope (Recital 26) and turn pseudonymization into a recommended security and minimization measure (Articles 25 and 32). From that you can derive fairly clear practical rules.

You need genuine anonymization when:

• You're going to publish the dataset or share it without a processing agreement behind it.
• You want to use the data for a new purpose that doesn't fit the original one and you have no basis to extend it.
• You want to retain information beyond your defined retention period. Anonymizing is the legitimate alternative to deleting.
• You're going to train a model whose parameters will leave your control and could memorize examples.

Pseudonymization is enough when:

• Processing is internal, you have a legal basis, and the purpose hasn't changed.
• You're populating a development or test environment and need realistically shaped data.
• You work with a processor under an Article 28 agreement and want to reduce the exposure surface.
• You need to be able to honour an erasure or access request, which is impossible by definition with anonymized data.

That last point gets forgotten a lot. If you genuinely anonymize, you lose the ability to serve data subject rights over that dataset. That's not a bug: it's the logical consequence. But it should be a decision, not a discovery.

Which anonymization techniques exist, and which should you choose?

This is where most guides stop at a list of names. What's useful is knowing what each technique protects and what it costs you in data utility.

Suppression. Delete the column. It's the most underrated and most effective technique there is. Before arguing about algorithms, ask whether you actually need the field. In most analytics projects, the name and email contribute nothing to the model.

Generalization. Replace a precise value with a range or a category: date of birth becomes an age band, postcode becomes a region, the exact amount becomes an interval. It reduces granularity and with it the ability to single out one person.

Masking and tokenization. Replace the value with another one of the same shape. A national ID that still looks like a national ID, an IBAN that validates. Useful for test environments where software needs valid formats. Careful: if the token is deterministic and reversible, this is pseudonymization.

Perturbation and noise. Alter numeric values in a controlled way so aggregates stay valid but no individual record is exact. Useful for billing, consumption or usage metrics.

Aggregation. Publish sums and averages by group rather than records. With a well-defined minimum group size, it's about as robust as it gets.

Differential privacy. The theoretically strongest approach: add calibrated noise so you can mathematically bound how much each query reveals about any individual. It's the right answer for datasets that will be queried many times, and also the hardest to implement properly. Don't propose it unless you have someone who can reason about a privacy budget.

Synthetic data. Generate new records that reproduce the statistical distribution of the original without corresponding to real people. It has improved a lot and is a genuine option for development and demos. The trap: a generator trained on too little data can reproduce original records almost verbatim. That needs verifying, not assuming.

The selection rule is simple: start by suppressing what you don't need, generalize what you can, and only then discuss advanced techniques on whatever is left.

Why does anonymization that looks sufficient still fail?

Because identification almost never comes from the obvious field. It comes from the combination. These are called quasi-identifiers: fields that say nothing about who you are on their own, but plenty together. Postcode, date of birth and sex are the classic example; with those three you can identify a huge share of any country's population.

The failures we see over and over:

• The name column gets cleaned and everything else stays. A customer's order history with dates, amounts and location is as unique a fingerprint as their ID number.
• Hashing without a salt. A hash of a national ID or an email is trivial to reverse by brute force: the space of possible values is small and known. An unsalted hash anonymizes nothing.
• The dataset gets anonymized but the attachments don't. The CSV is immaculate, and in the folder next door sit the original PDFs with the name in the header.
• Free-text fields get ignored. Comments, sales notes and support tickets are full of hand-typed names, phone numbers and addresses. It's where the most personal data escapes and the least gets reviewed.
• Linkage risk gets forgotten. An anonymized dataset can stop being anonymous the moment it's combined with another one the company — or anyone else — already holds.

The practical test, before calling anything anonymized: pick three records at random and ask someone on the team to work out whose they are using only internal information. If they manage it in under ten minutes, it isn't anonymized.

How do you use AI without exposing your clients' data?

This is the case that brings most companies to this conversation. You want to use a language model, a document extraction system or a recommendation engine, and there is personal data in the loop. The order that works is this.

1. Decide up front which data categories may leave the perimeter. Not file by file: by category. Contact data, financial data, health data, official identifiers. That's a management decision, not something a technician settles at eleven at night.

2. Minimize at source. If the use case is classifying support tickets, the model doesn't need the customer's name. Filtering before sending is cheaper and more robust than any contractual clause.

3. Apply entity detection and replacement to free text. An automatic step that finds names, phone numbers, emails, licence plates, addresses and document numbers and replaces them with type placeholders before the text leaves your infrastructure. It isn't perfect, which is why you should measure its failure rate on a real sample before trusting it.

4. Choose where processing happens and with what retention. Where the model runs, how long the input is kept, whether it's used for retraining. That's contract, not trust. If the vendor can't answer in writing, you have your answer.

5. Record the processing. What data, for what purpose, on what legal basis, who sees it. If it isn't in the record of processing activities, it doesn't exist as far as the regulator is concerned.

6. Watch the outputs, not just the inputs. A model can return personal data that was in its context. Conversation logs are personal data, and they usually sit in the least protected part of the whole architecture.

For the specific case of vendors handling third-party data, there's an extra layer of liability we cover in the guide on AI for accounting firms. And if what's ahead of you is getting the data in order before any AI project at all, the right sequence is in data before AI.

What can you do this week if none of this is in place?

A minimum plan, no committee and no extraordinary budget:

• Day 1. List the five most-used sources of personal data in the company and who accesses each one. That alone tells you where the problem is.
• Day 2. In each one, mark which fields are direct identifiers, which are quasi-identifiers and which are free text. Free text is always the most urgent.
• Day 3. Define, in writing and on a single page, which categories may leave the perimeter and where they may go.
• Day 4. Build the simplest filtering that works for the first real use case. A column-suppression script counts.
• Day 5. Run the re-identification test on three records. Document the result, including if it goes badly.

That doesn't certify you in anything, but it leaves you in a defensible position and with the judgement to make the next decision. Which is exactly what the company that discovers the problem the day a client query or a complaint arrives does not have.

Frequently asked questions

Does hashing a national ID count as anonymization? No. The set of possible IDs is small and known, so a hash can be brute-forced back in minutes. With a secret, well-guarded salt it becomes pseudonymization, not anonymization, because whoever holds the salt can undo it.

Can I use client data to train a model if it's pseudonymized? It's still personal data, so you need a legal basis and compatibility with the original purpose. Pseudonymization reduces risk and helps in an impact assessment, but it doesn't take you out of the GDPR or replace the decision about purpose.

Is synthetic data automatically anonymous? Not automatically. A generator trained on too few records can reproduce examples nearly identical to the originals. You need to assess memorization risk with specific tests before treating the synthetic dataset as anonymous.

Can I anonymize instead of deleting when the retention period expires? Yes, and it's usually the sensible way out when you want to keep the statistical value of the history. The condition is that the anonymization be genuine and irreversible: if you keep the mapping table somewhere, you haven't met the deadline, you've just hidden it.

The honest summary

Data anonymization isn't a box you tick with a tool. It's a decision about what information you genuinely need and what you're willing to lose in exchange for being able to use it without worrying. Most companies considering AI don't need differential privacy: they need to stop sending fields nobody uses, review their free text, and write down on one page who can see what. That removes 80% of the risk for 10% of the effort.

If you have an AI project stalled because nobody knows whether the data can leave the building, the audit includes exactly that map: which data each process touches, which of it is personal, and what needs doing before automating anything. And if you already have it clear and just want to test the approach against someone who has built it before, let's talk.