Data is only anonymous when re-identification stops being reasonably likely, not just difficult. That’s the whole ball game. Get this right, and properly anonymised data falls outside GDPR entirely. Get it wrong, and you’re still processing personal data, even if you renamed the columns and told yourself otherwise.
The European Data Protection Board and recital 26 of the GDPR set the bar, and it’s higher than most teams expect. Before you tick the “anonymised, job done” box, three things need to happen:
- Don’t assume. Removing a name field doesn’t make a dataset anonymous.
- Test it. Run the data against a proper re-identification test, not a gut check.
- Document it. Write down your method, your assumptions, and why you believe it holds.
What’s the difference between anonymizácia osobných údajov and pseudonymisation?
Here’s where most compliance headaches start. Anonymisation strips data of any reasonable link back to a person, permanently. Pseudonymisation swaps identifiers for tokens or codes, but keeps a key somewhere that can reverse the process. One takes you out of GDPR’s scope. The other doesn’t, not even close.
Three quick examples make this concrete:
- Replacing “Ján Novák” with “Patient 4471” in a spreadsheet, while keeping a lookup table elsewhere, is pseudonymisation.
- Aggregating a thousand salary records into an average by department, with no way back to individuals, is anonymisation.
- Hashing an email address with a key you still hold is pseudonymisation dressed up to look bolder than it is.
Pseudonymised data remains personal data under GDPR, full stop. That means breach notification duties, data subject access requests, and every other obligation still apply. It’s a genuinely useful security control, and ENISA’s guidance on pseudonymisation rightly treats it as one, but it’s not an exit from compliance.
Choose pseudonymisation when you need reversibility for legitimate operational reasons, like linking records for research while keeping the master key locked down. Choose anonymisation when you genuinely never need to go back to the individual again.
GDPR and legal status: what the EDPB framework actually demands
Recital 26 says information is not personal data when the individual is “no longer identifiable.” Article 4 defines personal data broadly enough that “no longer identifiable” is doing a lot of heavy lifting in that sentence. That’s exactly why the EDPB stepped in with something more operational.
The EDPB’s Guidelines 02/2026 set out a three part test: No Record Isolation, No Linkage, No Inference. Pass all three, in the context that actually matters for your data, and you can treat it as anonymous.
The EDPB also draws a line between a contextual approach (weighing up who might realistically access the data and what other information they hold) and a simplified approach (a conservative, blanket assumption that a motivated attacker has decent resources). Most regulators expect the contextual approach for genuinely low-risk internal use, and the simplified, cautious approach for anything you plan to publish or share externally.
Here’s the number that should worry you: a dataset judged anonymous for one recipient can be personal data for another, depending on what auxiliary information that recipient can access. A hospital’s internal team and a data broker looking at the same “anonymised” export are not equally likely to re-identify someone.
Get this classification wrong and the practical consequences stack up fast. Cross-border transfer rules kick back in. Data subject rights, including access and portability, reapply. Breach notification duties return. None of that is optional once you’ve mislabelled personal data as anonymous.
Common anonymisation techniques and where each one falls short
No single technique does everything. Pick based on what you’re protecting and what you need the data to still do afterwards.
- Masking and redaction hide or blank out direct identifiers like names and ID numbers. Fast, cheap, and useless against indirect identifiers like a rare postcode combined with a birth date.
- Aggregation and generalisation roll individual records into group statistics or coarser categories (age bands instead of birthdates). Great for reporting, but small subgroups can still be re-identified if the bucket is too narrow.
- Randomisation and differential privacy add calibrated statistical noise so aggregate patterns survive while individual records blur. Powerful for analytics, but the noise parameters need real expertise to get right.
- Hashing and permutation scramble values into fixed strings or shuffle them across records. Looks anonymous, but hashing without proper salting is trivially reversible against known value lists.
- Synthetic data generates entirely new records that mimic statistical patterns without mapping to any real person. Excellent for AI training sets, though poorly generated synthetic data can still leak outlier patterns from the source.
Tabular data suits aggregation and differential privacy well. Free text and scanned documents need masking plus a human pass, because entity detection in unstructured content is nowhere near perfect. Multimedia (photos, audio, video) usually needs bespoke redaction tools built for that format specifically.
Pro Tip: Never rely on one technique alone. Layer masking with aggregation, or hashing with generalisation, so a single weak point doesn’t undo the whole effort.
Academic research keeps confirming this layering matters. Surveys of anonymisation attacks show re-identification techniques evolve constantly, so yesterday’s “safe” method can become tomorrow’s cautionary tale.
How do you test whether data is actually anonymous?
Talk is cheap. The EDPB’s three criteria give you something to actually check against, rather than a vibe.
- No Record Isolation: can an attacker single out one person’s record within the dataset? Try it yourself using the rarest combination of attributes you can find.
- No Linkage: can two or more records about the same person be linked together, even across separate releases? Cross-reference your dataset against any public data you can find.
- No Inference: can someone deduce a new fact about a person with high confidence, even without isolating or linking a record? This one is the hardest to rule out and the easiest to overlook.
| Test | Quick practical check | Documentation to keep |
|---|---|---|
| No Record Isolation | Search for unique attribute combinations | Query results and thresholds used |
| No Linkage | Attempt cross-dataset matching with public sources | List of external datasets tested against |
| No Inference | Model plausible attacker reasoning chains | Written adversary scenario and conclusion |
Model your adversary honestly. A journalist with time and public records access is a very different threat than a curious colleague. Run the conservative, simplified approach whenever the data leaves your organisation’s walls, and keep the contextual approach for genuinely closed internal systems.
Building an anonymisation workflow that actually holds up
Automated tools are brilliant at speed and terrible at judgement calls. That’s why every serious pipeline pairs the two.
- Step one: automated detection using named entity recognition (NER) and OCR flags likely personal data across documents, spreadsheets, and scans.
- Step two: apply the chosen transformation, masking, aggregation, or hashing, consistently across the flagged fields.
- Step three: strip embedded metadata (author names in document properties, GPS tags in images) that survives even after the visible text is clean.
- Step four: human reviewers check edge cases: handwriting, stamps, low-confidence OCR, and anything the model flagged as uncertain.
OCR fails predictably on stamps, tables, and handwriting, and treating its output as gospel is how identifiers slip through undetected. A reviewer catching that gap before the file goes anywhere is not a nice-to-have step, it’s the difference between compliant and exposed.
If you’re feeding anonymised content into a third-party AI system, strip personal data before it ever reaches the model, and check your processor contract covers where that data actually goes. Glocco’s own guide on essential AI tools for translators covers this exact tension between speed and privacy in more depth.
Pro Tip: Treat every low-confidence OCR flag as a “review required” item, never an automatic pass. It’s the single cheapest safeguard in the whole pipeline.
Planning the timeline and budget for an anonymisation project
Nobody anonymises a whole organisation’s data overnight, and trying to will blow your budget.
- Pilot (2 to 4 weeks): run the pipeline on a representative sample, tune detection rules, and measure your manual review rate.
- Scale (4 to 12 weeks, depending on volume): roll the tuned process across the full dataset, keeping human review on flagged edge cases only.
- Audit (ongoing): periodically re-test against the three EDPB criteria, especially after any new external dataset becomes publicly available that could enable linkage.
The main cost drivers are predictable once you’ve run a pilot: total data volume, the proportion of unstructured content versus tidy tabular data, how high an assurance level your use case demands, and what percentage of records need manual review rather than automated pass-through.
Keep a minimum audit trail for every project: original file hashes, the transformations applied, reviewer sign-off, dates, and a short written statement of your adversary model and reasoning. Regulators and auditors both want to see the thinking, not just the output.
The re-identification risks nobody budgets for
Anonymisation isn’t a one-time event you complete and forget. The biggest risk is auxiliary data: information that didn’t exist, or wasn’t public, when you first anonymised a dataset can surface years later and suddenly make linkage possible again.
Small subgroups are the classic trap. Aggregating by department and age band feels safe until you realise the “finance, over 60” bucket in a mid-sized company has exactly one person in it. Generalisation only works when every category actually contains enough people to hide in.
Synthetic data carries its own quiet risk. Poorly tuned generative models can memorise and reproduce outlier records from the training set almost verbatim, which defeats the entire point. Differential privacy techniques reduce this by adding calibrated noise, but the parameters need genuine statistical scrutiny, not a default setting left untouched.
Mitigation isn’t a single fix, it’s a habit. Re-test datasets periodically against newly available public data. Limit the release of high-granularity data to only what a use case genuinely requires. Favour the conservative, simplified assessment approach whenever data leaves your direct control, because you can’t control what auxiliary information a recipient gains access to next year.
The uncomfortable truth is that “anonymous forever” is rarely a guarantee anyone can honestly make; embracing data deletion practices is a crucial part of mitigating long-term re-identification risks. What you can guarantee is a documented, defensible process that was sound at the point you applied it, gets re-checked on a schedule, and adapts when the threat landscape shifts.
Proving your anonymisation process would survive an audit
An auditor doesn’t just want clean data. They want to see your reasoning, in writing, with dates attached.
Start with a documented methodology for every dataset: which technique you applied, why you chose it over the alternatives, and which of the three EDPB criteria you tested against. Vague statements like “data was anonymised using standard methods” won’t hold up if a regulator asks follow-up questions.
Keep version history. If a dataset gets re-anonymised after a process change, log what changed and why, rather than overwriting the previous record. This matters especially when a data protection authority investigates a complaint months or years after the original processing.
Build in periodic re-validation, not a one-off certificate. A dataset judged safely anonymous in 2024 might not clear the bar in 2026 if new public datasets have emerged that enable linkage. Set a calendar reminder, genuinely, to re-run your tests on datasets still in active use.
Finally, assign clear ownership. Someone specific, by name and role, should sign off on each anonymisation decision, and that sign-off should sit alongside the technical log described earlier: file hashes, transformations, reviewer initials, and the adversary model considered. When these elements exist together, an audit stops being a scramble and becomes a five-minute conversation.
Where anonymisation fits next to encryption and data minimisation
Anonymisation gets a lot of attention, but it’s one tool in a wider kit, not a replacement for the others.
Encryption protects data in transit and at rest, but it’s reversible by design for anyone holding the key. Encrypted data is still personal data under GDPR; encryption reduces the risk of exposure during a breach, not the legal classification of the data itself. Anonymisation, done properly, changes the classification entirely.
Data minimisation asks a different question upfront: do you need this field at all? Collecting less personal data in the first place is often cheaper and more effective than anonymising a bloated dataset after the fact. The two work brilliantly together: minimise what you collect, then anonymise what remains once its original purpose is served.
Pseudonymisation, covered earlier, sits in the middle: reversible, still personal data, but a genuinely useful control for reducing exposure during processing.
Think of it as layers rather than a single choice. Minimise collection at the source, encrypt what you store and transmit, pseudonymise data you need to keep reversible for operational reasons, and anonymise the data whose individual link you’re prepared to lose permanently. Organisations that treat these as interchangeable, or pick just one and call it a day, tend to be the ones explaining themselves to a regulator later.
Why glocco® builds privacy into the translation pipeline itself
We see personal data constantly, in contracts, medical records, legal filings. That’s why glocco® strips PII before documents ever touch an AI system, backs it up with human review, and documents every step. It’s not a bolt-on. It’s how confidentiality in legal translation actually gets delivered, not just promised.
Want a partner who takes data privacy as seriously as you do?
There’s plenty of anonymisation software out there that’ll strip a name from a field and call it a day. That’s not really the problem most of our clients are solving. When your source documents contain patient records, contract terms, or financial data that needs translating into another language, the anonymisation and the localisation can’t happen in separate silos, or things slip through the cracks between them.
Glocco® builds privacy checks directly into the translation and AI annotation workflow, so PII gets handled before it ever reaches a third-party model, and a human reviewer checks the edge cases automated tools miss. That’s the whole point of pairing AI-powered translation with a documented process: speed without cutting corners on the data itself.
If you’re handling regulated, sensitive, or compliance-heavy content that needs translating, get in touch and ask about a pilot project. We’ll show you exactly how our workflow keeps personal data protected from the first upload to the final delivery.
Frequently asked questions
Is anonymizácia osobných údajov reversible?
No, not if it’s done properly. Genuine anonymisation removes any reasonable path back to an individual. If a process can be reversed with a key, it’s pseudonymisation, not anonymisation, and GDPR still applies.
Does GDPR still apply to anonymised data?
No. Once data passes the EDPB’s three-part test (No Record Isolation, No Linkage, No Inference) and recital 26’s threshold for “no longer identifiable,” it falls outside GDPR’s scope entirely.
What’s the fastest way to anonymise a large batch of documents?
Automated NER and OCR detection handle the bulk of the work quickly, but skipping human review on flagged edge cases (handwriting, stamps, low-confidence scans) is how identifiers slip through unnoticed.
Can AI tools anonymise data safely on their own?
They speed up detection significantly, but they’re not reliable enough to trust unsupervised, particularly with unstructured or scanned content. Pair automated tools with a documented human verification step every time.
How often should anonymised datasets be re-tested?
There’s no fixed universal interval, but re-testing after any new public dataset emerges that could enable linkage is essential, alongside periodic scheduled reviews for datasets still in active use.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
- Guidelines 02/2026 on Anonymisation (EDPB)
- Regulation (EU) 2016/679 (GDPR) — official text on EUR-Lex
- Data pseudonymisation: advanced techniques and use cases (ENISA)
- Vulnerability- and Diversity-Aware Anonymization (IEEE Access)
- GDPR a anonymizácia údajov
