EDPB Guidelines 02/2026: The New Rules for Data Anonymisation in AI

Under EDPB Guidelines 02/2026 on Anonymisation, data is only considered anonymous if three cumulative risks are eliminated: singling out, linkability, and inference. The Board confirms anonymity is relative to the recipient, meaning pseudonymised internal datasets shared with third parties or fed into machine learning pipelines remain subject to the GDPR unless re-identification is technically impossible for that recipient.

For European startups and scale-ups building or fine-tuning models, "anonymising" production logs or customer datasets is often treated as an escape hatch from GDPR compliance. The European Data Protection Board (EDPB) just closed that loophole. Replacing the historical Article 29 Working Party Opinion 05/2014, Guidelines 02/2026 establish strict, mathematically grounded criteria that engineering and privacy teams must satisfy before stripping data of its personal data classification.

Who is actually in scope?

Any enterprise operating within the EEA that processes personal data to train models, publish analytics, or share data assets with external partners falls under these guidelines.

This directly impacts:

• AI Providers and Deployers: Teams training LLMs or computer vision models on user data and claiming the training corpora are "anonymised" under the AI Act.
• B2B SaaS Platforms: Companies aggregating client metrics or telemetry to publish benchmarks or feed secondary recommendation engines.
• HealthTech and FinTech Startups: Organizations dealing with Article 9 special-category data that attempt to strip direct identifiers like names or social security numbers while preserving high-dimensional behavioral records.

If your system retains high-dimensional metadata, the EDPB presumes the data is merely pseudonymised—not anonymised. Consequently, all core obligations under GDPR, including mandatory DPIA documentation and Article 30 records of processing (ROPA), continue to apply.

What documentation is required by Guidelines 02/2026?

The EDPB makes one thing clear: subjective assumptions do not count as proof. Data controllers must document a formal Anonymisation Assessment Report before treating any dataset as out of scope of data protection law.

Your technical documentation must establish three concrete barriers:

1. Elimination of Singling Out: You must demonstrate that an attacker or recipient cannot isolate records belonging to a specific individual, even through outlier analysis or clustering.
2. Elimination of Linkability: You must mathematically prove that records in your dataset cannot be linked to external auxiliary databases, voter rolls, public social media profiles, or third-party datasets.
3. Elimination of Inference: You must prove that an observer cannot deduce confidential attributes of an individual with significant probability, even if their direct identity is masked.

Furthermore, Guidelines 02/2026 adopt a recipient-dependent standard aligned with recent European case law. A dataset may be considered non-personal data in the hands of an external research partner who lacks access to decryption keys or auxiliary databases, while remaining personal data in your internal storage. Your documentation must evaluate the specific threat model and available auxiliary knowledge of each intended recipient.

What are the penalties for non-compliance?

Treating personal data as anonymous without meeting the EDPB thresholds constitutes unlawful data processing under Article 6 and a breach of transparency under Articles 12, 13, and 14.

European DPAs—including the CNIL, BfDI, and Garante—regularly treat flawed anonymisation as an unnotified data breach and an unlawful processing activity:

• Administrative Fines: Statutory penalties reach up to €20,000,000 or 4% of total worldwide annual turnover, whichever is higher under GDPR Article 83(5).
• Corrective Sanctions: DPAs have the statutory authority under Article 58(2) to order the immediate cessation of processing and the total deletion of training datasets and derivative AI model weights built on improperly anonymised data.
• AI Act Spillover: Under the AI Act, deploying high-risk systems built on unlawful datasets creates severe regulatory exposure, compounding liability across both data protection and product safety regimes.

What should SMEs do first?

European tech SMEs cannot afford to rebuild models or face corrective orders after deploying to production. Take these four practical steps today:

• Audit Current Pseudonymisation Pipelines: Review tokenization, hashing, and masking routines. If you retain salted hashes where the salt is stored internally, the output is pseudonymised data under Article 4(5), not anonymous data.
• Conduct Adversarial Re-Identification Testing: Run empirical re-identification attacks against your aggregated tables using differential privacy metrics or k-anonymity scoring before exporting data to external cloud environments.
• Update Your Processing Records: Ensure that the transformation of personal data into anonymous datasets is documented as a distinct processing operation in your ROPA, backed by an appropriate legal basis under Article 6(1).
• Prepare Review-Ready Evidence: Maintain version-controlled Anonymisation Assessment Reports alongside your DPIA files to present immediately if requested during a DPA inquiry or client security audit.

Disclaimer: EuroComply provides compliance readiness tools and evidence drafts. This guide is for informational purposes and does not constitute legal, regulatory, or compliance advice. Have technical documentation and assessments reviewed by qualified counsel.