Handling a Rights Request Against a Fine-Tuned Model

“Under Article 17 GDPR I request the erasure of all my personal data, including any data used to train or fine-tune your AI models.” That sentence, or a template close to it, is now a routine arrival. This is what can be done about it and what cannot.

The request, as it actually arrives

The clock starts on receipt. Article 12(3) requires a response without undue delay and in any event within one month, extendable by two further months where necessary given complexity and number of requests, provided you inform the person of the extension and the reasons within the first month. There is no exemption for “this one is technically hard”, and a fine-tune is exactly the case where the extension is worth taking early rather than discovering you need it on day 28.

Read what was actually asked. A single template often bundles Article 15 access, Article 16 rectification, Article 17 erasure, Article 18 restriction, Article 20 portability and Article 21 objection. They have different tests and different answers, and a response that treats the bundle as one request tends to answer the easiest and leave the hardest unaddressed, which is the version that becomes a complaint.

Four places the data is, and one where it is not

A fine-tuning programme leaves personal data in at least four distinct artefacts, and conflating them is what produces both the impossible promise and the unjustified refusal.

• The source system. The CRM, ticket store, chat history or document repository the training examples were extracted from. This is ordinary structured data. Access and erasure work here normally, and this is where most of the substance of the answer lives.
• The curated training file. The JSONL, the parquet shard, the labelled set, together with every copy: object storage, a colleague’s laptop, the vendor’s upload endpoint, the backup. This is also ordinary data, and it is the artefact most often forgotten because it is nobody’s system of record.
• Inference logs and evaluation records. Prompts, completions, traces, human-review annotations, feedback labels. These frequently contain the person’s data in a form nobody catalogued, and they are within scope of Article 15.
• The adapter or the checkpoint. The LoRA weights or the full fine-tuned checkpoint. Here the data is not stored as records at all. It is distributed across parameters as a change in the model’s conditional behaviour.

The fifth place is the one people assume exists: an index inside the model mapping a person to their contribution. There is no such index. Nothing in the checkpoint can be queried for “what did this person contribute”, and nothing can be edited to remove it while leaving the rest intact. That is a property of gradient-based training, not a limitation of your tooling or a choice by your vendor.

Answering the access request

Article 15 gives the right to confirmation, to a copy of the personal data undergoing processing, and to the information in Article 15(1)(a) to (h) — purposes, categories, recipients, retention period, the existence of the other rights, the source where not collected from the person, and the automated decision-making information discussed in the Recital 71 page. For a fine-tune, that means producing the source records, the extracted training examples that relate to the person, the logs, and a description of what the fine-tune was for.

Recital 63 says the right to a copy should not adversely affect the rights of others, and Article 15(4) says the same in operative form. A training file frequently contains a conversation with two people in it. The answer is redaction of the third party’s data, not refusal of the whole record — a blanket refusal on third-party grounds is one of the more common findings against controllers.

On the weights themselves, the honest answer to “what personal data about me is in the model” is that the model does not hold retrievable records and you cannot enumerate a contribution. Say that plainly, and say what you did instead: the training examples that concerned them, disclosed in full. Do not assert that the model contains no personal data as a matter of law. The EDPB’s Opinion 28/2024 of 17 December 2024 declined to treat models as anonymous by default, so that assertion is a legal conclusion in a live area, not a statement of fact about your system.

Answering the erasure request

Erasure under Article 17 is doable and verifiable for the first three artefacts. Delete the source records subject to any overriding retention obligation under Article 17(3), delete the training file and every copy including the vendor-side upload, and purge or truncate the logs. Article 19 then requires you to communicate the erasure to each recipient to whom the data was disclosed, unless impossible or disproportionate — which for a fine-tune means telling the model vendor, in writing, and asking them to confirm deletion of the uploaded file and of any derived artefact they hold.

For the checkpoint there are three real options and one that is not yet real. The first is retraining from the corrected corpus, which is complete and, for a small adapter, often costs less than the argument about whether it is proportionate. The second is retiring the checkpoint entirely — the strongest answer available and sometimes the cheapest, if the fine-tune is superseded anyway. The third is mitigation short of removal: output filters, refusal rules and evaluation to show the model does not emit the person’s data. The fourth, machine unlearning, is an active research area rather than a deployable guarantee, and describing an unlearning procedure to a data subject as though it removed their data is a claim you would have to defend.

Article 17(1) is not unconditional in any case: the right applies on the listed grounds and Article 17(3) carves out legal obligations, public-interest archiving, research subject to Article 89(1), and the establishment or defence of legal claims. If you refuse in part, cite the specific subparagraph, explain it, and tell the person about the right to complain to a supervisory authority and to a judicial remedy as Article 12(4) requires. A refusal that does not name its ground reads as an evasion whether or not it is one.

Saying it without overclaiming

The failure mode is a response that sounds accommodating and is false — “we have removed your data from our models” when what happened was that a file was deleted. If the checkpoint was not retrained or retired, that sentence is untrue, and it is untrue in writing to a person who may forward it to a regulator. The opposite failure is a flat “this is technically impossible”, which skips the fact that retraining and retirement both exist and were simply judged too expensive. Proportionality is a real argument, but it has to be made as one.

Wording that holds up tends to have four parts: what was deleted, named by system; what was disclosed instead; what the model is and why selective removal from its parameters is not available; and what you did about the residual risk, whether that is retraining on a schedule, retiring the checkpoint at a stated date, or output-level controls with the evaluation behind them. Then the complaint route. A person who receives that will often accept it. A person who receives a reassurance they later discover was hollow will not.

Two operational notes worth building before the next request arrives. Keep a register that maps each fine-tuned checkpoint to the exact training file and the exact source query that produced it; without it you cannot answer the access request at all, and it is separately required as part of the record of processing activities. And decide the retraining cadence in advance as policy, so that the answer to “when will the model no longer reflect this data” is a date rather than a negotiation.