What happens to a trained model when a data license is terminated?

Why is a trained model hard to unwind?#

A trained model is hard to unwind because your records' influence is spread across its weights alongside every other source it learned from. There is no file to delete. Removing one supplier's contribution reliably means retraining the model without it, which developers resist for large models because of the cost and the disruption to products built on them.

Research on machine unlearning aims to remove specific training data from a model without full retraining, but results remain hard to verify. A supplier cannot easily confirm that its records' effect is gone, so contract terms carry the weight.

Model deletion does exist as a remedy. US regulators have, in some enforcement settlements over improperly obtained data, required companies to delete models built with it. Those cases involved unlawful collection rather than an ordinary license ending, which is why suppliers need their own contract terms.

What do termination clauses usually cover?#

Termination clauses usually cover the licensed data in every form the buyer holds it: delivered files, working copies, backups on a stated schedule, and derived datasets such as cleaned versions, labels, embeddings and evaluation sets. They typically require written certification of deletion.

What they usually leave alone is a model already trained. Developer drafts commonly state that models trained during the term may be retained and used after termination, sometimes without time limit. Read that sentence first, because it decides more than the rest of the clause.

Delete data, stop use or retrain: the remedy options#

The remedy options range from deleting data only to destroying models, and each carries a different burden for the buyer and a different level of protection for the supplier. Buyers weigh that burden when they negotiate the rest of the deal, so ask for the remedy that matches the actual risk.

Does the reason for termination change the outcome?#

The reason for termination often changes the outcome, and a well-drafted license sets different consequences for expiry, termination for convenience and termination for breach. Treating them identically usually favors the buyer, because the mildest remedy then becomes the only one.

• 1Expiry at the end of the term: deletion of data and derivatives, with existing models retained, is a typical compromise.
• 2Termination for the buyer's breach, such as use outside the permitted scope: stronger remedies, including stop-use of affected models, are easier to justify.
• 3Termination because the supplier must withdraw records, for example after finding a customer restriction: deletion of the affected records and a no-further-training duty, usually without penalty to either side.
• 4Change of control or insolvency of the buyer: limits on assignment, so the records and post-termination rights do not pass to an unknown party without consent.

What to negotiate before signing#

The terms to negotiate before signing are the ones that decide the post-termination picture, because a buyer has little reason to add them once the records are already inside a model.

Start with definitions. Derived data should name embeddings, vector indexes, labels, synthetic records and evaluation sets, so the deletion clause reaches them. Covered models should identify which models may be trained during the term, so the retention right does not stretch to models trained afterward from copies that were never deleted.

Then set the mechanics: a deletion deadline that lets backups age out under normal rotation, a certificate signed by an officer, a no-further-training duty that takes effect on termination, and survival of confidentiality, output restrictions and naming limits. Add a cooperation duty in case a regulator or court later requires deletion of data or models.

Illustrative: an engineering firm withdraws project records#

Illustrative: a fictional engineering and architecture firm licensed RFIs, submittals and internal review comments from Procore and Bluebeam to a developer building a document assistant. The developer fine-tuned a model on the records and built a retrieval index over them.

During the term, the firm discovers that one client's contract restricts reuse of project records, so it must withdraw that client's material. Because the license separated retrieval from training, the developer rebuilds the index without the withdrawn records and deletes the old one. The fine-tuned model stays in service, the developer stops any further training on that client's records and certifies deletion of all copies.

The firm's remaining exposure is limited to what had already shaped the model's weights, and its counsel holds a certificate and a clear record of each step taken.

Which obligations should survive termination?#

The obligations that should survive termination are the ones that protect your records after the buyer stops receiving them, since a retained model keeps working long after the license ends. A survival clause that lists them by name is easier to enforce than a general statement that terms survive where their nature requires.

Keep the list short and specific. Buyers accept a precise survival list more readily than an open-ended one, and a precise list leaves less room for argument later.

How SourceX handles post-termination terms#

SourceX sets out post-termination terms as part of permitted use during the Approval step of the SourceX five-step transaction, so the supplier approves what happens to data, derivatives and models before Delivery. The SourceX Evidence Packet records those terms with provenance, licensing rights, the privacy record and release authorization.

Because Preparation removes personal and confidential details before delivery, the part of an archive that ends up inside weights is limited to material the supplier approved for that purpose.