Under the GDPR, people in an AI training set keep their rights to information, access, rectification, erasure, restriction and objection, over the dataset and the model unless it is shown to be anonymous. Regulators accept a layered response: delete from the corpus, exclude from the next training run, test for memorization, and filter outputs where retraining is disproportionate.
Two points are still contested: whether a trained model holds personal data at all (the EDPB says test case by case; the Hamburg DPA said no in 2024), and whether blocking an output cures an inaccurate one, the question in noyb’s complaints against OpenAI. Lawful basis, processing records and vendor diligence are covered in GDPR compliance for machine learning models; this page is the request-handling reference.
Which rights apply to which copy of the data
A request about “my data in your AI” can land in four places: the raw corpus, the fine-tuning set (often reused chat transcripts, the default consumer assistants moved to in 2025), the model weights, and the outputs and logs. The legal text is the same for all four; the feasible response is not. The CNIL recommends telling requesters whether you read the request as aimed at the training data or the model, and how you are answering it.
How each right applies at each layer
| Right | Raw corpus | Fine-tune set | Model weights | Outputs and logs |
|---|---|---|---|---|
| Information (Art. 13, 14) | Art. 14, within one month; public notice if individual notice is disproportionate (Art. 14(5)(b)) | Art. 13 if collected from the person; notice before reuse for training (Art. 13(3)) | Disclose the regurgitation risk, safeguards and redress route | Explain how to report outputs containing personal data |
| Access (Art. 15) | Copy of the person’s records, annotations, metadata and available source, redacting other people’s data (Art. 15(4)) | Same, including labels and feedback | Memorization check results with example outputs, or “not impossible” if inconclusive | Logged prompts and outputs about the person |
| Rectification (Art. 16) | Correct records and annotations | Correct, then retrain the adapter | No direct edit: retrain, or filter until the next training run | The main battleground: false statements about real people |
| Erasure (Art. 17) | Delete, add to the exclusion list, notify recipients (Art. 19) | Delete, then retrain the adapter | Retrain where proportionate, robust filter until then; Art. 17(3) exceptions apply | Delete logs; filter regeneration |
| Restriction (Art. 18) | Quarantine, storage only, while accuracy or an objection is checked | Hold out of the next run | Block outputs about the person during the check | Suppress during the check |
| Objection (Art. 21) | Stop unless you show compelling legitimate grounds; offer an opt-out before collection | Honor before the next run | Bites on the next run and on outputs | Suppress outputs about the person |
| Identification (Art. 11, 12(2)) | If you demonstrate you cannot identify the person, Articles 15 to 20 fall away unless they supply extra information | Same | Ask for the prompts that surface the data | Same |
What regulators have accepted
| Right | Accepted or signaled response | Primary source |
|---|---|---|
| Information | A public, layered notice (a dataset or model card works if it stands out) naming sources, or at least the riskiest source categories, published before training | CNIL informing sheet; EDPB Guidelines 03/2026 (draft); GDPR Art. 13, 14 |
| Access | Training-record copies plus the memorization investigation; withheld data, sources and recipients are one ground of noyb’s April 2024 complaint | CNIL rights sheet; GDPR Art. 15 |
| Rectification | Retraining, which can be batched, or robust filters; whether prompt-level blocking cures inaccurate outputs is before regulators in both noyb complaints | CNIL rights sheet; GDPR Art. 16 |
| Erasure | The same toolkit; refusal only in narrow cases such as the CNIL’s public-figure example; unlearning only once it can guarantee deletion | CNIL rights sheet; EDPB Guidelines 03/2026 (draft); GDPR Art. 17 |
| Restriction | No AI-specific regulator guidance yet; apply the text and log the hold | GDPR Art. 18 |
| Objection | A route open before any training begins; if you call the opt-out unconditional, honor it automatically. Meta kept its form open for over a year | Irish DPC AI Insights Report; DPC statement on Meta; GDPR Art. 21 |
| Identification | Say in the notice that you cannot identify people, and what extra information would let you act | CNIL informing and rights sheets; GDPR Art. 11, 12(2) |
Article 17(3) exceptions are narrow (expression and information, legal obligations and public-interest tasks, public health, archiving, research or statistics that erasure would seriously impair, legal claims), and “retraining is expensive” is not one of them; the CNIL treats cost and complexity as proportionality factors. Its examples mark the range: a public figure asking to be erased from a model that correctly reports public figures’ roles, where retraining is very costly, may in principle be refused; a non-anonymous insurance model that surfaces one claimant’s settlement obliges the controller to propose a solution. Where outputs drive decisions about a person, Article 22 adds rights of its own.
The threshold question: is the model personal data?
Only if it fails the EDPB’s anonymity test, and the controller must be able to demonstrate that it passes. Opinion 28/2024, adopted on 17 December 2024 at the Irish DPC’s request, treats a model as anonymous only where it is “very unlikely” both to identify, directly or indirectly, the people whose data trained it and to let anyone extract that data through queries. Supervisory authorities judge that case by case, weighing tests for membership and attribute inference, exfiltration, regurgitation, model inversion and reconstruction. Legitimate interest as a training basis (the EDPB’s three-step test) and the processing record each stage needs are covered in GDPR compliance for machine learning models; how a claimed anonymization is judged, in pseudonymization versus anonymization under GDPR. The CNIL asks developers to prioritize anonymizing training data; federated learning is the architectural alternative that avoids pooling it at all.
What the CNIL’s February 2025 recommendations say
The CNIL’s recommendations of 7 February 2025, on informing data subjects and on facilitating their rights, are where the output-filtering practice comes from, and they attach more conditions to it than the shorthand does.
Notice
- Individual notice applies where you hold contact details and reaching people is not disproportionate. Otherwise a public notice under Article 14(5)(b) suffices, provided you document the disproportion and take appropriate measures such as a DPIA even where Article 35 does not require one.
- Name sources precisely when they are few. When they are many, categories or a few main sources generally suffice; for scraping, the categories of sites, at least the riskiest. Domain names, URLs and collection dates are good practice, not a requirement.
- As good practice, leave a reasonable period between notice and training. Model and dataset cards can carry the notice if it stands out; a specialist technical paper cannot.
Rights
- You need not keep identifiers just to answer requests. People can supply extra information, such as an image or a pseudonym, and an LLM developer can ask for the prompts the requester believes reveal memorization. If you still hold the training data, find the person there first, then check the model.
- Retraining is the primary remedy while you hold the data, and it can run periodically to clear several requests at once. Ship the updated model and, as good practice, contractually require downstream users to run current versions.
- Filters are acceptable when retraining is disproportionate, or “pending the next training” when it cannot happen within the response deadline, if they are “sufficiently effective and robust (i.e. they cannot be circumvented)”. The CNIL prefers general rules that stop the system generating personal data, such as named-entity recognition, over a blacklist of people who exercised their rights; a blacklist must be secured and assessed for the membership inference risk it adds.
The CNIL’s June 2025 legitimate-interest recommendations and web-scraping focus sheet list the collection-side measures, mandatory and recommended: define collection criteria in advance, exclude unnecessary categories and delete irrelevant data at once, skip sites that object through robots.txt or CAPTCHA, keep a default exclusion list of sensitive sites such as health forums, offer a discretionary right to object before collection, and pseudonymize or anonymize promptly. A scraper built that way already has the exclusion list an erasure request needs.
Decision procedure: route each request by where the data sits
Record the reasoning at every branch in the DPIA (the DPIA template for LLM deployment gives a structure).
| Where the data sits | Action | Record |
|---|---|---|
| Raw corpus and derived datasets | Delete; add URLs, identifiers and document hashes to the exclusion list the next crawl and dataset build read; notify recipients of copies; if you published the dataset, take reasonable steps to tell controllers processing it (Art. 17(2)) | Hits, deletion date, exclusion entry |
| Fine-tuning or adapter data | Delete, retrain the adapter and ship it; an adapter costs far less to retrain than a base model, which weakens any disproportion argument | Adapter versions before and after |
| Retrieval index, prompt logs, stored outputs | Delete like any database record; re-index | Deletion date |
| Base weights you trained | Assess extractability (worked example below). Extractable: robust output filter now, excluded from the next retrain. Not extractable: say so, with the “not impossible” caveat where it applies | Probe log, filter test, retrain date, and the ground for not retraining now: an Art. 17(3) exception, Art. 12(5) for a manifestly unfounded or excessive request, or cost-and-complexity proportionality |
| Third-party base model | The provider is the controller for its training data: name it and how to reach it, forward the request if your contract provides for that, and handle your own layers | Provider, date forwarded, what you handled |
“Not our model” is an incomplete answer on the third-party branch: the prompts, logs, retrieval index and filter are yours, and any part you decline needs a reply within one month with reasons and the complaint route (Art. 12(4)). The CNIL draws the same line for knowledge bases: requests about one a third party added go to that third party. Provider diligence questions are in GDPR compliance for machine learning models, and forwarding to a provider outside the EEA is a transfer (cross-border LLM data transfers).
Worked example: erasure against a model trained on scraped web data
A company pre-trains its own model on a web crawl, adds an adapter fine-tuned on support transcripts, and serves it with a retrieval index. A private individual writes in: asked about them by name, the assistant returns their street and employer. They want it all erased.
- Day 0: log and scope. Log receipt; Article 12(3) gives one month. Acknowledge, say you are treating the request as covering the training data and the model, and ask for name variants, usernames, URLs where the data appeared and the prompts that surfaced it. Ask for identity proof only if you have reasonable doubts (Art. 12(6)). A request-tracking platform keeps the clock.
- Days 1 to 5: search. Search the retained crawl and every derived artifact (deduplicated shards, tokenized caches, the fine-tune set, the retrieval index) for the identifiers and URLs, and record document IDs, source URLs and crawl dates. If the crawl was not kept, record that; Article 11 then shapes the answer.
- Days 5 to 10: delete and exclude. Delete matching documents and chunks, purge logs, add URLs, identifiers and document hashes to the exclusion list, retrain the adapter if the transcripts contained the person, and notify recipients of dataset copies.
- Days 5 to 15: test the weights. Deletion does not touch a trained model, and Carlini et al. extracted names, phone numbers and email addresses from GPT-2, including sequences that appeared in a single training document. Run this yourself and keep the log:
- Pin the model version (record the weights hash) and run every probe with production filters off, then on.
- Build three probe sets: prefix probes (the text just before the person’s data in each deleted document, for the model to continue), direct questions (“Where does [name] live?”, “Who employs [name]?”), and the requester’s own prompts.
- Use greedy decoding plus repeated sampling at a non-zero temperature, for example 20 samples at 1.0, and record the settings so the next model gets the same test.
- Run the direct questions for several fictitious names of the same form as controls.
- Read the results. A verbatim continuation of a corpus prefix is memorized, extractable text; memorization grows with model capacity, duplication and prompt length (Carlini et al., 2022). Attributes that appear for the real name but not the controls point to memorization; attributes invented for the controls too suggest generation from correlations, as the CNIL warns, and a false statement is then a rectification issue. Membership inference testing adds a statistical check if you can train shadow models.
- Days 15 to 25: choose the model-level remedy. If a retrain that excludes the documents lands inside the deadline, use it and tell downstream users to update. Otherwise filter pending the next training with a general rule (no home addresses or employers for private individuals) rather than a list of complainants, and rerun the probes with the filter on, plus paraphrases and other languages, to show it cannot be circumvented. Record the results, the retrain date and why you are not retraining now.
- Within one month: respond or extend. If testing or the retrain date is unsettled, notify an extension of up to two further months, with reasons, before the first month ends. Anything you decline needs reasons plus the complaint and court routes (Art. 12(4)).
The weights paragraph should state what erasure did and did not do, without overclaiming (“your data has been deleted from our AI”):
[Controller] found [N] documents containing your name, street and employer in its training corpus. They have been deleted from the corpus and every dataset derived from it, and their URLs and your identifiers are on the exclusion list for all future collection and training. The model in service, [model version], was trained before your request, and deleting source documents does not change a trained model. Queried with [N] prompts, including yours, it reproduced your street name in [n] outputs; examples are attached. Since [date], a filter has stopped the service generating home addresses and employer details for private individuals, and the next model, due [date], is being trained without your data. Until it replaces the current one, the filter, not the model, is what prevents disclosure. If your data appears in any output, send the prompt and it will be handled as a new request. You can also complain to [supervisory authority].
Models built on unlawfully processed data: the three EDPB scenarios
Opinion 28/2024 does not say unlawful training automatically taints deployment. It sets out three scenarios:
| Scenario | What the EDPB says | What it means for a deployer |
|---|---|---|
| 1. Personal data retained in the model; the same controller deploys | Whether development and deployment are separate purposes, and how far the missing legal basis affects deployment, is decided case by case | No clean break: a developer deploying its own model should expect both phases to be examined together |
| 2. Personal data retained; another controller deploys | Authorities consider whether the deployer made an appropriate assessment, as part of its accountability, that the model was not developed unlawfully, looking at the data’s source and any infringement finding by an authority or court, scaled to deployment risk | Exposure turns on documented diligence about the provider’s sources and any findings against it |
| 3. Model anonymized before the same or another controller deploys | If operating the model involves no personal data, the GDPR does not apply and the unlawful training should not affect its operation; personal data processed in deployment is under the GDPR in its own right | Only as strong as the anonymity evidence: get the provider’s extraction and inference test results, or you are back in Scenario 2 |
Findings move, so a Scenario 2 assessment needs rechecking. The Garante’s December 2024 decision that OpenAI trained ChatGPT without first identifying an appropriate legal basis was the kind of finding Scenario 2 names, until the Tribunale di Roma annulled it on competence grounds in March 2026 without examining the merits.
Enforcement and case record
| Date | Body | What happened | Why it matters |
|---|---|---|---|
| 29 Apr 2024 | noyb to Austria’s DSB | ChatGPT kept giving a public figure a wrong birth date; OpenAI said it could block data on prompts such as their name but not correct it, and did not adequately answer their access request | First test of rectification and access against a model provider; still pending |
| Jul 2024 | Hamburg DPA | Discussion paper: no personal data is stored in an LLM, so storing one is not processing; rights attach to the AI system’s inputs and outputs; training violations do not make later use unlawful | The opposing view to EDPB 28/2024 |
| 20 Dec 2024 | Garante | €15 million fine on OpenAI (decision 755 of 2 Nov 2024): training without an identified legal basis, transparency failures, no age verification, an unreported March 2023 breach, plus a six-month campaign on objecting, rectification and erasure | Annulled by the Tribunale di Roma on 18 Mar 2026: the Irish DPC had become lead authority on 15 Feb 2024; the merits were not examined |
| 20 Mar 2025 | noyb to Norway’s Datatilsynet | ChatGPT falsely described a Norwegian man as having murdered two of his children; noyb seeks deletion of the output, fine-tuning to remove inaccurate results, and a fine | Irish DPC lead since 30 Jun 2025; tests whether blocking outputs suffices while the model may still hold the data |
| 14 Apr to 27 May 2025 | Meta; Irish DPC | Meta notified EU users and opened an objection form before training on adults’ public content began on 27 May; the DPC cited a longer notice period, in-app forms open over a year, de-identification and output filters | The objection-before-training model regulators have accepted |
| 23 May 2025 | OLG Köln, 15 UKl 2/25 | Refused Verbraucherzentrale NRW’s injunction; legitimate interest accepted, citing EDPB 28/2024; about six weeks to object held adequate | Reasonable expectation of AI training ran only from Meta’s 10 Jun 2024 announcement, yet the safeguards carried the balancing |
| 8 Jul 2026 | EDPB | Guidelines 03/2026 on web scraping for generative AI, open for comment until 30 Oct 2026 | Public notice mandatory when relying on Art. 14(5)(b); data “cannot be easily deleted” from a trained model; unlearning only once it can guarantee deletion |
| 25 Sep 2026 | Irish DPC | AI Insights Report on its 2021 to 2025 supervision | Objection must be available “before any AI training begins”; “if your objection is honoured” misleads where the opt-out is unconditional |
The objection row may change by statute. The Commission’s Digital Omnibus proposal of 19 November 2025 would add an Article 88c confirming that developing and operating AI can rest on legitimate interest, with an unconditional right to object. EDPB-EDPS Joint Opinion 2/2026 replied that legitimate interest is already available and the right belongs in Article 21, flagged well in advance because retained data can be hard to remove. The Council compromise 12535/26 of 3 September 2026, published by noyb, reportedly drops that right from the operative text. Nothing has been adopted.
FAQ
Can I get my personal data removed from an AI model?
Yes: if the model is not anonymous, erasure and objection apply. Expect the developer to delete your data from its training set, keep it out of the next training run and block outputs about you, rather than retrain at once; regulators accept that where retraining is disproportionate. If the answer falls short, complain to your supervisory authority.
Is machine unlearning required for GDPR erasure?
No. Neither the CNIL nor the EDPB requires it. The CNIL accepts retraining, which can be batched periodically, or robust output filters when retraining is disproportionate. The EDPB’s draft web-scraping guidelines say unlearning could replace filters or retraining once an algorithm can guarantee that specific data has actually been deleted from the model.
Does the right to object still apply after my data was used for training?
Yes. Article 21 applies at any time to processing based on legitimate interest, and the controller must stop unless it shows compelling legitimate grounds. After training, an objection mostly bites on the next training run and on outputs, which is why the Irish DPC wants the objection route open before any training begins.
