Introduction: Between Data Protection and Technical Feasibility
AI models like ChatGPT, image recognition systems, or candidate scoring algorithms have long been a fixed part of many business processes in Europe. But as their capabilities grow, so does the pressure to consistently implement data protection requirements like the right to be forgotten. Things get especially complex when personal data is embedded not just in databases, but in the "learned knowledge" of the models themselves. This guide explains why deletion is so challenging in the world of AI, which legal and technical pitfalls companies need to watch out for — and, with the EU AI Act in effect since August 2025, how to implement practical, GDPR-compliant strategies.
What Does the Right to Be Forgotten Say?
The "right to be forgotten" under Article 17 GDPR requires companies to permanently delete personal data upon request — for example, when consent is withdrawn, a purpose has been fulfilled, or processing was unlawful.
Relevance for AI systems:
Many companies use personal data to improve algorithms — for example:
- for behavioral analysis in e-commerce
- for chatbots with personalized responses
- in candidate scoring systems
But: if this data has to be deleted later — what happens to the AI model that was trained on it?
The core problem: the GDPR doesn't distinguish between a classic database and a trained model. This creates uncertainty — because "learned knowledge" can also be personal data if it can be traced back to an individual.
Why AI Models Are Problematic
An AI model "learns" by processing training data. This produces model weights or vector representations that aren't structured or deletable like classic data records.
Example 1 — A chatbot trained on CRM data:
A chatbot is trained on real customer inquiries from the CRM, including names, issues, and order numbers. Even if the original data is deleted, the patterns remain embedded in the model.
Example 2 — Applicant management with AI:
HR software uses candidate profiles to improve its scoring. Even if a candidate's record is deleted, the model may continue using their writing style or criteria patterns — indirectly linked to that person.
Risk: if this data can later be reconstructed or plays a decisive role in decisions, that constitutes a data protection violation.
What to Do With a Deletion Request?
When a deletion is requested, the question arises: does the AI model need to be retrained or adjusted?
The GDPR doesn't give a clear answer, but according to supervisory authorities, the following applies:
If the trained model stores personal information or makes it reproducible, the model itself is also subject to the deletion obligation.
Real-world example:
Meta has already been criticized by data protection authorities because training data containing personal content in its LLMs (large language models) could no longer be fully deleted. There's a growing expectation that AI systems will be able to respond to data deletion requests in a traceable and reversible way.
Typical problems in companies:
- The model was trained on live customer data, but no log exists
- No versioning → it's unclear which data is embedded in which model
• • The deletion request also concerns data that was relevant to the training objectives
Technical Approaches
This is where AI engineering and data protection intersect — there are technical options for making the right to be forgotten a practical reality:
1. Machine Unlearning
Targeted removal of individual training data points from a model, without a complete retrain.
- Works well for simple models (e.g., decision trees)
- More difficult for deep neural networks
2. Differential Privacy
The model is trained so that no conclusions can be drawn about individual data points.
- Used by OpenAI, Google, and Apple
- Well suited to aggregated data, less so for individual contexts
3. Retraining With a Deletion List
The model is regularly retrained — without the deleted data.
- Very reliable
- But: labor-intensive, expensive, and only practical for large companies
4. Federated Learning
Data stays decentralized — models learn locally and are then merged centrally.
- Advantage: deletions can be implemented locally
- Complex to integrate
Tip: for companies handling many deletion requests, a "model-centric" deletion process with automated audit trails and versioning is worthwhile.
What Companies Should Do Now
The deletion obligation does not stop at the CRM or the cloud — it increasingly applies to algorithmic systems too. That's why companies need:
1. Privacy by design for AI systems
- Clarify early on: which data may be used?
- Pseudonymize or aggregate training data wherever possible
2. Model documentation
- Who trained what with which data?
- Which models are in use? Which version contains which data?
3. A process for deletion requests
- Cross-functional, involving data protection, IT, and data science
- Automated checks to determine whether models are affected
- Model retraining or replacement where necessary
4. DPIA (Data Protection Impact Assessment)
- Especially for sensitive models (HR, health, behavior, risk scoring)
- Must assess whether data subject rights are technically enforceable
Conclusion
The right to be forgotten poses real challenges for AI developers and companies — but it's solvable. With documented data flows, technical "unlearning," and clear responsibilities, even the world of AI can become GDPR-ready.
Companies building AI models today need to factor in reversibility from the start — otherwise, they risk expensive retraining, fines, and reputational damage.
EU AI Act: Guide to AI Compliance | heyData
Learn what the EU AI Act requires of companies and how to manage AI risks, documentation, oversight, and governance in a structured way.
Free & no obligation
FAQ
Why is implementing the "right to be forgotten" so difficult for AI models?
Why is implementing the "right to be forgotten" so difficult for AI models?
While an entry in a classic database can simply be deleted, AI models process and weave training data into mathematical patterns (model weights). Even if the original dataset is deleted, the learned knowledge can remain in the model and theoretically be reconstructed. Since the GDPR also applies to indirectly personal information in models, this poses major technical challenges for developers.
Does an AI model need to be retrained if a user requests deletion of their data?
Does an AI model need to be retrained if a user requests deletion of their data?
If a model can still store or reproduce personal information, supervisory authorities hold that the deletion obligation also applies to the model itself. To avoid having to completely retrain the model each time at extremely high cost and effort (retraining), technical approaches such as machine unlearning (targeted removal of individual training data) and differential privacy are gaining importance.
Which technical methods help make AI systems compliant with data protection law?
Which technical methods help make AI systems compliant with data protection law?
The most important approaches include:
- Machine unlearning: Removing individual data points from the model without complete retraining.
- Differential privacy: A mathematical method that ensures conclusions about individuals in the model are ruled out.
- Federated learning: Decentralized learning in which data remains on local devices and deletions can easily be implemented locally.
- Regular retraining: Retraining the model based on a cleaned training database / deletion list.
What specific steps should companies take to prepare for deletion requests affecting AI systems?
What specific steps should companies take to prepare for deletion requests affecting AI systems?
Companies should apply the principle of privacy by design:
- Minimize training data: Anonymize, pseudonymize, or aggregate data before training.
- Model documentation & versioning: Keep complete records of which datasets are included in which model version.
- Clear deletion request process: Set up automated workflows between IT, data science, and data protection to check whether and how AI models are affected by a data subject request.
