GDPR and AI: when the right to be forgotten reaches the model

The problem in one paragraph

A customer signs up to a SaaS product, uses it for six months, then writes: "Delete all my data. Article 17." Deleting the account, the campaigns, the reports and every row with their ID is the easy part. The awkward question is the model. If their data helped train it, its influence sits in the model's parameters, shaping predictions for everyone else, and deleting the rows does not undo that. This is the machine unlearning problem, and it is where the right to erasure meets the way machine learning works.

It kept me up at night while building GrowCentric.ai, and I work on it across several products, all built on Ruby on Rails and all subject to data protection law. This article covers what the law actually says, what the regulators have and have not said about models, what the research can and cannot do, and the architecture that keeps you out of the problem in the first place.

What the right to erasure says

The right sits in Article 17 of the GDPR, which applies directly in Ireland. A person can have their personal data erased without undue delay where one of a set of grounds applies: the data is no longer needed for its purpose, they withdraw the consent it rested on, they object and there is no overriding legitimate ground (or they object to direct marketing), the data was processed unlawfully, the law requires erasure, or it was collected from a child for an online service.¹²

It is not absolute. Erasure does not apply where processing is needed for freedom of expression, a legal obligation, public health, archiving or research, or legal claims.¹² Irish law adds restrictions of its own in the Data Protection Act 2018: section 60 for important objectives of public interest, and section 43 to balance erasure with freedom of expression and information.¹

The clock is one month. Under Article 12(3) of the GDPR, the controller must act on the request without undue delay and within one month of receiving it, extendable by two further months where necessary, taking into account the complexity and number of requests, and must tell the person about the extension, with the reasons, within the first month.³

Nowhere does Article 17 mention models. It was written about personal data, wherever it lives. Whether a trained model contains personal data is the question that decides everything else.

Worked example: the request, and the clock

An invented one. Merchants Mail is an email marketing SaaS in Galway, at merchantsmail.example. On 3 March a recipient of one of its customers' newsletters writes asking for every trace of them to be erased. Merchants Mail processes recipient data for its customers, so it is a processor here: it passes the request to the customer, the controller, and helps it respond, as its processing contract has to require.⁴ The customer's deadline is 3 April. If the request touches backups, an analytics warehouse and a model, the customer can extend by two months, but only by telling the recipient before 3 April, with reasons.

The interesting part is the last item on that list: the model.

Why deleting the row is no longer the whole answer

When a model trains, each example nudges thousands or millions of parameters by tiny amounts through gradient descent. The finished model is the sum of all those nudges. There is no column in it labelled "User X". The influence is spread across the whole parameter space and tangled up with every other example.

The analogy I use is soup. Ingredients go in one at a time and simmer for hours. Then someone asks you to take out the salt from step three. You can't. The only salt free soup is a new soup made without salt.

Two things make this a legal question, not just an engineering one. Models can memorise. Carlini and colleagues extracted hundreds of verbatim training sequences from GPT 2, including names, phone numbers and email addresses, some of which appeared in only one document of the training data.⁵ And membership inference attacks can tell, from a model's answers alone, whether a given record was in its training set.⁶ A model that leaks like that holds personal data in any sense that matters.

Here is how it looks across the kinds of product I work on, as four invented businesses:

• A marketing optimisation SaaS learns from campaign results. If one client's data shows that a certain audience converts best on Thursday evenings, that pattern can shape recommendations for another client. Deleting the first client's account leaves the pattern in the model.
• An email platform like Merchants Mail learns which send times and subject lines get opened. Each recipient's opens and clicks fed that learning. Delete one recipient and the insight remains.
• A regional listings site in Cork, at mardykelocal.example, ranks local businesses using visitors' behaviour. The ranking model keeps the patterns after a visitor leaves.
• A used car marketplace in Limerick on Solidus, at castletroymotors.example, recommends cars from browsing. If it learned from one visitor that people who view one family hatchback also view a rival's, deleting that visitor does not unlearn the association.

In every case the database deletion is easy and the model is not.

What the regulators have actually said

The first version of this article claimed regulators had made unlearning a requirement. They have not, and I have rewritten this section to say only what the published documents say.

