Who Owns the AI Model Your Dev Partner Builds on Your Data

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK-based seed or Series A SaaS founder who has just been told by an investor that their IP assignment clause does not explicitly cover model weights or training data derivatives, and cannot close the round until it does

If your MSA assigns 'code and deliverables' but doesn't explicitly name model weights, embeddings, fine-tuning checkpoints, and derivative training datasets as assigned IP, your vendor has a credible statutory claim to the most valuable asset in your company. Under section 9(3) of the UK Copyright, Designs and Patents Act 1988, the author of a computer-generated work is 'the person by whom the arrangements necessary for the creation of the work are undertaken' — the engineer who ran the training job, not the client who supplied the data. Fixing this before the round closes is a two-page contract amendment, not a rebuild. This post walks through the exact clause family to add, the wording that protects you, the wording that quietly doesn't, and the questions to put to your dev partner. It is not legal advice — your solicitor needs to review the final document — but it will let you have an informed conversation with both sides.

Why your existing IP clause almost certainly fails

The standard software development MSA was drafted for a world where 'the deliverable' meant source code, documentation, and perhaps a database schema. The CDPA's computer-generated works provision was written in 1988 for algorithmic generators and spreadsheet macros, long before trained neural network weights existed as a concept. Courts have not yet resolved how section 9(3) applies to a 70GB file of floating-point numbers produced by running your data through someone else's training pipeline on their GPUs.

That 36-year gap matters right now because investor expectations have moved. UK VC due diligence now explicitly demands a verified chain of title across all training datasets, fine-tuning artifacts, and proprietary model weights, and flags generic software IP assignment provisions as legally insufficient. The new norm at seed and Series A is mandatory assignment of all model weights and training data pipelines, not boilerplate that only names 'code'.

The commercial consequence is blunt. Broad IP ambiguities in vendor or customer contracts reduce acquisition valuations by 15–40% by creating competing ownership claims on the model's core assets, and 83% of B2B AI startups sign enterprise contracts whose IP clauses fail acquisition due diligence. Getty Images v. Stability AI, currently proceeding through the English High Court, already includes a defence that no model training occurred in the UK — a preview of the jurisdictional arguments vendors will deploy when the stakes are a founder's cap table rather than a copyright claim.

What you actually built, in the vendor's eyes

When a dev partner trains or fine-tunes a model on your data, five distinct artifacts come out of that process, and your current contract probably only clearly covers two of them:

• Source code — the training scripts, inference wrappers, API endpoints. Usually covered.
• Configuration and infrastructure-as-code — the Terraform, Dockerfiles, Kubernetes manifests. Usually covered.
• Model weights — the trained parameters themselves, often the single most valuable file on the system. Rarely named.
• Embeddings and vector indexes — numerical representations of your proprietary content, reusable to bootstrap a competitor's product. Almost never named.
• Derivative training datasets — cleaned, labelled, augmented versions of your raw data. Legally distinct from the raw data you supplied. Almost never named.

A clause that says 'all code and deliverables created under this agreement are assigned to Client' does not unambiguously capture the last three. A diligence lawyer reading that clause will tell your investor they cannot confirm chain of title.

The IP assignment clause family: what to add

You need one amended assignment clause and three supporting definitions. The structure below is what most UK diligence lawyers are now asking for. Your solicitor should adapt the exact wording to your MSA's existing drafting conventions.

1. Expand the definition of 'Deliverables'

What it's for: to ensure every artifact produced during the engagement is caught by the assignment, regardless of whether it looks like 'code' in the traditional sense.

Wording that protects you: Deliverables includes, without limitation, all source code, object code, scripts, configuration files, trained and fine-tuned model weights and checkpoints, LoRA adapters, embeddings, vector databases and indexes, prompt templates, system prompts, evaluation datasets, synthetic datasets, labelled and cleaned training datasets derived from Client Data, model cards, and any intermediate artifacts produced during training, fine-tuning, or inference.

Wording that quietly doesn't: 'all software, code, and documentation created for the Client'. The word 'software' is contested when applied to a weights file, and 'documentation' excludes datasets.

Question to put to the vendor: 'List every file and artifact that will exist on your infrastructure at the end of the engagement. For each, confirm in writing whether it falls under the Deliverables definition.'

2. A dedicated AI assets assignment clause

What it's for: to address section 9(3) of the CDPA head-on, so there is no residual statutory claim by the vendor as 'author' of computer-generated work.

Wording that protects you: The Supplier hereby assigns to the Client, with full title guarantee and by way of present assignment of future rights, all right, title, and interest (including all copyright, database rights, and any rights arising under section 9(3) of the Copyright, Designs and Patents Act 1988) in and to all AI Assets created, trained, fine-tuned, or derived in the performance of this Agreement. For the avoidance of doubt, the Client is the person by whom the arrangements necessary for the creation of any computer-generated work under this Agreement are undertaken.

