When a model goes into production, the environment that produced it does not clean itself up. The training data stays where it was, the checkpoints accumulate, the intermediate processed copies remain, and the whole set quietly becomes the largest and least examined part of the storage estate. Nobody is confident enough about what might be needed later to delete any of it.
That hesitation is reasonable. Some of it genuinely must be kept, sometimes for years. But treating all of it as equally important is what turns an AI programme into a capacity problem, and the decision is easier than it looks once the material is separated by what question it would be used to answer.
During a training campaign, everything feels current. The distinction between what is in use and what is finished only becomes visible once a model is deployed and the team moves on to the next one. At that point, the previous campaign's data is no longer read by anything, but it is also not obviously disposable, so it stays.
The cost compounds because each campaign leaves a similar residue. Three or four cycles in, the environment holds several generations of datasets, several sets of checkpoints and several processed variants of substantially the same source material. Capacity reviews start showing growth that nobody can attribute to current work, which is a familiar shape for anyone who has managed capacity on a large object store.
The resolution is a retention policy set per artifact type rather than per project. What a finished run leaves behind is predictable, so the rules can be written once and applied automatically.
Separating the residue into categories makes the decision tractable, because the categories have very different sizes and very different justifications for being kept.
| Artifact | Relative size | Why it might be needed | Typical retention |
|---|---|---|---|
| Source training data | Largest | Retraining, audit, reprocessing with better methods | Life of the model plus an audit margin |
| Processed or packed copies | Large | Fast exact reproduction of a run | Short, regenerate from source instead |
| Intermediate checkpoints | Large in aggregate | Resuming an interrupted run | Days, expire automatically |
| Final model weights | Small | Serving, rollback, comparison against successors | Long, often indefinite |
| Dataset manifest and run record | Very small | Explaining what the model learned from | Indefinite, the cheapest thing to keep |
The pattern in that table is the useful part. The two items worth keeping longest, the final weights and the run record, are also the two smallest. The items that dominate capacity, processed copies and intermediate checkpoints, are largely regenerable or disposable. Most of the capacity problem is caused by keeping the wrong things rather than by keeping too much overall.
Some retention is not a choice. Organizations in regulated sectors may need to explain how an automated decision was reached, which means retaining enough to describe the data the model learned from. Contractual terms with data providers frequently specify both a retention limit and a deletion obligation. Sector rules on record keeping may apply to the inputs of a decision system in the same way they apply to other business records.
The practical step is to establish which obligations apply before setting any policy, and to note that obligations can point in both directions. A rule that requires records to be kept for seven years and a licence that requires source data to be deleted after two are not contradictory if the retained record is the manifest and the deleted item is the payload. Separating those two is what makes both possible.
Where the data includes personal information, retention limits are usually tighter than the instinct to keep everything, and the ability to show what was kept and where it was held becomes part of the obligation rather than an administrative extra.
An individual's request to have their data erased is straightforward when the data sits as individual objects with a known identifier. It becomes difficult when the same samples have been copied into packed training files, derived embeddings and multiple dataset versions, because each copy has to be found and handled.
This is a strong argument for keeping the authoritative dataset as individually addressable objects, keeping a catalog that maps identifiers to locations, and treating packed and processed forms as disposable derivatives that can be regenerated. Deleting from the source and regenerating the derivative is usually simpler and more defensible than editing packed files in place.
It is also a reason to keep a deletion log. A retained dataset version that can no longer be fully rebuilt because samples were legitimately erased is not a failure, but the difference has to be documented or it looks like data loss when someone reviews it later.
Much of what teams are reluctant to delete does not need to be deleted, only moved. Source data from a completed campaign is read rarely but might be needed for retraining or for an audit. That profile suits capacity storage with a longer access time far better than it suits the performance tier it was trained from.
A workable arrangement moves completed campaign data to a capacity tier at the point the model ships, keeps the manifests and final weights on fast storage where they are easy to reach, and expires checkpoints and processed copies on a schedule. The capacity tier holds the bulk at a much lower cost per terabyte, and nothing that might be needed has been thrown away.
Lifecycle rules should do this automatically. Retention decided by a person each quarter is retention that will not happen, and the whole point of classifying artifacts by type is that the rules can then run without anyone revisiting them.
Scality RING is commonly used as the capacity tier in this arrangement, holding completed training data, milestone checkpoints and final model states on a single namespace while performance storage serves active work. Lifecycle rules can move data between prefixes and expire derived artifacts on a schedule, which keeps intermediate checkpoints and processed copies from accumulating without anyone having to intervene.
For material that has to be defensible, object lock holds selected objects immutable for a defined period, which suits the manifests and final weights behind a deployed model. Retaining those on the same system as the source data, with different retention applied per prefix, means the record and the data it describes stay together rather than drifting apart across systems, which is the condition that makes an audit request straightforward to answer.
A retention policy is working when the team can answer three questions about any model currently in production: what data it was trained on, whether that data is still retrievable, and what has been deleted from it since. If all three have answers, the policy is doing its job regardless of how much has been removed.
Test it the way an auditor would. Pick a deployed model, ask for the dataset version and the run record, and try to retrieve a sample of the data. The exercise usually reveals that the expensive material was kept while the cheap material that explains it was not, which is the inversion this kind of policy exists to prevent.