The EDPB opinion on AI models

In Opinion 28/2024, adopted on 17 December 2024, the European Data Protection Board considered personal data in AI models. Its central finding: AI models trained on personal data "cannot, in all cases, be considered anonymous", and anonymity has to be assessed case by case. For a model to count as anonymous, both the likelihood of extracting personal data about the people in the training data and the likelihood of getting such data out through queries must be insignificant, taking into account all the means reasonably likely to be used.⁷

The consequence is logical rather than spelled out: a model that is not anonymous contains personal data, and the GDPR, rights included, applies to it.

The opinion also lists what a supervisory authority may do where a model was developed with unlawfully processed data: a fine, a temporary limit on processing, "erasing part of the dataset that was processed unlawfully or, where this is not possible, depending on the facts at hand, having regard to the proportionality of the measure, ordering the erasure of the whole dataset used to develop the AI model and/or the AI model itself".⁷ That is the worst case, and it is about unlawful development, not about an ordinary erasure request.

Two more points matter for builders. Among measures that can help a controller in the balancing test for legitimate interest, the opinion lists letting people exercise erasure even where the Article 17 grounds do not apply, and post training techniques that attempt to remove or suppress personal data.⁷ Those are offered as mitigations, not duties. And a controller that deploys someone else's model is expected to have made an appropriate assessment that the model was not developed by unlawfully processing personal data.⁷ If you build on a third party model, that assessment is yours.

The first version also said the EDPB had "rejected" an earlier position of the Hamburg authority. The opinion does not say that, so I have cut it.

The EDPB's year of enforcement on erasure

In 2025 the right to erasure was the topic of the EDPB's Coordinated Enforcement Framework. 32 data protection authorities took part: 9 opened or continued formal investigations and 23 ran fact finding exercises, with 764 controllers responding. The report was adopted on 10 February 2026.⁸

It found seven recurring problems, including weak internal procedures, too little information for individuals, unclear retention periods and deletion from backups.⁸ It does not single out AI models. The finding that matters most for this article is about anonymisation: many controllers use anonymisation instead of deletion, some only apply basic pseudonymisation or partial masking, which would not meet the GDPR's requirements for deletion, and the EDPB is working on guidelines on anonymisation.⁹ Hold that thought for the architecture below.

The regulator in Ireland

In Ireland the regulator is the Data Protection Commission (DPC), and it has a particular stake in this question: it was the DPC, as the Irish supervisory authority, that asked the EDPB for Opinion 28/2024, on 4 September 2024.⁷ Its own guidance on AI and large language models puts the erasure question to builders in one line. If someone asks you for access to their personal data, or to delete the personal data you hold on them within the AI system, "can you do it?" It warns that memorisation can cause passages of personal training data to be regurgitated by the product, and it says the ability to uphold the rights of access, rectification and erasure "must be considered at the earliest stage possible in development".¹⁰

That is the honest position. No regulator I have found requires machine unlearning as a technique. The DPC expects you to be able to honour erasure for an AI system, and when a model holds someone's personal data and nothing can take it out cleanly, what is left is retraining without their data or deleting the model.

The enforcement case everyone cites

In December 2024 Italy's data protection authority, the Garante, fined OpenAI €15 million, finding among other things that it had processed users' personal data to train ChatGPT without first identifying an adequate legal basis.¹¹ The first version of this article stopped there. Since then, a judgment of the Court of Rome published on 18 March 2026 upheld OpenAI's appeal against that decision, and the Garante has removed the decision from its website.¹¹ The case shows the questions are live. It does not show settled law.

What machine unlearning research can do

Researchers have worked on this since at least 2015, and a 2022 survey summed up the state of the field: recent work "has not been able to completely solve the problem".¹² The main families:

Full retraining. Train again from scratch without the erased data. It is exact, and it is the yardstick everything else is measured against. For a large model it is slow and expensive. For a small domain model it may be perfectly affordable.

SISA training. Bourtoule and colleagues split the training data into shards, train a separate model on each, and combine their outputs. When a deletion arrives, only the shard that held the record is retrained.¹³ The name stands for sharded, isolated, sliced and aggregated. It cuts the cost of forgetting, at the price of building your whole training pipeline around it.