Wording that quietly doesn't: 'The Supplier assigns all intellectual property rights in the Deliverables.' Database rights and the section 9(3) authorship point both need naming explicitly, because a court may not read them into a general assignment.

Question to put to the vendor: 'Do you accept that for the purposes of section 9(3), the Client is treated as the person making the arrangements? If not, which parts of the training pipeline do you consider your arrangement?'

3. Carve-outs: what the vendor keeps, and what you must police

What it's for: vendors legitimately reuse their own pre-existing tooling, internal libraries, and general know-how. A clause that tries to assign everything they touch is unsignable and will be negotiated out. The job is to make the carve-out precise rather than open-ended.

Wording that protects you: Supplier retains ownership of Background IP, defined as software, tools, and libraries developed by Supplier prior to or independently of this Agreement and listed in Schedule X. Supplier grants Client a perpetual, irrevocable, worldwide, royalty-free, sublicensable licence to use Background IP solely to the extent embedded in or necessary to operate the Deliverables. Supplier shall not incorporate any third-party open-source components with copyleft licences (including GPL, AGPL, or SSPL) into the Deliverables without prior written consent.

Wording that quietly doesn't: 'Supplier retains all pre-existing IP and general know-how.' 'General know-how' is a loophole that lets the vendor rebuild your model for the next client.

Specifically dangerous: a clause giving the vendor the right to 'use anonymised or aggregated data' from your engagement for 'service improvement'. In an AI build, 'service improvement' may mean training their next model on your embeddings. Strike it or narrow it to pure operational telemetry.

Question to put to the vendor: 'Give us the full Schedule of Background IP you intend to use. Confirm you will not train any model you offer to another client on data, embeddings, or weights derived from our engagement.'

4. Foundation model licensing and the pass-through problem

What it's for: if your dev partner fine-tunes Llama, Mistral, or a similar open-weight foundation model, the licence of the base model flows through to the fine-tuned weights. A Llama derivative inherits Meta's acceptable use policy and naming requirements. Your contract must acknowledge this and allocate responsibility for compliance.

Wording that protects you: Supplier warrants that it has identified every third-party foundation model, dataset, or pre-trained component used in the creation of the Deliverables, and has listed each in Schedule Y together with its licence terms. Supplier warrants that the Deliverables as delivered comply with all such licences, and indemnifies Client against claims arising from licence breaches attributable to Supplier's selection or use.

Wording that quietly doesn't: 'Supplier warrants the Deliverables do not infringe third-party IP.' This is standard non-infringement wording and does not surface the licence pass-through issue.

Question to put to the vendor: 'Every foundation model, every open dataset, every pre-trained embedding — give us the list and the licence for each. If we later want to switch from an open-weight model to a commercial one, what work does that trigger and who pays?'

5. Training data provenance and the chain-of-title record

What it's for: investors now want to see that every data point that went into training has a documented right to be there. If the vendor scraped, bought, or synthesised any training data, you need the receipts.

Wording that protects you: Supplier shall maintain and deliver to Client a Training Data Register documenting, for each dataset used in training or fine-tuning: (a) its source, (b) the legal basis for its use, (c) any licence terms or terms of service governing its use, (d) whether it contains personal data and if so the lawful basis under UK GDPR, and (e) any contractual restrictions on downstream use of models trained on it.

Wording that quietly doesn't: 'Supplier will use only lawfully obtained training data.' This is unverifiable and gives you nothing to show diligence.

Question to put to the vendor: 'Show us the Training Data Register as it stands today. If we are acquired next year, our acquirer's lawyers will ask for this — can you produce it in a format that satisfies them?'

6. Escrow and transition-out for model artifacts

Assignment on paper is worthless if the weights live on the vendor's GPU cluster and you cannot extract them. Your transition-out clause needs to name the artifacts and the format.

Wording that protects you: On termination or expiry, Supplier shall deliver within [X] days: (a) all model weights, checkpoints, and adapters in their native framework format (PyTorch, SafeTensors, or equivalent), (b) all training and evaluation datasets, (c) all embeddings and vector indexes with the schema and generation code, (d) documented reproduction instructions sufficient for a competent ML engineer to retrain the model from scratch, and (e) deletion certificates confirming removal from Supplier's infrastructure within [Y] days thereafter.

Question to put to the vendor: 'Walk us through, as a dry run, the handover. What do we receive, in what format, and what tooling do we need to run it independently?'

The jurisdictional trap: where was the model trained?

Stability AI's defence in the Getty case — that no training occurred in the UK — is a preview of what an offshore dev partner may argue if a dispute arises over your model weights. If training happened on cloud infrastructure in a third country, under that country's law, your UK-law MSA may be contested as the wrong forum for determining who owns the weights.

