What Happens to a Trained Model When Consent Is Withdrawn

A user who consented to their conversations being used for training withdraws that consent. Two obligations follow and they are usually discussed as one. The first is unambiguous and cheap. The second is the question nobody has answered.

What Article 7(3) actually says

Article 7(3) of Regulation (EU) 2016/679 gives the data subject the right to withdraw consent at any time, requires that it be as easy to withdraw as to give, and states expressly that withdrawal does not affect the lawfulness of processing based on consent before its withdrawal.

That last clause is the one to hold on to. A training run carried out while consent was valid was lawful, and it remains lawful. Withdrawal is not retroactive invalidation, and any analysis that treats a withdrawal as though it made the historic processing unlawful is starting from the wrong place. What withdrawal does is remove the basis for processing from the moment it takes effect — and the question is what processing continues after that moment.

The forward-looking duty, which is clear

From the moment consent is withdrawn, you may not carry out further processing of that person’s data on that basis. In concrete terms:

• Their data must be excluded from any subsequent training run, fine-tune or evaluation set built for the purpose consent covered.
• Any pipeline that periodically re-ingests fresh conversations must filter them out, including retrospective backfills.
• Continued storage of the corpus itself is processing under Article 4(2) and needs a basis. Once consent is gone, either another basis applies to retention or the data must go — which is the Article 17 question below.
• Withdrawal must be as easy as giving. A one-click toggle to opt in and an email to a legal address to opt out is a breach of 7(3) on its own terms, independently of anything to do with the model.

Almost every dispute in this area is about the model, and almost every enforceable failure is here. Excluding a person from future runs is engineering work that is entirely achievable, and a controller who has not built the exclusion list is exposed on the easy limb while arguing about the hard one.

Article 17 and what erasure reaches

Article 17(1)(b) gives a right to erasure where the data subject withdraws consent on which the processing was based and there is no other legal ground. So withdrawal usually arrives with an erasure obligation attached, and the scope of that obligation is the real question.

Uncontroversially, it reaches the stored corpus, the derived datasets, the caches and the logs — anything in a retrievable form. Article 17(3) carves out processing necessary for exercising freedom of expression and information, for compliance with a legal obligation, for reasons of public interest in the area of public health, for archiving, scientific or historical research or statistical purposes under Article 89(1) where erasure would render the objectives impossible or seriously impair them, and for the establishment, exercise or defence of legal claims. The research carve-out is narrower than it is usually invoked to be and it is not a general exemption for model development.

Article 17(2) adds that where the controller has made the data public it must take reasonable steps, taking account of available technology and cost, to inform other controllers processing it that erasure has been requested. A published model is an interesting case under that provision and nobody has tested it.

Does the model itself have to change?

This is where the honest answer is that the position is unresolved, and the reason it is unresolved is that it depends on a prior question: whether the trained parameters constitute personal data at all. That prior question is set out on whether you can get your data out of a trained model, and it has two serious answers.

If the weights are not personal data relating to the individual, Article 17 does not reach them, and the erasure obligation is satisfied by removing the source data and excluding the person from future training. This is broadly the direction of the Hamburg data protection authority’s July 2024 discussion paper, and it is a coherent reading.

If they are, or may be, then a model that can still reproduce the person’s data is arguably still processing it, and an erasure request reaches something the controller has no clean mechanism to deliver. The EDPB’s Opinion 28/2024 of 17 December 2024 does not decide this, but it declines to accept that models are anonymous by default and requires the controller to demonstrate that extraction from the model, and from its outputs, is insignificantly likely. That framing suggests a route: a model that genuinely meets the opinion’s anonymity threshold is one for which the erasure question does not arise, and demonstrating that becomes the controller’s task rather than the regulator’s.

What would settle it is the same thing that would settle the rectification question on AI-hallucinated personal data: a reasoned supervisory decision or a reference to the Court of Justice on the status of model parameters. Until then, a controller asserting that no obligation touches the model is taking a position, not reporting a rule.

Retraining, unlearning, and what they cost

Three technical responses exist and they differ enormously in cost and in how much they actually deliver.

• Full retraining without the data. Complete, and for a large model economically absurd as a response to one request. It only makes sense batched onto a scheduled retraining cycle, which is why some controllers commit to honouring exclusions “at the next training run” rather than immediately.
• Machine unlearning. An active research area aiming to remove a training example’s influence without full retraining. The methods are approximate and their guarantees are contested; there is no accepted way to certify that a specific example’s influence has been removed from a large model. Presenting unlearning to a regulator as equivalent to erasure would be overstating what the technique delivers.
• Output-layer suppression. Preventing the model from emitting the person’s data. Real mitigation, plainly not erasure, and it should be described as what it is.

What to build before you need it

The decisions that make withdrawal tractable are made long before a request arrives, and they are mostly about provenance.

• Record which subjects contributed to which training run. Without this you cannot answer any question about a specific person’s data, including whether it was used at all — and “we do not know” is a worse answer than either alternative.
• Maintain a durable exclusion list keyed to something that survives account deletion, and apply it at ingestion rather than at query time.
• Prefer retrieval over training for personal data. Data in a retrieval index can be deleted; data in weights cannot. This is the single architectural choice that most reduces exposure to this whole class of question.
• Choose the basis deliberately. Consent brings Article 7(3) and the 17(1)(b) erasure route; legitimate interests brings the Article 21 objection right instead. Neither escapes the problem, and picking one because it sounds more respectful without tracing its consequences is how controllers end up with the strictest version of both.
• Say in the notice what withdrawal does and does not do. A clear statement that withdrawal excludes future use but that an already-trained model will not be retrained is honest, testable, and far better than a promise of deletion you cannot keep. Related retention questions are on retention limits for training data.