Influence based removal. Koh and Liang showed how influence functions can trace a prediction back to the training points most responsible for it.¹⁴ Guo and colleagues turned that idea into "certified removal", a formal guarantee that a model with data removed cannot be distinguished from one that never saw it, for linear classifiers.¹⁵ Strong for simple models, much harder for deep networks.

Relabelling and fine tuning. Graves and colleagues proposed "amnesiac" unlearning: record the updates each batch made and undo them, or relabel the data to be forgotten and fine tune, then check against membership inference and model inversion attacks.¹⁶ Fast, but approximate.

The test for all of them is the same attack that motivates them: can an adversary still tell the record was in the training set?⁶

Worked example: what sharding saves

Castletroy Motors retrains its recommendation model nightly. A full training run takes eight hours (the example's assumption). With the data split into equal shards, a deletion only retrains one shard, so the cost is roughly the full cost divided by the number of shards:

$$C_{\text{shard}} \approx \frac{C_{\text{full}}}{S}$$

Here $C_{\text{shard}}$ is the time to retrain after one deletion, $C_{\text{full}}$ the time for a full training run, and $S$ the number of equal shards. It is a simple ratio, explained in Foundations: ratios and rates.

With 16 shards:

$$\frac{8}{16} = 0.5$$

Here $8$ is the full run in hours, $16$ the number of shards and $0.5$ the hours per deletion. Thirty deletions a month cost 15 hours of training instead of 240. The catch is that 16 models each trained on a sixteenth of the data may predict worse than one model trained on all of it, and Bourtoule and colleagues measured that trade off for their datasets.¹³ You pay for fast forgetting with some accuracy.

The practical answer: keep personal data out of training

Here is where I stop describing the problem and describe what I do about it.

The best answer to machine unlearning is never needing it. If personal data never reaches a model in identifiable form, there is nothing to unlearn. That does not mean you cannot learn from your users. It means an architecture that separates personal data from training data, through aggregation, anonymisation and careful governance.

Read it from the top. The raw data stays where deletion is easy. The cohort check is the gate. The provenance record at the bottom is what lets you answer a request with evidence instead of a shrug.

Layer 1: data provenance

First, know exactly what data went into which model. If you cannot answer "was this person's data used to train that model?", you cannot answer an erasure request properly.

class DataProvenanceTracker
  def record_training_usage(model_version:, data_sources:)
    data_sources.each do |source|
      TrainingDataRecord.create!(
        model_name: model_version.model_name,
        model_version: model_version.version_string,
        data_source_type: source[:type],
        data_source_id: source[:id],
        contains_personal_data: source[:personal_data],
        anonymisation_method: source[:anonymisation_method],
        aggregation_level: source[:aggregation_level],
        included_at: Time.current,
        data_hash: compute_data_hash(source)
      )
    end
  end

  def find_models_using_data_from(user:)
    TrainingDataRecord.where(
      data_source_type: "user_derived",
      data_source_id: user.id,
      contains_personal_data: true
    ).includes(:model_version)
  end

  def erasure_impact_assessment(user:)
    affected = find_models_using_data_from(user: user)
    {
      user_id: user.id,
      affected_model_count: affected.size,
      models: affected.map do |record|
        {
          model: record.model_name,
          version: record.model_version,
          anonymisation_method: record.anonymisation_method,
          aggregation_level: record.aggregation_level,
          retraining_required: record.contains_personal_data &&
                               record.aggregation_level == "individual"
        }
      end,
      assessed_at: Time.current
    }
  end
end

This is the first thing I implemented across GrowCentric.ai and the client products I work on. Every training run records what data was used, at what level of aggregation, and whether personal data was involved.

Layer 2: the anonymisation pipeline

The key decision: personal data is aggregated or anonymised before it reaches a training pipeline. Raw data stays in the application database, where deletion is straightforward. Only derived, aggregated features flow to training.

class TrainingDataAnonymiser
  def prepare_training_features(user_data, purpose:)
    case purpose
    when :campaign_optimisation then aggregate_campaigns(user_data)
    when :email_engagement      then aggregate_engagement(user_data)
    when :recommendation_engine then generalise_browsing(user_data)
    end
  end

  private

  def aggregate_campaigns(data)
    # No identifiers, cohort level only, minimum 50 per cohort
    data.group_by { |d| cohort_key(d) }
        .select { |_key, members| members.size >= 50 }
        .transform_values { |members| aggregate_metrics(members) }
  end

  def aggregate_engagement(data)
    # Segment and time bucket only, minimum 100 recipients per group
    data.group_by { |d| [d[:segment], time_bucket(d[:timestamp])] }
        .select { |_key, members| members.size >= 100 }
        .transform_values do |members|
          {
            open_rate: members.count { |m| m[:opened] }.to_f / members.size,
            click_rate: members.count { |m| m[:clicked] }.to_f / members.size,
            segment_size: members.size
          }
        end
  end

  def generalise_browsing(data)
    # Generalise attributes, keep only groups of at least k = 10
    data.map { |d| strip_identity(d) }
        .group_by { |d| generalise_attributes(d) }
        .select { |_key, group| group.size >= 10 }
  end

  def cohort_key(datum)
    [datum[:region_code], datum[:industry_vertical],
     time_bucket(datum[:timestamp]), device_category(datum[:device])].join(":")
  end
end

The design principle is minimum cohort sizes. For GrowCentric.ai campaign data, no training cohort smaller than 50. For email engagement on the client products, no segment smaller than 100 recipients. For browsing data, groups of at least ten. The last is k anonymity, Latanya Sweeney's model: a release protects each person if their record cannot be told apart from at least $k-1$ others in it.¹⁷

Now the honest caveat the first version left out. Grouping is not automatically anonymisation. Sweeney's own paper shows how k anonymous releases can still be re identified when the accompanying policies are not respected.¹⁷ And the EDPB found controllers treating basic pseudonymisation or masking as deletion when it does not meet the GDPR's standard.⁹ Anonymous, in law, means the data no longer relates to an identifiable person.² So the cohort gate is necessary, not sufficient: drop rare combinations, coarsen timestamps and locations, never train on identifiers, and test what an attacker could infer.

Worked example: the cohort gate

Mardyke Local groups visitor sessions by district, category and week before training its ranking model. One week, the groups for "Douglas, wedding photographers" hold these session counts: 41, 12 and 7.

With $k = 10$, the gate keeps groups of 10 or more:

• 41: kept
• 12: kept
• 7: dropped

The group of seven is dropped not because seven is a magic number but because a small, specific group is where one person's behaviour stands out. When one of those seven visitors later asks for erasure, Mardyke Local deletes their raw sessions, and the provenance record shows that their week fell in a dropped group, or in a kept group of at least ten, never in a model as an individual.

Layer 3: the erasure handler

When a request comes in, the system handles it end to end:

class GDPRErasureHandler
  def process_erasure_request(user:, requested_at: Time.current)
    request = ErasureRequest.create!(user: user, requested_at: requested_at,
                                     status: "processing")

    ActiveRecord::Base.transaction do
      delete_personal_data(user)

      impact = DataProvenanceTracker.new.erasure_impact_assessment(user: user)
      impact[:models].each do |model_info|
        if model_info[:retraining_required]
          schedule_model_remediation(model_info, user)
        else
          log_no_action_required(model_info, reason: "training_data_aggregated")
        end
      end

      propagate_to_processors(user)

      request.update!(
        status: "completed",
        completed_at: Time.current,
        impact_assessment: impact,
        model_remediation_required: impact[:models].any? { |m| m[:retraining_required] },
        documentation: generate_erasure_documentation(user, impact)
      )
    end

    # The deadline is one month from receipt, extendable only by notice
    ErasureConfirmationMailer.send_confirmation(user, request).deliver_later
    request
  end

  private

  def delete_personal_data(user)
    [UserProfileService, CampaignDataService, EmailEngagementService,
     BrowsingHistoryService, SupportTicketService,
     AuditLogService] # anonymise the audit trail, where the law requires keeping it
      .each { |service| service.erase_for(user) }
  end

  def schedule_model_remediation(model_info, user)
    ModelRetrainingJob.perform_later(model_name: model_info[:model],
                                     exclude_user_id: user.id,
                                     reason: "erasure_request", priority: "high")
  end

  def propagate_to_processors(user)
    DataProcessorRegistry.all.each do |processor|
      processor.request_erasure(user_identifier: user.anonymised_id)
    end
  end
end

If the pipeline in layer 2 works, the retraining branch should almost never run. It is there for the day it does.

Layer 4: design for retraining

Even with good aggregation, keep retraining feasible. It is what the DPC's call to consider erasure at the earliest stage of development comes down to in practice:¹⁰

class RetrainableModelPipeline
  def train(model_config:, training_data:, excluded_users: [])
    dataset = prepare_versioned_dataset(training_data: training_data,
                                        excluded_users: excluded_users)
    model = ModelTrainer.train(config: model_config, data: dataset[:features])

    ModelVersion.create!(
      model_name: model_config[:name],
      version: next_version(model_config[:name]),
      trained_at: Time.current,
      training_data_hash: dataset[:hash],
      excluded_users: excluded_users,
      data_provenance: dataset[:provenance]
    )
    model
  end

  # SISA inspired: keep the data in shards so a partial retrain is possible
  def prepare_versioned_dataset(training_data:, excluded_users: [])
    shards = training_data.each_slice(shard_size).map do |shard|
      { data: shard.reject { |d| excluded_users.include?(d[:source_user_id]) },
        hash: Digest::SHA256.hexdigest(shard.to_json) }
    end
    { features: shards.flat_map { |s| s[:data] },
      hash: Digest::SHA256.hexdigest(shards.map { |s| s[:hash] }.join),
      provenance: shards.map { |s| s[:hash] } }
  end
end

The erasure playbook, step by step

When someone exercises the right to erasure:

Step 1: acknowledge quickly. Not a legal requirement, but a reply within a few days tells the person a human has seen it.

Step 2: map the data. Use the provenance records to find every place their personal data lives: application databases, analytics, backups, processors and training sets. Backups are included. The EDPB's enforcement report found many controllers had no procedure for erasure in backups, and where deleting from a backup is not advisable, it expects you to keep track of the request and honour it on any restored system, and to be able to demonstrate the erasure.¹⁸

Step 3: assess the models. If the architecture works, the assessment shows their data reached training only in aggregated form. Write that down.

Step 4: delete. Remove the personal data everywhere, within one month of receipt, or extend by notice for a complex case.³

Step 5: retrain if needed. If personal data reached a model in identifiable form, schedule a retrain without it, and record the timeline.

Step 6: tell your processors. Pass the request to every processor that holds the data.

Step 7: document everything. Weak procedures and poor information were among the EDPB's main findings.⁸ Your records are your evidence.

Step 8: confirm to the person. Say what was erased, what sits in backups and for how long, and whether any retraining is still running.

How this fits the wider picture

The EU AI Act asks providers of high risk systems for technical documentation that includes their training data, from 2 December 2027 for most of them,¹⁹ and its Digital Omnibus now lets providers process special category data strictly for bias detection, deleted once the bias is corrected.²⁰ I cover the dates in the EU AI Act for SaaS builders and the DACH angle in AI compliance for the DACH market. Together with the GDPR, it means knowing what trained your models and being able to show it.

The first version of this article also described a proposal to allow legitimate interest as a legal basis for AI training under the GDPR. That was a separate proposal, I could not confirm its status, and I have cut it. Whatever the legal basis, the right to erasure stays.

The Cyber Resilience Act adds security duties for the pipelines themselves, and the NIS2 Directive adds incident reporting if they are breached.

The bottom line for developers

The right to be forgotten was never only about rows. It is about personal data wherever it lives, and a model can be one of those places. The EDPB says a model trained on personal data is not automatically anonymous. The DPC asks whether you can delete the personal data an AI system holds, and wants that settled at the earliest stage of development. Neither tells you to master machine unlearning.

So architect the system properly from the start. Keep personal data out of training through aggregation with minimum cohort sizes, and do not mistake masking for anonymisation. Record what went into every model. Keep retraining feasible. Handle requests end to end, models included, and write it all down.

The patterns are the same in every Rails application I build: provenance, aggregation, minimum cohorts, sharded training where it pays, a full erasure handler and an audit trail. Build them once and apply them everywhere, because sooner or later someone will ask what happened to their data in your model.

Footnotes

1. Data Protection Commission, The right to erasure (Articles 17 and 19 of the GDPR), accessed November 2026, https://www.dataprotection.ie/en/individuals/know-your-rights/right-erasure-articles-17-19-gdpr

2. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 17 and Recital 26, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

3. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 12(3), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

4. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 28(3)(e), processor assistance with data subject rights, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

5. Nicholas Carlini, Florian Tramer, Eric Wallace, Matthew Jagielski and others, Extracting Training Data from Large Language Models, arXiv, 2020, https://arxiv.org/abs/2012.07805

6. Reza Shokri, Marco Stronati, Congzheng Song and Vitaly Shmatikov, Membership Inference Attacks against Machine Learning Models, arXiv, 2016, https://arxiv.org/abs/1610.05820

7. European Data Protection Board, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, adopted 17 December 2024, https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf

8. European Data Protection Board, EDPB identifies challenges hindering the full implementation of the right to erasure, 18 February 2026, https://www.edpb.europa.eu/news/edpb-identifies-challenges-hindering-the-full-implementation-of-the-right-to-erasure_en

9. European Data Protection Board, 2025 Coordinated Enforcement Action: Implementation of the right to erasure by controllers, adopted 10 February 2026, section 4.2.7, https://www.edpb.europa.eu/system/files/2026-02/edpb_cef-report_2025_right-to-erasure_en.pdf

10. Data Protection Commission, AI, Large Language Models and Data Protection, 18 July 2024, https://www.dataprotection.ie/en/dpc-guidance/blogs/AI-LLMs-and-Data-Protection

11. Garante per la protezione dei dati personali, ChatGPT, il Garante privacy chiude l'istruttoria, 20 December 2024, with the note on the Court of Rome judgment No. 4153/2026 published 18 March 2026, https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10085432

12. Thanh Tam Nguyen, Thanh Trung Huynh, Zhao Ren, Phi Le Nguyen and others, A Survey of Machine Unlearning, arXiv, 2022, https://arxiv.org/abs/2209.02299

13. Lucas Bourtoule, Varun Chandrasekaran, Christopher A. Choquette-Choo, Hengrui Jia and others, Machine Unlearning, arXiv, 2019, https://arxiv.org/abs/1912.03817

14. Pang Wei Koh and Percy Liang, Understanding Black-box Predictions via Influence Functions, arXiv, 2017, https://arxiv.org/abs/1703.04730

15. Chuan Guo, Tom Goldstein, Awni Hannun and Laurens van der Maaten, Certified Data Removal from Machine Learning Models, arXiv, 2019, https://arxiv.org/abs/1911.03030

16. Laura Graves, Vineel Nagisetty and Vijay Ganesh, Amnesiac Machine Learning, arXiv, 2020, https://arxiv.org/abs/2010.10981

17. Latanya Sweeney, k-anonymity: a model for protecting privacy, International Journal on Uncertainty, Fuzziness and Knowledge-based Systems, 10(5), 2002, https://dataprivacylab.org/dataprivacy/projects/kanonymity/kanonymity.pdf

18. European Data Protection Board, 2025 Coordinated Enforcement Action: Implementation of the right to erasure by controllers, adopted 10 February 2026, section 4.2.6, https://www.edpb.europa.eu/system/files/2026-02/edpb_cef-report_2025_right-to-erasure_en.pdf

19. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 11 and Annex IV, point 2(d), Official Journal of the European Union, 12 July 2024, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689

20. Regulation (EU) 2026/1744 (Digital Omnibus on AI), Article 1, points 6 and 40, amending Regulation (EU) 2024/1689, Official Journal of the European Union, 24 July 2026, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744