Pseudonymisation Pipelines That Hold Up Under Scrutiny

Why Pseudonymisation Matters

Your data teams face pressure from two sides. Generative AI projects demand large volumes of personal data for training, while connected devices like smart glasses generate continuous streams of video and audio, capturing people who haven't interacted with your Consent Management Platform. The European Data Protection Board (EDPB) has addressed these issues in recent outputs, including Guidelines 03/2026 on web scraping in generative AI and Statement 1/2026 on smart glasses. It has also issued Guidelines 01/2025 on Pseudonymisation.

Pseudonymisation is the control that balances between "we can't use this data" and "we're using it without safeguards." Yet, it's often misapplied. The key distinction is legal, not technical. Under GDPR Article 4(5), pseudonymised data can't be attributed to a specific person without additional information that is kept separately and protected. It remains personal data. Anonymised data falls outside GDPR; pseudonymised data does not. Treating the two as interchangeable skips obligations like Legal Basis for Processing, Purpose Disclosure, and data subject rights.

This guide walks you through a defensible implementation.

Preparation Before Implementation

Before you start, gather these essentials:

• Processing Inventory: Identify datasets with direct identifiers (names, emails, device IDs) and indirect identifiers (timestamps, location, rare attribute combinations).
• Documented Purposes: Define each downstream use, like model training or analytics. Your pseudonymisation strategy depends on these purposes.
• Threat Model: Identify who you're protecting against: internal analysts, a processor, a third-party recipient, or an external attacker.
• Access to EDPB Guidelines 01/2025: Use this as your reference for terminology and expectations.
• Secrets-Management System: Use an HSM or managed KMS for holding keys and lookup tables.
• Owner for "Additional Information": Assign a role, not a team alias, for managing this information.

Step-by-Step Implementation

Step 1: Define the Pseudonymisation Domain. Decide the scope within which pseudonyms are linkable. A single domain (one project, one recipient) is safer than a global one. Avoid creating a Universal Identifier that links data across analytics, marketing, and AI training sets.

Step 2: Classify and Select Fields. Mark fields as direct identifiers, quasi-identifiers, or non-identifying. Transform direct identifiers. Generalise or suppress quasi-identifiers (coarsen timestamps, bucket locations, truncate postcodes). Avoid leaving exact timestamps and precise locations untouched.

Step 3: Choose the Transformation. Match the technique to the use case:

• Keyed Hashing (HMAC-SHA-256): Deterministic, keeping records linkable within the domain. The key is the protected "additional information."
• Tokenisation with a Vault: Random tokens, with the mapping table stored separately. Useful for reversibility under strict controls.
• Format-Preserving Encryption: Useful when downstream systems require a fixed format.
• Random Per-Record IDs: Strongest when linkage isn't needed.

Avoid plain unsalted hashing of low-entropy values. A minimal keyed example:

pseudonym = HMAC_SHA256(domain_key, normalise(email))

Step 4: Separate the Additional Information. Store keys and lookup tables in a different system with different access controls from the pseudonymised dataset. Log every key access and restrict re-identification to the smallest necessary group.

Step 5: Apply at the Ingestion Boundary. Pseudonymise data as early as practical, ideally before it lands in the analytics warehouse or AI training corpus. For scraped or third-party sources, do this before storage and keep your Legal Basis for Processing documented separately.

Step 6: Handle Continuous-Capture Data. For smart-glasses-style streams, pseudonymisation of metadata won't address faces and voices in the content. Apply on-device or at-edge minimisation (blurring, discarding raw frames, short retention) and treat the content as identifiable.

Step 7: Document It. Record the technique, domain, key custodian, re-identification procedure, and residual risk in your DPIA and processing records. This supports Data Protection by Design under Article 25.

Validation: How to Verify It Works

Run these checks before release and after any schema change:

1. Re-identification Test: Have someone outside the build team try to link pseudonymised records back to people using only the dataset and realistic auxiliary data.
2. Uniqueness Check: Query for rare combinations of quasi-identifiers. Unique records on a few fields can be re-identified by inference.
3. Key-Separation Audit: Ensure no account with dataset access also has key store access. Test with real credentials.
4. Determinism Check: Confirm the same input produces the same pseudonym within a domain and a different one across domains.
5. Leak Scan: Search logs, error output, and debug dumps for raw identifiers that bypassed the pipeline.

Ongoing Maintenance

• Rotate Keys on a defined schedule and plan for re-pseudonymisation.
• Review Quasi-Identifiers when new fields are added. New columns can undo protections.
• Re-run Re-identification Tests when new datasets or AI techniques change potential attacker capabilities.
• Audit Access to additional information regularly and remove stale permissions.
• Handle Data Subject Requests with a clear process. If you can re-identify, you can respond to access and erasure requests.
• Track EDPB Output. Update your approach as Guidelines 01/2025 and related guidance evolve.

Pseudonymisation lowers risk but doesn't remove your obligations. Build your pipeline as if a regulator will ask you to demonstrate each step, because one day they might.