A recommendation model was trained on browsing histories collected under consent. Several thousand users withdraw that consent. What happens to the model that has already learned from their data, and what makes your answer defensible?

What actually changes at the moment of withdrawal

Withdrawal stops further processing on that basis. Three things follow immediately and cheaply, and they are the ones that matter most to the person:

1. The user's own stored profile, embedding or feature row is deleted, so nothing personalised is computed from them again.
2. They are added to the exclusion list applied at feature-build time, so the next training corpus is built without them.
3. Serving stops using any per-user artefact derived from their history, falling back to non-personalised ranking.

The contested part is the trained weights. Whether a set of model parameters constitutes personal data is unsettled and jurisdiction-dependent. The architecture's job is to make that question cheap to answer rather than to win the argument.

Where it amplifies

The corpus is rarely one file. A withdrawn user's rows are also in the feature store, the offline evaluation sets, the replay buffers, the experiment snapshots that reproduce last quarter's results, and a notebook on someone's laptop. Each derived copy needs the same exclusion, and copies that nobody governs are how a defensible position becomes an indefensible one.

The failure mode is quiet. Nothing errors when an exclusion list is applied to the training job and not to the evaluation set, so the breach surfaces months later as a regulator's question you cannot answer in the 30 days you have to answer it.

What stops it

• Provenance on every training row: subject id and lawful basis carried into the corpus, so "was this person in the training set, and under what basis" is a query that returns in minutes.
• A stated retrain cadence. If the model is fully retrained weekly, then the maximum residency of a withdrawn user's contribution is one cycle, and that interval is your published answer. It is a design parameter you choose, not an accident.
• Sharded training when the cadence is not affordable. The SISA construction published in 2021 trains over k independent shards and ensembles them, so removing one subject means retraining one shard rather than the whole model: with k = 20 that is roughly 5% of the cost, paid for with some accuracy and a more complex serving path. Approximate unlearning methods exist in the literature and are not yet something to promise a regulator, because none of them lets you prove the influence is gone rather than merely reduced.

What would have to be true for retraining to be unnecessary

That no individual measurably influences the output: the model was trained on aggregates above a population threshold, or with a formal privacy guarantee bounding any single record's effect. If you can point to that guarantee, there is no per-subject contribution to remove, and you say so with the parameter. Without one, "the model has generalised, so it is fine" is an assertion, not an argument.

When this is over-engineering

A ranker trained on item-level statistics — how often a product is bought after being viewed, with no user identifier in the corpus — has no subject to withdraw. Check whether the model consumes per-person rows at all before designing an unlearning pipeline. Many recommenders that are described as personalised are personalised at serving time from a profile you can simply delete.