Engineering, production, governance, cost, communication · insight-0279

Plan how deletion requests propagate to snapshots, features and retraining

Situation
A customer's data is deleted from the operational database, but it remains in last quarter's training snapshot and feature tables.
Action
Inventory every copy of personal data in the ML lifecycle, propagate deletions to snapshots and feature stores, define with legal how trained models are handled (for example removal at the next scheduled retrain), and log completion.
Reason
ML pipelines multiply copies of data, so deletion needs lineage to reach all of them.
Boundary
Personal data under deletion rights, contractual deletion clauses, data-sharing agreements.

Symptom or risk

Deletion stops at the source, and copies persist in places nobody inventoried, including models retrained later on old snapshots.

Fully anonymised aggregates may fall outside scope; confirm with legal.

Rebuilding snapshots breaks exact reproducibility of old models; record this as an accepted limitation.

Assuming a model never memorises individual records; large models can.

Training data can be extracted from large language models, showing that models can memorise individual records.
Extracting Training Data from Large Language Models