Two Regulations, One Solution
ML engineers building on EU data face two regulatory frameworks with overlapping requirements:
- GDPR Article 5(1)(c): Data minimization — personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.”
- GDPR Article 25: Data protection by design — technical measures to minimise personal data processing must be implemented by design, not as an afterthought.
- EU AI Act Article 10(5): Training, validation and testing data “shall be free of personal data where technically feasible.”
The good news: the anonymization standard that satisfies GDPR simultaneously satisfies the EU AI Act. Data that meets GDPR Recital 26 (“no reasonable means of re-identification”) is not personal data under either framework. One implementation, two frameworks, continuous compliance.
What "Free of Personal Data Where Technically Feasible" Actually Means
Regulators and courts will interpret “technically feasible” broadly. The standard is not “whether it is possible to build PII detection.” The standard is effectively “whether commercially available tools exist.” Given that production-ready PII anonymization APIs exist (including this one), most organisations cannot credibly argue that anonymizing structured text is infeasible.
The phrase “where technically feasible” is primarily intended to address edge cases like medical imaging, voice recordings, and video data where complete de-identification may compromise the training signal. For text data — the most common LLM training modality — technical feasibility is essentially presumed.
The 4 Types of PII in AI Training Data
1. Direct Identifiers
These are unambiguously personal: full names, email addresses, social security numbers, passport numbers, phone numbers, date of birth combined with name, home addresses. Direct identifiers must always be anonymized. There is no legitimate argument for preserving them in LLM training data.
2. Quasi-Identifiers
Individually not identifying, but dangerous in combination: date of birth without name, ZIP code, job title, employer, nationality. A landmark study by Latanya Sweeney showed that 87% of Americans can be uniquely identified by just three quasi-identifiers: 5-digit ZIP code, birth date, and sex. LLMs trained on quasi-identifiers may learn to synthesize identifying combinations even without direct PII in the training data.
3. Sensitive Categories (GDPR Article 9)
Receives heightened protection under GDPR: health and medical data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, sexual orientation, criminal convictions. Sensitive category data in training corpora creates compounded compliance risk: GDPR Article 9 violations, potential EU AI Act high-risk AI classification triggers, and HIPAA violations for health data.
4. Generated PII (Model Output Risk)
A less-discussed risk: LLMs trained on corpora containing real personal data may generate realistic-looking personal data in their outputs. A model trained on email datasets may produce output that resembles real email addresses. A model trained on medical records may generate plausible-but-fictional patient data that could be confused with real records. Anonymizing training data eliminates this class of output risk entirely.
Consistent Pseudonymization: Why It Matters for RAG
For RAG (Retrieval-Augmented Generation) pipelines, the most important property of training data anonymization is consistency: the same real entity must always map to the same pseudonym.
Consider a support ticket dataset used to fine-tune a customer service LLM. If “Sarah Chen” appears in 23 tickets but is replaced with “PERSON_1” in some tickets and “PERSON_7” in others, the model learns that these are 23 different entities. The relationship between tickets is destroyed. Retrieval quality degrades because the model cannot associate related interactions.
With consistent pseudonymization, “Sarah Chen” → “Emma Williams” in every occurrence across the entire corpus. The model learns the correct relationship structure. The pseudonym is consistent, so similarity search and entity co-reference work correctly.
The 5-Step Anonymization Pipeline for Training Data
Catalogue Your Training Data Sources
Before processing, document every training data source: origin, collection date, whether consent was obtained (if applicable), what personal data categories are present. This catalogue becomes the foundation of your Article 11 technical documentation and your GDPR Records of Processing Activities (ROPA).
Run a PII Discovery Scan
Before applying anonymization, run a detection-only scan to quantify the PII exposure in your raw dataset. This gives you a baseline for your compliance documentation and helps you tune detection sensitivity. For web-based sources, use piisafe.eu. For file batches, use the REST API in detection mode.
Apply Consistent Anonymization
Process your entire training corpus with consistent pseudonymization enabled. Use a single session ID for all documents in a training batch to ensure cross-document entity consistency. For multilingual corpora, specify all languages in the request so cross-language entity matching works correctly (a German document mentioning “Karl Schmidt” and an English document mentioning the same person should receive the same pseudonym).
Validate Anonymization Quality
After processing, run a second detection scan on the anonymized corpus to measure residual PII. The target is zero detected entities. Any remaining detections represent either false negatives (real PII missed) or false positives (non-PII incorrectly identified as PII in the validation scan). Review flagged instances manually to determine which category they fall into.
Archive the Audit Trail
Export the detection and anonymization logs as CSV or JSON. Archive them with your training run metadata. Include: date processed, anonymize.solutions version used, entity types targeted, total entities replaced, detection confidence scores, and the session ID (which allows the mapping to be reconstructed for authorised legal review if required).
What to Document for Compliance
For GDPR ROPA and EU AI Act Article 11 technical documentation, your anonymization section should include:
- Training data sources and legal basis for original collection
- Date anonymization was applied and version of tools used
- Entity types targeted (with reference to the 320+ entity type list)
- Anonymization method used (replace/mask/hash/encrypt/pseudonymize)
- Consistency approach for cross-document entity mapping
- Validation scan results (before and after entity counts)
- Infrastructure certification (ISO 27001:2022, Hetzner Germany)
- Re-identification risk assessment conclusion
Conclusion: Anonymize First, Train Second
The ML teams that will avoid regulatory problems are the ones who make anonymization a step in their data pipeline — not an afterthought after training is complete. Retroactively removing PII from a model is not technically possible; you must retrain from scratch. Building anonymization into your pipeline from day one costs a few minutes of API calls per training batch. Building it after an enforcement action costs months of retraining, legal fees, and potential fines.
Ready to implement? The anonymize.solutions REST API processes training data batches in minutes. The consistent pseudonymization feature preserves entity relationships for RAG pipelines. View the API documentation or request a demo to discuss your specific training data architecture.