Data, model and IP transfers in an AI business sale

An AI business sale transfers several distinct legal assets that don't automatically move together the way a storefront's furniture and inventory do. The training data, the trained model or weights, the source code, and any licences or third-party agreements the product depends on each need to be individually confirmed as owned and assignable. A purchase agreement that treats all of this as one bundled 'business' without checking each piece can leave a buyer with less than they thought they were getting. Treating each asset separately in the transfer documents, rather than relying on a single catch-all clause, is what actually protects the buyer once the deal has closed.

Data: licensing terms decide what’s actually transferable

Training data comes with whatever terms it was originally obtained under, and those terms don’t disappear just because the business changes hands. Data licensed from a third party may have restrictions on transfer, sublicensing or use by a different owner that need to be reviewed before assuming it moves with the sale. Data that includes personal information carries its own obligations under Canadian privacy law regarding how it can be used and by whom, and a change of ownership can itself be a moment that triggers new obligations around notice or consent depending on how the data was originally collected. None of this is a formality — it determines whether the buyer actually gets to keep using the data the business was built on. A buyer’s lawyer should request copies of the underlying data licences and consent language directly, rather than relying on the seller’s summary of what those terms say.

Model and weights: what’s actually being assigned

Where a company trained its own model, the trained weights are a specific, identifiable asset that needs to be explicitly assigned in the purchase agreement, not assumed to transfer as part of a general 'assets of the business' clause. Where the business instead fine-tuned a third party's foundation model, what's actually owned and transferable is typically the fine-tuning data and the resulting adjustment, not the underlying foundation model itself, which remains subject to that provider's own licence terms. Getting this distinction right in the transfer documents matters, because a buyer who thinks they're acquiring a model outright may in fact be acquiring a licence-dependent derivative of someone else's model. Where training involved data later found to be improperly licensed, the resulting model can carry that defect forward, which is one more reason data provenance and model ownership have to be reviewed together rather than separately.

Source code and technical IP

Code transfers through the same assignment mechanics as any software business sale, but AI products often have more moving pieces — data pipelines, training scripts, evaluation tooling — that need to be captured in the technical asset inventory, not just the customer-facing application. A thorough transfer confirms every repository, environment and piece of infrastructure-as-code that the product actually depends on to run, not just what’s visible in a demo.

The contractor IP gap, and how to close it

The single most common defect found in AI business transfers is a contractor or freelancer who built part of the model, the pipeline or the code without ever signing an agreement assigning IP rights to the company. Under Canadian law, absent an explicit assignment, an independent contractor generally retains ownership of what they create, which means the company — and by extension the buyer — may not actually hold clean title to that component. Closing this gap means identifying every contractor who touched a core technical asset and obtaining a retroactive assignment before the sale closes, while there’s still a business relationship and leverage to ask. Where a retroactive assignment can’t be obtained before closing, the purchase agreement should address the risk directly rather than leaving it unaddressed, whether through a price adjustment, an indemnity, or a condition to closing.

Open-source and third-party licence terms

Open-source components carry their own licence terms that survive a change of ownership, and some licences impose obligations — attribution, source disclosure, restrictions on commercial use — that a buyer needs to understand and continue complying with. A transfer agreement should include a representation from the seller about what open-source and third-party components are used and under what licences, so the buyer isn’t discovering a compliance obligation for the first time after closing.

What the purchase agreement should actually cover

• An explicit, itemized assignment of the model, weights, code and any registered IP, not a general reference to 'all business assets.'
• Representations and warranties about data provenance, licensing and privacy compliance, with meaningful consequences if they turn out to be false.
• Confirmation, attached as a schedule, that every contractor who built a core technical asset has signed an IP assignment.
• A schedule of open-source and third-party licences the product depends on, with the seller’s representation that use has been compliant.
• Clear treatment of what happens to any data or model components that turn out not to be transferable, rather than silence on the point.
• A survival period for the data and IP representations that’s long enough to cover the realistic time it would take a problem to surface.