AI anonymisation and NER: the guide that disentangles anonymisation, pseudonymisation and UK GDPR (2026)
Quick Answer: what is AI anonymisation and NER?
AI anonymisation and pseudonymisation rely on the NER technique (Named Entity Recognition: the ability of an AI to automatically spot names, addresses, numbers, dates, organisations within a text). The AI identifies these personal data items and then replaces them with markers or pseudonyms.
Critical UK GDPR distinction:
- Anonymisation: irreversible transformation. The data falls outside the scope of UK GDPR. Technically very difficult to achieve — you must ensure the individual can never be identified again, even by combining with other sources, even if someone recovers the key. The ICO Anonymisation Code of Practice sets the bar.
- Pseudonymisation (Article 4(5) UK GDPR): reversible replacement under strict access. The data remains personal under UK GDPR, but the risk is reduced.
The majority of so-called “AI anonymisation” projects actually produce pseudonymisation. That is the first thing to clarify: everything else — lawful basis, DPIA, retention, international transfers under the UK-US Data Bridge — flows from this.
2026 toolset:
- Large language models (Claude, GPT-4o, Mistral Large): 96-99% accuracy on standard British English, simple to deploy via a prompt, but inference cost and provider dependency.
- Dedicated NER models (spaCy en_core_web_lg, RoBERTa-NER, GLiNER, Microsoft Presidio): faster, more economical at volume, but fixed taxonomy.
- For sovereignty: Mistral on-premise or Llama 3 self-hosted + spaCy in-house, zero data egress to the United States — relevant for NHS data, financial services, and legal professional privilege.
Use cases that hold up: corpus preparation for internal fine-tuning, sharing with academic partners under a Data Sharing Agreement, responding to a subject access request without exposing third-party data, management analysis of internal corpora, sectoral compliance (NHS, legal, financial services), document preparation before calling a SaaS LLM.
Why this topic, why now
Many UK organisations have in mind: “send our documents to an LLM, but without the personal data inside”. The idea is sound. The promise is rarely kept.
Three things have changed in 2026. One, modern LLMs really do NER properly in English — that was not true in 2022. Two, open-source dedicated models (spaCy, GLiNER, RoBERTa-NER) are now within reach of a sovereign deployment — no need to send a single word to OpenAI to anonymise a single word. Three, the regulatory doctrine has hardened on what truly counts as “anonymisation”: the ICO’s 2021 Anonymisation Code of Practice and the EDPB’s Opinion 28/2024 are explicit — pseudonymising is not anonymising.
The trap: believing that a name detector is enough to “exit UK GDPR”. It is not. This article disentangles what works, what does not, and where to draw the line between AI, the organisation, the DPO and the human validation machine.
Anonymisation vs pseudonymisation: the distinction that changes everything
This is the foundation. Everything else — lawful basis, DPIA, processor contracts, retention — depends on this distinction.
Anonymisation under UK GDPR
For data to be truly anonymised, three conditions must be met simultaneously, as set out in the ICO Anonymisation Code:
- No direct re-identification — names, identifiers, NHS numbers, NI numbers are removed or transformed.
- No indirect re-identification — no combination of attributes can isolate an individual. This includes singular contexts (“the only commercial director who left ACME Ltd in March 2025”).
- No re-identification by combination — even by combining with the open Companies House register, an electoral roll, a LinkedIn export or an open public dataset, the individual remains indistinguishable.
If these three conditions are met, the data falls outside the scope of UK GDPR. That is the maximum promise.
Achieving these three conditions is technically very difficult, particularly for free-text documents (emails, meeting notes, contracts). Formal techniques exist — k-anonymity, l-diversity, t-closeness — but they apply mainly to tabular databases, not free-text.
Pseudonymisation under UK GDPR
Article 4(5) of the UK GDPR defines it as “the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures”.
In plain terms: you replace John Smith with Person_001, and you keep a Person_001 → John Smith mapping table elsewhere, under very restricted access. Pseudonymisation strongly reduces risk, but the data remains personal under UK GDPR. All obligations apply: record of processing activities, lawful basis, retention, data subject rights, DPIA where applicable, processor contracts.
Quick decision table
| Criterion | Anonymisation | Pseudonymisation |
|---|---|---|
| Link to the individual | Irretrievably destroyed | Preserved via separate key |
| Subject to UK GDPR? | No | Yes |
| Feasibility on free-text | Very difficult | Feasible with NER + policy |
| Typical use case | Open dataset publication | Internal processing, framed sharing |
| Residual risk | Near-zero (if done well) | Low but non-zero |
| Implementation effort | High | Moderate |
Practical verdict: most so-called “AI anonymisation” projects are in reality pseudonymisation. That is not a weakness, it is a clear framework. The trap is to promise anonymisation and deliver pseudonymisation: compliance collapses, and the DPO discovers the problem six months later — typically during an ICO audit.
NER: what it does, what it does not do
The mechanics
NER (Named Entity Recognition) identifies in a text the named entities belonging to predefined categories. A classic taxonomy adapted for the UK:
| Category | Example | UK GDPR sensitivity |
|---|---|---|
| PER — person | John Smith, Mr Brown | Direct identifier |
| ORG — organisation | ACME Ltd, NHS Trust | Indirect (combined with PER) |
| LOC — location | London, 24 Baker Street | Indirect, sometimes direct (precise address) |
| DATE | 15 March 2026 | Indirect (personal event dates) |
| EMAIL / PHONE / IBAN / NHS_NUMBER / NI_NUMBER | john@acme.co.uk, 07 1234 5678 | Direct identifiers |
| MISC — miscellaneous | Case number, internal reference | Variable |
For pseudonymisation in UK enterprises, this taxonomy is enriched with business categories: NHS patient identifier, customer ID, case number, sensitive amounts, contract identifiers, postcode (the last three digits are highly identifying when combined with age and gender — the famous Sweeney result on US ZIP codes applies just as well to UK postcodes). It is this domain-specific typing work that makes the difference between generic NER and usable pseudonymisation.
Simplified pipeline diagram
[Source text]
│
▼
[NER] → list of detected entities (type, value, position)
│
▼
[Replacement policy] → what to delete, what to pseudonymise, what to keep
│
▼
[Pseudonym generation] → "original → pseudonym" table
│ │
│ ▼
│ [Secure vault]
▼ (re-identification key,
[Pseudonymised text] highly restricted access)The vault is the critical piece. If anyone can access the mapping table, pseudonymisation collapses. This is an architectural point, not an implementation detail — the ICO will examine this exact control during an audit.
What NER does not see
NER, even excellent, misses three families of identifying data:
1. Indirectly identifying data through context. “The commercial director who left ACME Ltd in March 2025 for a competitor” — no proper noun in the sentence, but only one person in the world matches. The NER detects “commercial director”, “ACME Ltd”, “March 2025”. It does not understand that the combination is singular.
2. Rare combinations. “Female, 47, agronomic engineer, living in St Andrews, mother of twins” — no element is identifying in isolation, the combination is strongly so. No NER detects “rare combination”. This is where UK postcode-based attacks bite hardest.
3. Implicit internal references. “As agreed yesterday over the phone, here is the draft letter for the client we discussed” — the NER sees no identifiable entity, yet a human who knows the context knows exactly who is meant.
That is why human review on a sample remains mandatory: 5 to 10% of the corpus at launch, reducible to 1-2% once patterns stabilise. And it is also why we systematically combine NER with a contextual rewriting policy on high-stakes cases: we do not just replace names, we also neutralise singular contexts.
The three technical approaches (plain language)
Approach 1 — Generic LLM with instruction
You give the LLM an instruction like: “identify in this text all named entities and return them in structured form, with their type and position”. Modern models (Claude, GPT-4o, Mistral Large) do this very well on standard British English.
| Advantages | Limitations |
|---|---|
| High accuracy (96-99% on standard English) | Non-trivial inference cost at volume |
| Handles context (useful for ambiguous cases) | Latency (a few seconds per document) |
| Flexible: taxonomy adapted via the prompt | LLM provider dependency |
| No technical learning curve | Possible egress to foreign provider if SaaS |
When it is the right choice: prototypes, low-to-medium volumes (up to a few tens of thousands of documents per month), evolving taxonomy, team without NLP expertise.
Approach 2 — Dedicated NER model (open-source)
Specialised pre-trained model: spaCy en_core_web_lg, RoBERTa-NER, GLiNER, Microsoft Presidio. Runs locally, very fast, low cost.
| Advantages | Limitations |
|---|---|
| Very fast (milliseconds per document) | Fixed taxonomy by default |
| Economical at volume | Performance varies by domain |
| Deployable on-premise, zero egress | More technical setup (Python, model packaging) |
| Mature (spaCy in production since 2015) | Weak context understanding |
When it is the right choice: high volumes (millions of NHS records, financial documents), critical latency, maximum sovereignty requirement, controlled inference budget.
Approach 3 — Hybrid
Dedicated model for fast detection on the bulk flow + generic LLM for complex or ambiguous cases + human review on critical cases.
| Advantages | Limitations |
|---|---|
| Optimum cost / accuracy on large volumes | More complex architecture |
| Robust on atypical cases | Requires an orchestrator (LangChain, custom code) |
| Compatible with sovereignty requirements | Demands metric tracking (LLM fallback rate) |
When it is the right choice: stabilised production, high volumes, high-quality requirement, team able to operate a pipeline.
Quick decision tree
Monthly volume?
│
├── < 10,000 documents
│ └── Critical latency (real-time)?
│ ├── Yes → Dedicated NER (spaCy)
│ └── No → Generic LLM
│
├── 10,000 – 1 million
│ └── Maximum sensitivity (NHS, legal)?
│ ├── Yes → Hybrid on sovereign stack
│ └── No → Sovereign generic LLM (Mistral)
│
└── > 1 million
└── Hybrid mandatory (inference economy + quality)Use cases that hold up
No exhaustive catalogue. Six robust cases, with what you need to know before starting.
Case 1 — Preparing a corpus for internal fine-tuning
Context: a UK organisation wants to adapt an open-source LLM (Llama, Mistral) to its business. It holds a corpus of internal meeting notes, email exchanges, documentation. Without pseudonymisation, this data risks ending up in the weights of the final model and resurfacing through a so-called membership inference attack (“was this document in the training corpus?”).
Typical volume: 10,000 to 500,000 documents.
What can go wrong: incomplete pseudonymisation on internal references (case numbers, project codes) — these references are not seen by NER but enable internal cross-referencing.
Success metric: re-identification rate < 1% on a manual sample post-pseudonymisation.
Case 2 — Sharing with an academic partner or consultant
Context: a UK law firm wants to share a corpus of contracts with a university lab for statistical analysis. An NHS Trust wants to share patient pathway notes with a data consultant for a quality audit.
Typical volume: a few thousand documents.
What can go wrong: underestimating indirectly identifying data. A contract anonymised on the names of the parties may remain identifiable via the case number, the competent court, the registration date.
Safeguard: Data Sharing Agreement (DSA) with the partner, limited retention, provable destruction, audit possible. Pseudonymisation alone does not replace the contract — and for NHS data, a Data Sharing Framework Contract (DSFC) is non-negotiable.
Case 3 — Responding to a subject access request (Article 15 UK GDPR)
Context: an individual requests access to their personal data. They have the right to receive it — but not to obtain in passing the data of other people present in the same documents (emails, meeting notes). NER + redaction of third parties makes the response compliant. The ICO has issued enforcement notices on poorly redacted SARs (e.g. the £1.35m DWP fine context for related disclosure failings).
Typical volume: variable, sometimes a handful of documents, sometimes several hundred.
What can go wrong: over-pseudonymisation that renders the document unintelligible and prevents the requester from understanding their own data.
Safeguard: clear policy on what is redacted and what is kept, validation by the DPO or legal department before sending.
Case 4 — Analysing an internal corpus without unlawful employee surveillance
Context: a leadership team wants to understand recurring topics in internal exchanges (emails, customer support) without crossing the line into unlawful individual surveillance under the Employment Rights Act 1996 and the ICO Employment Practices Code. Pseudonymising senders and recipients allows aggregate analysis.
Typical volume: 10,000 to 1 million messages per month.
What can go wrong: pseudonymisation does not suffice if the analysis indirectly reveals individual behaviour (atypical sending volume, unique time patterns). You must also aggregate before analysis.
Safeguard: prior consultation with employee representatives where applicable, documented DPIA, limited purpose, restricted access to the results.
Case 5 — Sectoral compliance (NHS, legal professional privilege, financial services)
Context: an NHS-adjacent organisation wants to use an external LLM to analyse clinical notes. If the patient identifier is not necessary for the analysis, upstream pseudonymisation allows the content to be sent to a less constrained LLM (Mistral Le Chat Enterprise) instead of imposing a full DSP Toolkit-compliant infrastructure. The Caldicott Principles still apply — pseudonymisation does not exempt the organisation from documenting purpose, necessity, and minimum data use. See our GDPR-compliant AI guide.
Safeguard: DPA with the LLM provider, mandatory DPIA, traceability of every send, retention of the original version in a DSP Toolkit-compliant environment.
Case 6 — Accounting preparation and financial flows
Context: sensitive invoices (supplier invoices including salary data, healthcare invoices in private medical insurance), itemised expense claims. Pseudonymising patient or employee data before processing by a SaaS LLM for structured extraction. See our AI invoice automation guide.
Typical volume: 10,000 to 500,000 documents per month depending on organisation size.
Reference architecture: what we actually build
A production AI anonymisation pipeline breaks down into seven stages. Each has its pitfalls.
Stage 1 — Ingestion. The document arrives in raw format: PDF, Word, email, database export, scanned image. For non-textual documents, prior OCR (Tesseract, AWS Textract in London region, Doctly). At this stage, we keep the original encrypted for audit.
Stage 2 — NER detection. LLM or dedicated model identifies entities. Output: structured list {type, value, start_offset, end_offset}. For long documents, we chunk into blocks of a few thousand characters with overlap; otherwise models miss entities straddling boundaries.
Stage 3 — Replacement policy. Business decision, not technical:
- Categories to delete (clean removal, e.g. card numbers in emails)
- Categories to pseudonymise (replacement by stable pseudonymous identifier, e.g. names of individuals)
- Categories to keep (useful for downstream use, e.g. dates if they serve temporal analysis)
Stage 4 — Pseudonym generation. John Smith → Person_001. The pseudonym must be stable (the same individual receives the same pseudonym across all documents) and uncorrelated to the original value (no hash of the value — a hash can be attacked by dictionary if the domain is small). The mapping table is stored in a separate vault.
Stage 5 — Application to text. Effective replacement. Watch out for word boundaries, case, accents, spelling variations. A John Smith may appear later as Mr Smith, J. Smith, Smith — the NER must link these forms (a process called coreference resolution).
Stage 6 — Validation. Human review on a sample (5 to 10% at launch, reducible to 1-2% after stabilisation). We measure:
- Missed entity rate (recall)
- False positive rate (precision)
- Presence of residual indirectly identifying data
Stage 7 — Audit and logs. Separate retention:
- Original encrypted document (in case of dispute, SAR, audit)
- Pseudonymised document (for downstream use)
- Mapping table (vault, highly restricted access)
- Access logs (who saw what, when)
Simplified production diagram
[Source] [Processing] [Destinations]
│ │ │
▼ ▼ ▼
PDF / email ──► OCR ──► NER ──► Policy ──► Pseudo. ──► SaaS LLM / fine-tune / sharing
│ │
└─► Audit ──┘
│
▼
Key vault (strict access)
Encrypted original (DSP Toolkit if NHS)The re-identification trap
This is the ultimate test. Pseudonymisation that does not withstand combination attacks is not usable pseudonymisation — and the ICO will say so during an audit.
Three classic attacks
Attack 1 — Combination with an open source. The attacker has access to the electoral roll, Companies House data, a LinkedIn export. They cross-reference the remaining attributes in the pseudonymised document (age, town, occupation, employer) with these sources. If a combination is unique, re-identification succeeds. The famous Sweeney study (1997) showed that 87% of US individuals are uniquely identified by ZIP + DOB + gender — UK postcodes give similar results.
Attack 2 — Inference by context. The attacker knows the domain. They know that only one commercial director left ACME Ltd in March 2025. They deduce the identity.
Attack 3 — Membership inference (on fine-tuned LLM). An attacker queries a model fine-tuned on a pseudonymised corpus to guess whether a given individual was in the training set. If the model has overfitted, it leaks information. The 2023 Carlini et al. work on extraction attacks against GPT-2 made this a board-level concern.
Three defences
Defence 1 — k-anonymity (for tabular databases). Each combination of attributes appears at least k times in the dataset. If k = 5, each profile is indistinguishable from at least 4 others. On free-text, partial transposition via generalisation: “47” → “40-50”, “agronomic engineer in St Andrews” → “professional in Scotland”.
Defence 2 — l-diversity and t-closeness. Extensions of k-anonymity that also constrain the diversity of sensitive values within each group. Useful when sensitive data (health, opinion) is at the heart of the dataset.
Defence 3 — Re-identification testing. More pragmatic: actively attempt to re-identify on a sample. If you succeed too easily, pseudonymisation is insufficient. This practice is expected by the ICO for sensitive projects under the Anonymisation Code.
None of the three protects fully. The practical rule: explicitly test robustness before going to production, and document the tests.
UK GDPR compliance: what is actually expected
AI anonymisation/pseudonymisation is itself an automated processing of personal data. Therefore subject to UK GDPR. Here is what to record, and what you must be able to produce in case of an ICO audit.
Article 30 record of processing
A dedicated entry: “automated pseudonymisation by NER for [specific purpose]”. You record:
- Purpose (e.g. preparing a corpus for fine-tuning, sharing with partner X, analysing internal emails)
- Categories of data processed (free-text, types of entities detected)
- Data subjects (customers, employees, NHS patients depending on case)
- Retention (of the original, of the pseudonymised version, of the mapping table — each justified)
- Processors (LLM provider, hosting)
- Technical and organisational measures
Lawful basis
Depending on context:
- Legitimate interest (Article 6(1)(f) UK GDPR): the most frequent case for internal processing, subject to documenting the Legitimate Interest Assessment (LIA) — purpose vs data subjects’ rights.
- Performance of a contract: if processing flows directly from contract performance with the individual.
- Legal obligation: rare, but possible (responding to a SAR, for example).
- Consent: exceptionally, and to be avoided if another basis is available — consent can be withdrawn.
DPIA (Data Protection Impact Assessment)
Recommended in most cases, mandatory in several scenarios listed by the ICO:
- High volumes
- Special category data (health, political opinions, biometrics, criminal offence data)
- Large-scale processing
- Systematic monitoring of employees
- Data matching across sources
The DPIA documents the residual risk after pseudonymisation, justifies technical choices, and formalises access control to the key. It must be available to the ICO upon request. See our AI DPIA practical guide.
DPA with the LLM provider
If you use a SaaS LLM, the processor contract (DPA) must cover:
- Processing location (ideally EU/UK — Mistral, Scaleway, AWS London)
- Prohibition on using data to train the model
- Retention of prompts and completions
- Sub-processors (hosting, backups)
- Incident notification arrangements
With a sovereign European provider, the DPA is significantly simpler. With a US provider, it becomes a technical dossier in its own right (UK International Data Transfer Agreement, transfer impact assessment under the post-Schrems II framework, sometimes unusable depending on the nature of the data — particularly for NHS or financial services data).
Processing location
For sensitive data (NHS, legal professional privilege, financial services, salary data), location is a topic in its own right. Three levels:
- Sovereign cloud (Scaleway, OVHcloud London, UKCloud) — data remains in the UK or EU, under European law, no exposure to seizure under the US Cloud Act.
- On-premise — the AI runs on the organisation’s servers, zero data egress. See our local LLM in business guide.
- Foreign cloud with contractual safeguards — possible but with substantial documentation burden, and a non-zero residual risk. The UK-US Data Bridge helps for some flows but does not cover all use cases.
For most sensitive UK cases, you keep either a sovereign provider (Mistral La Plateforme) or on-premise. This is the approach DPLIANCE takes for its clients, in the context of custom AI solutions.
What we refuse to promise
Three antipatterns we regularly see in projects, and which we avoid at DPLIANCE.
“We will anonymise, so we exit UK GDPR.” No, except in very exceptional cases. Pseudonymisation remains under UK GDPR. If exiting UK GDPR is necessary for the project, the project must be redesigned — not the meaning of words twisted. The ICO Anonymisation Code is explicit on this.
“NER detects everything, we don’t need human review.” No NER detects singular contexts, rare combinations, implicit references. Human review on samples is non-negotiable at launch, and remains recommended in steady state.
“We keep the re-identification key, but we lock it down well.” If the key remains accessible to several people, pseudonymisation becomes theoretical. UK GDPR practice expects highly restricted access, logged, with an exceptional and traced recovery process.
FAQ
What is the practical difference between anonymisation and pseudonymisation under UK GDPR?
Anonymisation is irreversible: it becomes impossible to identify the individual, even by combining with other sources, even with a key. The data falls outside the scope of UK GDPR and the Data Protection Act 2018 — the ICO Anonymisation Code of Practice (2021 update) confirms this. Pseudonymisation is reversible: a pseudonymous identifier replaces the direct identifiers, but a re-identification key exists elsewhere under strict access. The data remains personal under UK GDPR. Practical consequence: the majority of so-called “AI anonymisation” projects actually produce pseudonymisation. UK GDPR obligations continue to apply (record of processing activities, lawful basis, DPIA where required), even if the risk has been reduced.
Is NER (Named Entity Recognition) enough to anonymise a text?
No, almost never. NER detects explicit named entities: names, surnames, phone numbers, addresses, IBANs, NHS numbers, NI numbers, dates. It systematically misses indirectly identifying data: precise descriptions (“the commercial director who left ACME Ltd in March 2025”), singular combinations (age + town + occupation), internal references (case number correlated with a client), contextual phrasings. Rigorous anonymisation requires NER + contextual analysis + human review on critical cases + robustness testing against re-identification — exactly what the ICO Anonymisation Code of Practice expects.
What accuracy can be expected from a 2026 NER AI in English?
On standard British English, a modern LLM (Claude, GPT-4o, Mistral Large) detects 96 to 99% of explicit named entities with a well-crafted prompt. Dedicated models (spaCy en_core_web_lg, RoBERTa-NER, GLiNER multilingual) reach 93 to 99% F1 depending on the domain. Performance drops sharply on: foreign or rare names, mixed languages (Welsh, Gaelic, Punjabi), trade abbreviations, implicit references within the text. No model reaches 100% — that is why human review on a sample remains indispensable at launch.
Generic LLM or dedicated NER model?
For most cases in 2026, a well-prompted generic LLM (Claude, GPT-4o, Mistral) is sufficient with accuracy above 95%. A dedicated NER model (spaCy en_core_web_lg, RoBERTa-NER, fine-tuned model) becomes relevant when volume is very high (millions of documents per month), latency is critical (real-time triage in NHS or financial services), or context is ultra-specialised (clinical terminology, legal terminology). The simple rule: start with a generic LLM for the prototype, switch to a dedicated model if inference cost or performance justifies it.
Does NER-pseudonymised data remain subject to UK GDPR?
Yes. UK GDPR considers data to remain personal as long as re-identification is possible — directly, indirectly, by combination with other sources, or via the pseudonymisation key. Pseudonymisation reduces risk but does not remove the data from UK GDPR scope. To achieve genuine anonymisation under UK GDPR, the key must be destroyed, indirectly identifying data must be removed, and the dataset must withstand combination attacks. This is technically very difficult — the ICO’s 2021 Anonymisation Code is explicit on the bar.
Which use cases really hold up for UK organisations?
Six robust use cases: (1) preparing a corpus for fine-tuning an internal model without leakage risk; (2) sharing a dataset with a consultant or academic partner under a Data Sharing Agreement; (3) responding to a subject access request (Article 15 UK GDPR) without exposing third-party data; (4) analysing internal corpora (emails, meeting notes) for management purposes without crossing into unlawful surveillance under the Employment Rights Act and ICO Employment Practices Code; (5) sectoral compliance (NHS data under the Caldicott Principles, legal professional privilege, financial services); (6) preparing documents before sending to a SaaS LLM to reduce exposure.
Which tools support sovereign AI anonymisation in 2026 for the UK?
Sovereign generic LLMs: Mistral Large via La Plateforme (EU), Mistral on-premise via vLLM, UK-hosted deployments (AWS London, Azure UK South, OVHcloud London) on independent infrastructure. Open-source dedicated models: spaCy en_core_web_lg (excellent performance/cost ratio for British English), RoBERTa-NER, GLiNER multilingual. Microsoft Presidio is an excellent open-source framework but its default inference goes through OpenAI — to be rewired to a sovereign provider or local. For maximum sovereignty: Mistral on-prem or Llama 3 self-hosted + spaCy in-house, zero data egress.
Is a DPIA required for an AI anonymisation project?
Recommended in most cases, mandatory in several: high volumes, special category data (health, biometrics, criminal offence data under DPA 2018), large-scale processing, systematic monitoring of employees, data matching across sources. The logic: AI anonymisation is itself an automated processing of personal data, therefore subject to UK GDPR. The DPIA documents the residual risk after pseudonymisation, justifies technical choices, and formalises access control to the re-identification key. The ICO maintains an indicative list of operations requiring a DPIA on ico.org.uk.
Sources: UK General Data Protection Regulation, Articles 4(5) and Recital 26; Data Protection Act 2018; ICO Anonymisation, pseudonymisation and privacy enhancing technologies guidance (2021 Code of Practice); EDPB Opinion 28/2024 on certain data protection aspects of AI models; Caldicott Principles (eight principles, 2020 update); official documentation for spaCy, Microsoft Presidio, GLiNER, RoBERTa-NER; Mistral AI La Plateforme documentation.
To frame an AI anonymisation project in your organisation — tool choice, methodology, pipeline, compliance — see our GDPR-compliant AI guide, our AI DPIA practical guide, our local LLM in business guide, or contact us via our custom AI solutions.