When a data contract ends, what happens to the models already trained

The clause that is usually missing, and the five ways to handle it

A data agreement ends in the ordinary way: the term expires, one side terminates, or the parties simply stop working together. The data provisions are usually handled — deletion, return, stop of use, certificates. The model is not, because on the day the contract was drafted nobody had trained one yet.

The gap is not symmetrical. Data can be deleted. A trained model cannot be un-trained: information from the corpus is distributed across the weights, and no reliable procedure removes one contributor's material while leaving the rest of the capability intact. So the question at termination is not how to reverse the training. It is who may keep using what already exists.

• Perpetual training right. The licence to train survives termination, so existing models stay in service and you may keep training on the same data. Vendors resist it because it removes the commercial point of a term. A common middle ground is perpetual for models already trained, ended for new training.
• Frozen models. Rights survive only for the models that existed on the termination date, listed in a schedule. The list has to be attached at termination rather than at signature, and it has to say what counts as one model — a checkpoint, a version, or a model family.
• Run-off window. A fixed period after termination during which training may continue, usually long enough to finish work in progress and ship a release. It is the simplest of the five and often the fairest, because it maps to the real project cycle.
• Full stop. All use of the model ends and it is retired. This is rare in practice, because it means the buyer's product has to be withdrawn, and it is almost always a sign that the data was a one-off input rather than a foundation.
• Buy-out. The licence converts to perpetual on payment of a defined fee at termination, often expressed as a multiple of the remaining term's value. It gives the vendor certainty and the buyer an exit, and it is the option most deals actually land on.

What the vendor will ask for, and what to concede

Expect three requests. Deletion of the raw corpus with a certificate. A stop on using the surviving model to generate training material for other models — the distillation question, and a reasonable ask, because a surviving model can be used to manufacture a replacement dataset. And confirmation that the model card or transparency disclosure is updated if it named the dataset.

Concede the first two, and treat the third as a documentation task rather than a legal one. What you should not concede is a requirement to delete the model or to publish a retraction, unless the deal is small enough that retiring the model is genuinely survivable.

Define the surviving models precisely

Vague survival clauses produce the same argument every time: does a fine-tune of a surviving model survive, and does a model trained on the outputs of a surviving model count. Two definitions settle it. Name the surviving models in a schedule signed at termination, and state whether derivatives — fine-tunes, quantised builds, distilled students — fall inside the survival grant.

The practical answer is to include derivatives trained from the surviving model, while restricting use of the surviving model to generate training data for a materially different model family. That keeps your product alive and stops the survival right from becoming a permanent, unlimited licence through the back door.

The residual knowledge problem

No clause can make a team forget. Engineers who worked on a corpus retain an understanding of its composition, its accents and its failure cases. A clause demanding that the vendor not use residual knowledge is unenforceable, and it is usually a sign that the parties are negotiating about trust rather than about assets.

Handle it honestly instead. Acknowledge residual knowledge as permitted, then define the artefacts that are controlled: the files, the records, the models. That is the same boundary that makes the rest of the agreement work, and pretending otherwise produces a clause nobody can comply with.

The termination schedule to attach

Termination is the one moment when everyone is motivated to sign a short document, so have the shape of it ready in advance.

• The definition of a surviving model, and the list signed at termination.
• Whether derivatives are inside the survival grant.
• The run-off window, if there is one.
• Whether continued training is permitted, or only continued use.
• The buy-out option, with the fee expressed as a formula.
• Deletion and certification obligations for the corpus, with deadlines.
• A restriction on using the surviving model to generate training data for other model families.
• Survival of confidentiality, audit and records provisions beyond termination.
• A named contact on each side who signs the schedule.

Why this is worth drafting early

The cost of getting this wrong is asymmetric. A missing data-deletion clause is a compliance problem; a missing model-survival clause is a product problem, because it can require withdrawing something already in front of customers. The time to settle it is while the parties still like each other.

This is an operational outline rather than legal advice. Termination and survival provisions are read strictly by courts, and the wording should be checked by counsel against the specific licence grant.