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, in the UK and the EU

The right sits in Article 17 of the GDPR, and the UK GDPR keeps the same article. 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.¹² The UK added one more ground in England and Wales from 31 March 2026, for data processed because of a malicious allegation the controller has investigated and dropped.¹

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.¹²

The clock is one month. Under the EU GDPR, the controller must act on the request without undue delay and within one month of receiving it, extendable by two further months for complex or numerous requests, telling the person why within the first month.³ The UK has written the same period into a new Article 12A since 5 February 2026: one month from the relevant time, extendable by two months by notice.⁴

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. Ashdown Mail is an email marketing SaaS in Brighton, at ashdownmail.example. On 3 March a recipient of one of its customers' newsletters writes asking for every trace of them to be erased. Ashdown 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 Ashdown 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 Leeds, at kirkgatelocal.example, ranks local businesses using visitors' behaviour. The ranking model keeps the patterns after a visitor leaves.
• A used car marketplace in Manchester on Solidus, at mossleymotors.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 UK regulator

In the UK the regulator is now the Information Commission (still the ICO on its website), since the office of the Information Commissioner was abolished by the Data (Use and Access) Act 2025.¹¹ Its guidance on AI and individual rights is the clearest of all on models. Personal data may be in the training data, in predictions, or "contained in the model itself". Where a model holds personal data, a request for erasure may not be possible without retraining the model, without the erased data, or deleting the model altogether, and a well organised model management and deployment pipeline, while not a legal requirement, makes such requests easier and less costly. It also notes that erasing one person from the training data is unlikely to affect your ability to train the system.¹² The guidance says it is under review after the 2025 Act.¹²

That is the honest position. No regulator I have found requires machine unlearning as a technique. The ICO says that when a model holds someone's personal data, honouring their erasure may mean retraining 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

Mossley 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

Kirkgate Local groups visitor sessions by district, category and week before training its ranking model. One week, the groups for "Headingley, 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, Kirkgate 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, which is exactly what the ICO's guidance points at:¹²

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. The ICO is explicit that backups are included, and that you must be clear with the person about what happens to the copy in backup until it is overwritten.²⁰

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 ICO says honouring erasure for data inside a model may mean retraining or deleting it. 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. UK GDPR, Article 17, right to erasure, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/17

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. Data (Use and Access) Act 2025, section 76, inserting UK GDPR Article 12A, meaning of applicable time period, in force from 5 February 2026, legislation.gov.uk, https://www.legislation.gov.uk/ukpga/2025/18/section/76

5. UK GDPR, Article 28(3)(e), processor assistance with data subject rights, legislation.gov.uk, https://www.legislation.gov.uk/eur/2016/679/article/28

6. 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

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

8. 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

9. 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

10. 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

11. Data (Use and Access) Act 2025, section 118, abolition of the office of Information Commissioner, legislation.gov.uk, https://www.legislation.gov.uk/ukpga/2025/18/section/118

12. Information Commissioner's Office, Guidance on AI and data protection: How do we ensure individual rights in our AI systems?, accessed November 2026, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/how-do-we-ensure-individual-rights-in-our-ai-systems/

13. 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

14. 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

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

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

17. 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

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

19. 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

20. Information Commissioner's Office, Right to erasure, accessed November 2026, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/

21. 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

22. 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