Retention rules for training data: three layers, one deletion request

Three layers, and only one of them is about files

Retention in a training data project is usually discussed as though it were a single setting on a single system. It is three layers, and they move at different speeds:

• The legal layer: rules that cap how long personal data may be kept, and require a stated purpose for keeping it at all.
• The contractual layer: what the buyer and the supplier promised each other about deletion, verification, and what is left behind.
• The model layer: what remains in a trained system after the source files are gone, which is not a copy and is not nothing.

The failure the three layers produce

Treat the layers as one and you get the classic outcome: the supplier deletes the audio on schedule and confirms it in writing, and the buyer still cannot answer a participant who asks to be removed from the model. The paperwork is clean, the files are gone, and the obligation is unmet.

The reverse failure is quieter. A project keeps raw audio "just in case" for years after delivery, long past the purpose it was collected for, and the retention decision is never actually made by anyone — it is made by default when nobody schedules a deletion. Retention obligations are usually breached by inaction rather than by a decision.

The fix is to make the retention decision explicit per artifact, in writing, with a named owner. An unwritten retention rule is not a rule.

The legal layer underneath all of this has one dominant principle: storage limitation, meaning personal data may be kept no longer than necessary for the purpose it was collected for. That is a rule about justification rather than a fixed number of months, which is why "we keep everything indefinitely" is the position most likely to be questioned first.

Three specifics are worth knowing:

• A stated purpose supports a retention period. Change the purpose and the analysis resets rather than extending the old period — which is what happens when a corpus collected for transcription is later used for synthesis.
• Regimes aimed at children's data set retention limits expressly, which makes a destruction plan a condition of collection rather than a later decision.
• Erasure rights turn retention into a live obligation rather than an internal preference, because a request has to be answerable with a described process and a record.

The request that arrives after training

The hardest case is a withdrawal or erasure request for data that has already been trained on. Deleting the files does not remove what the model absorbed, and saying otherwise is the kind of statement that converts a complaint into a dispute.

The honest options, none of them free:

• Retrain without the data. The only method with a clear outcome, and the only one that costs a full training run.
• Approximate removal techniques from the research literature, which aim to reduce the influence of specific data and come with no general guarantee that the influence is gone.
• Suppression at the product level — blocking the behaviour the data would produce — which addresses the symptom rather than the weights.

Designing a schedule that can be kept

Retention schedules fail when they are written for an ideal workflow rather than the real one. The rules that hold up:

• Set a different clock for raw audio, transcripts, consent records and derived features, because they have different sensitivity and different uses.
• Name trigger events rather than calendar dates: delivery acceptance, model retirement, contract termination, consent withdrawal.
• Keep consent records longer than the data they justify, since they are the evidence that the data was lawfully held in the first place.
• Give one person ownership of the schedule, with a monthly reconciliation against actual storage rather than an annual review.
• Log every deletion with a date and a scope, so the file shows a history rather than a claim.

The retention clauses to get in writing

The contract items that decide whether deletion is real or nominal:

• The retention period per artifact, with its trigger, rather than one number for the whole project.
• Verification: what the supplier will confirm in writing, and how deletion is checked across backups, annotation caches and email attachments.
• The fate of derived artifacts — alignments, embeddings, features, intermediate exports — which are copies in substance even when they are not copies in form.
• What happens to the model, stated as what the supplier will and will not do rather than as a promise of erasure.
• Who bears the cost if a retraining becomes necessary because a participant withdraws.

What to do with this

Write down the three layers separately for the next project: what the law requires, what the contract says, and what the model keeps. Most retention disputes come from a conversation that mixed the three and produced a promise that none of them could support.

The other useful discipline is to answer the hard question in advance: if a participant asked today to be removed from a model trained on their recording, what would the answer be, and who would give it? A project that has an answer is in a different position from one that discovers the question during a complaint.

This is an operational summary rather than legal advice. Retention obligations depend on the data, the jurisdiction and the purpose, and the analysis for a specific corpus belongs with counsel.