Retention periods: should data still present in a trained model be deleted?

In Europe, the General Data Protection Regulation (GDPR) requires data controllers to adhere to strict retention periods. However, artificial intelligence (AI) models often retain undetectable traces of every observation used for training within their parameters. When personal data must be erased, is it sufficient to remove it from the source dataset, or must the model also be 'un-trained'? This article analyses legal requirements, technical and operational risks, 'machine unlearning' solutions, and best practices to balance compliance, performance, and cost management.

Introduction

Imagine a customer requests the deletion of their personal information by exercising their right to erasure (Article 17 of the GDPR). Your data science team has already integrated this data into a recommendation model that powers your e-commerce site's engine. The data no longer appears in the databases, but the neural network weights continue to carry its trace. If the data protection authority (DPA) were to audit your system, could you demonstrate that the right to erasure has been fully respected?

This situation is now recurring across all sectors leveraging machine learning (ML): healthcare, finance, human resources, and marketing. The boundary between 'raw data deletion' and 'erasing knowledge embedded in the model' is no longer purely theoretical. Legislators are beginning to take interest – the CNIL published a guide on the right to be forgotten and AI systems in 2022, and the European Data Protection Board (EDPB) is working on guidance regarding the 'right to be forgotten for AI models'.

This article provides a structured analysis to help CIOs, CISOs, AI leads, and decision-makers determine when and how to actually delete information contained within a trained model.

1. Legal framework for retention periods

Key takeaways

• The GDPR considers data as "personal" as soon as it allows, directly or indirectly, the identification of an individual. A model trained on personal data may therefore be assimilated to personal data if it enables the reconstruction, even partially, of the original information.
• Case law (Google Spain 2014) has already established that search results are subject to the right to erasure when they reveal personal facts. By analogy, a model that generates or influences responses containing elements of deleted data may be concerned.
• The obligation for "documentation and traceability" (Art. 30 GDPR) requires organisations to be able to justify the process followed to erase data – including at the model level.

2. The learning model as a data reservoir

2.1 How is information memorised?

During supervised training, each observation adjusts the model's parameters (weights) to reduce error on the dataset. Updates are typically performed via stochastic gradient descent or its variants (Adam, RMSProp). This process does not retain raw data but creates a statistical footprint:

• Local memorisation: neuron weights can become heavily influenced by rare or atypical examples.
• Overfitting: the model faithfully reproduces certain inputs, increasing the probability of reconstructing individual data points.
• Embedding vectors: in language or recommendation models, each entity (user, product) is represented by a vector learned from past interactions – these vectors are directly derived from the original data.

2.2 When does the model become personal data?

• Direct re-identification: if it is possible to query the model and obtain, through sufficient requests, text or an image that exactly reproduces the deleted data.
• Parameter extraction: inference attacks (model inversion) allow for the recovery of sensitive attributes from published weights or those accessible via an API.
• Linkage: when a model is combined with other sources, correlations can reveal a person's identity.

These scenarios are described in academic literature: Fredrikson et al., « Privacy in Machine Learning », 2015 [1]; Nasr et al., « Machine learning models are vulnerable to attribute inference attacks », 2019 [2].

3. Risks associated with data persistence in models

4. Machine unlearning techniques and technical mitigation

4.1 Overview of approaches

4.2 Practical Implementation

• Model Inventory
• Catalogue each artefact (type, version, training sets, hyperparameters).
• Identify models that have been trained on data subject to limited retention periods.

• Influence Evaluation
• Use influence metrics (e.g., Cook’s distance adapted for neural networks) to quantify the contribution of an observation to the model.
• Prioritise models where influence is high, as the risk of residual data is greater.

• Method Selection
• Small datasets / simple models: full retraining remains the gold standard.
• Large-scale models (LLMs, vision): combine DP during training and exact unlearning for ad hoc requests.
• Latency-sensitive environments: approximation via fine-tuning or pruning.

• Unlearning pipeline automation
• Integrate an 'unlearn' step into the ML CI/CD (e.g., GitLab, Jenkins).
• Retain gradient checkpoints to enable inverse reconstruction if required.

• Audit and traceability
• Generate an operation log specifying: affected model, identifier of the deleted data, unlearning method applied, and results of post-unlearning re-identification tests.

4.3 Code example (Python – exact unlearning)

import torch
from torch import nn, optim

def exact_unlearn(model: nn.Module,
                  data_point: tuple[torch.Tensor, torch.Tensor],
                  optimizer_state: dict):
    """
    Supprime l'influence d'un point d'entraînement en inversant le gradient.
    Nécessite que les gradients initiaux (avant entraînement) soient stockés.
    """
    x, y = data_point
    model.zero_grad()
    loss = nn.functional.cross_entropy(model(x), y)
    loss.backward()

    # Inverse des gradients sauvegardés lors de l'entraînement initial
    for p in model.parameters():
        if p.grad is not None:
            p.data += optimizer_state['lr'] * p.grad  # retour du pas d'optimisation

# Exemple d'utilisation
model = MyNet()
optimizer = optim.SGD(model.parameters(), lr=0.01)
# ... entraînement initial avec sauvegarde des gradients dans `grad_store` ...

exact_unlearn(model, (x_del, y_del), optimizer_state={'lr': 0.01})

Note: This implementation only works for constant step-size optimisers and requires the secure retention of original gradients.

5. Operational implications and costs

Return on Investment (ROI) analysis

• Scenario A – Full retraining for every deletion: legally ideal, but prohibitively expensive for LLM models (> 100M parameters). Negative ROI as soon as > 5% of users request erasure.
• Scenario B – DP + Approximate unlearning: reduction of re-identification risk to < 1% (according to studies by Abadi et al., 2016) with an average accuracy loss of 0.3% on standard datasets. Positive ROI once the annual erasure rate exceeds 2%.
• Scenario C – Hybrid (DP during training + exact unlearning for critical cases): combines the mathematical guarantee of DP with the precision of targeted retraining. Additional cost of ~15% compared to a standard ML pipeline, but prevents major sanctions.

6. Governance, audit and traceability

• Training data retention policy
• Define a maximum duration for each data category (customers, logs, images) in compliance with legal requirements.
• Automate the purging of raw datasets via cron scripts or data-lifecycle management solutions (e.g. Informatica, Collibra).

• Model Registry (inspired by the Model Card by Mitchell et al., 2019)
• Version, training date, source dataset(s), applied privacy methods, performance metrics, level of compliance with the right to erasure.

• Erasure request process
• User interface (DPO portal) → automated ticket → identification of the impacted model(s) → execution of the unlearning pipeline → generation of a signed audit report.

• Internal controls
• Periodic data inference tests (model inversion) to verify the absence of residuals after unlearning.
• Annual review by the data governance committee, including the DPO, CISO, and AI architects.

7. Case Study – Deletion of a customer dataset in a recommendation model

Context

• Company: European e-commerce platform (Turnover ≈ €200M).
• Model: Collaborative filtering system based on user/product embeddings, trained monthly on 10M interactions.
• Request: A customer has exercised their right to erasure (Article 17 GDPR) regarding all their historical interactions.

Applied approach

| 4 Technique selection | Influence > 0.05 ⇒ recourse to