Right to be forgotten and machine unlearning

WHAT THIS TESTS This checks whether you understand the gap between data deletion and model deletion: a trained model encodes information from its training data in its weights, so erasing the source rows does not by itself remove what the model learned from them.

A GOOD ANSWER COVERS Split the problem into two parts. First, deletion from data stores: remove the user's raw data from databases, backups, logs, feature stores, and any derived datasets, and stop using it in future pipelines. Second, removing the data's influence from the model itself, which is the hard part, machine unlearning. The gold standard is to retrain the model from scratch on the dataset minus that user, which is correct but often prohibitively expensive for large models. A practical alternative is sharded training such as SISA, where data is split into shards and the model is an ensemble, so a deletion request only requires retraining the one shard containing that user, dramatically cutting cost. Approximate unlearning methods attempt to mathematically adjust the weights to undo a sample's contribution without full retraining, trading exactness for speed. The challenges are real: full retraining is costly and slow, approximate methods lack guarantees, it is hard to prove the influence is truly gone, and you may need to defend against membership-inference attacks to demonstrate the user is no longer detectable in the model.

COMMON WRONG ANSWERS Assuming that deleting the user's rows from the database satisfies the right to be forgotten, ignoring the model weights entirely. Claiming you can simply delete a single training example from a model instantly with no cost. Forgetting verification, that you must be able to show the influence is removed.

LIKELY FOLLOW-UPS How does SISA reduce retraining cost in detail? How would you verify unlearning succeeded? What about data already in model embeddings or caches?

ONE CONCRETE EXAMPLE A user invokes deletion under privacy law. You purge their records from the warehouse, feature store, and backups. Because full retraining of the recommendation model costs days of compute, the system was built with SISA sharding, so you identify the single shard holding that user, retrain only that constituent model, and recombine the ensemble, satisfying the request in hours rather than retraining everything.