Add a clause that fixes this: The parties agree that for the purposes of determining ownership of AI Assets under this Agreement, the place of creation shall be deemed to be England and Wales, and English law shall apply to all questions of ownership, authorship, and assignment, regardless of the physical location of the computing infrastructure on which training or fine-tuning is performed.

Cost and timeline for fixing this

A clean amendment to an existing MSA — adding the clauses above, drafting the Schedules, and running one negotiation round with the vendor — is a short piece of work for a UK tech-focused solicitor. What drives it longer or shorter is: how willing your vendor is to sign the expanded assignment without re-pricing the engagement, whether Background IP needs to be itemised from scratch or already exists, and whether a Training Data Register has to be reconstructed after the fact (the expensive case) or simply formalised from existing records (the cheap case).

The three specifics that turn this from a range into a real quote are: (1) the number of separate datasets and foundation models already in use, (2) whether the vendor is a UK entity or will require conflict-of-laws drafting, and (3) whether your investor's counsel has given you a specific clause markup to respond to or you are drafting proactively. On the UK market context: UK AI firms raised £6 billion in 2025, up 52% year-on-year, and the AI Opportunities Action Plan is pushing more model development into UK commercial contracts — so expect diligence standards to tighten, not loosen.

How CodeNicely can help

When we built GimBooks, a YC-backed accounting SaaS, the engagement included structured IP assignment covering not just the application code but the data models, trained components, and derivative datasets — because a fintech company that cannot show clean chain of title to its AI assets cannot pass institutional diligence. Our standard MSA for AI builds names model weights, embeddings, fine-tuning checkpoints, and derivative training datasets as assigned IP, maintains a Training Data Register from day one, and commits to the transition-out artifact list above. Full IP ownership and no vendor lock-in is not a marketing line for us; it is how the paperwork is drafted before the first sprint begins. If you are scoping a new AI build or need a current engagement's IP position audited before a round closes, we can walk through the specifics with you and your solicitor.

The one-page checklist before you sign

1. Does the Deliverables definition explicitly name model weights, embeddings, fine-tuning checkpoints, and derivative datasets?
2. Is there a standalone AI assets assignment clause that names section 9(3) CDPA?
3. Is Background IP listed in a Schedule, not left as 'general know-how'?
4. Is there a bar on the vendor training future models on your data, weights, or embeddings?
5. Is every foundation model and third-party dataset listed with its licence?
6. Does the vendor maintain a Training Data Register you can hand to a diligence lawyer?
7. Does the transition-out clause specify artifact formats and reproduction instructions?
8. Is there a jurisdiction clause that fixes English law regardless of where training physically occurred?

Eight questions. If any answer is no or unclear, that is the gap your investor's counsel will find.

This post is a practitioner's walkthrough of contract structure, not legal advice. Every clause above needs to be reviewed and adapted by a qualified UK solicitor against your specific MSA, your vendor's position, and your investor's requirements before signing.

Frequently Asked Questions

Does a standard 'work for hire' clause cover AI model weights under UK law?

No. The UK does not have a 'work for hire' doctrine in the US sense; ownership of commissioned software defaults to the author under the CDPA unless expressly assigned. For model weights specifically, section 9(3) adds a further complication by treating computer-generated works as authored by the person making the arrangements — which a court could interpret as the vendor running the training job. Explicit assignment language naming weights, embeddings, and training derivatives is the only reliable fix.

Who owns the code when you outsource software development in the UK by default?

By default, the developer owns the copyright in code they write, even when paid to write it, unless the contract expressly assigns ownership to the client. This is different from employment, where works created by employees in the course of employment vest in the employer automatically. For outsourced development — and especially for AI artifacts beyond conventional code — the assignment must be explicit, present-tense ('hereby assigns'), and cover future rights.

Can we retroactively fix an IP clause for a model that has already been trained?

Yes, usually through a deed of assignment executed between the parties that covers everything created to date. It is cleaner and cheaper than it sounds if the vendor cooperates — which they usually do, because refusing creates a reputational problem for them with future clients. The harder part is reconstructing the Training Data Register after the fact if nobody kept records of what data was used; that is the work your solicitor cannot do for you.

What should the IP clause say about the vendor reusing general ML techniques they learned on our project?

Allow it narrowly. A sensible carve-out confirms the vendor retains residual skills, techniques, and know-how not embodied in specific code, data, weights, or documentation — this is standard and reasonable. What must be prohibited is reuse of your data, your derived datasets, your embeddings, or weights trained on your data for any other client or product. Draw the line at artifacts, not at the engineers' brains.

How much does this matter if we are using an off-the-shelf model like GPT-4 via API with no fine-tuning?

Less, but not zero. If there is no fine-tuning and no proprietary weights, your IP position centres on the orchestration code, the prompt library, any evaluation datasets, and the vector indexes of your embedded content — all of which still need to be explicitly assigned. The moment you fine-tune, train an adapter, or build a meaningful embedding corpus, you are back in the full-fat version of this problem and need the clause family above.