Who owns the code, prompts and models? Contract terms that matter

AI development contract IP is the clause most buyers skim and most regret. The rule is simple: insist on ownership of code, infrastructure configuration, prompts and fine-tuned model weights on payment, with any pre-existing tools the vendor brings licensed to you perpetually. Then extend the list to the things that are new with AI: evaluation sets, synthetic or labelled data derived from your data, and the documentation that explains why the system behaves as it does. Those are what let you run, change and re-host the system without the vendor.

This article walks through each category of asset, what "ownership" has to mean for it in practice, the clauses that quietly undermine it, and the questions to ask before signing. It is written from the vendor's side of the table, since our own contracts give clients all of this by default, and we have seen what happens when other contracts do not.

Why AI project ownership is different from software ownership

Traditional software contracts had one main asset: source code. Assign it, hand over the repository, done. An AI system has at least six distinct assets, and several of them are not obviously "code". A prompt is text. A fine-tuned model is a set of weights that may only be usable on the provider that produced it. An evaluation set is a spreadsheet of questions and expected answers. Documentation is prose. If the contract only mentions source code, the vendor may in good faith keep the rest, and you will discover the gap when you try to change providers or hire an internal team.

Prompt ownership: the clause that did not exist five years ago

Prompts are where much of the system's behaviour lives. A retrieval assistant's tone, refusal rules, citation format and escalation logic are usually in a few hundred lines of prompt text and templates. If a vendor treats prompts as their methodology, you may find you own an application that cannot be changed without them.

The contract should state that prompts, prompt templates, system instructions and the version history of all of them are deliverables assigned to you. It should also require that prompts be stored in your repository, not in a vendor-owned prompt management tool, or at minimum that the tool exports them in plain text. Our practice is to treat prompts like code: versioned, reviewed and evaluated on every change, in your repository from day one.

Fine-tuned model ownership and provider constraints

Fine-tuned weights are the awkward case, because ownership depends on where the fine-tune was run. Open-weight models fine-tuned on your own infrastructure produce weights you can hold, copy and deploy anywhere. Fine-tunes run through a hosted provider's API typically live inside that provider's account and may not be exportable at all; what you can own is the training data, the recipe (hyperparameters, base model version, preprocessing) and the account the fine-tune sits in.

So the contract should say three things: the fine-tune is created in an account you control; the training data and recipe are delivered so the fine-tune can be reproduced; and where the provider permits export, the weights are exported to your storage. Ask the vendor which case applies before the work starts, because it changes the architecture. The self-hosted LLM decision is partly an ownership decision.

Evaluation sets and derived data

Evaluation sets are the most under-valued asset in an AI contract. They encode what "correct" means for your system, and rebuilding them from scratch takes weeks of subject-matter time. If the vendor built them, they are part of the work you paid for. The same applies to labelled examples, synthetic data and embeddings computed from your documents: all derived from your data, all yours.

Write them into the deliverables list explicitly. "Evaluation sets, scoring code and results history for every release" is a sentence that costs nothing to add and saves a great deal later. Ask for the golden set to be in a plain, portable format rather than locked to one evaluation platform.

Pre-existing tools, licences and open source

Every vendor brings tooling: retrieval components, evaluation harnesses, deployment scaffolding. It is reasonable for them to keep ownership of these; it is not reasonable for your system to stop working when the engagement ends. The standard fix is a perpetual, royalty-free, non-exclusive licence to use, modify and sublicense the vendor's pre-existing tools as embedded in your deliverables.

Open-source components need a licence inventory. Most permissive licences are fine; some copyleft licences and some model licences carry obligations or usage restrictions. Ask for a bill of materials listing every third-party component, its licence and, for models, any usage restrictions on the base model.

Clauses that quietly undermine ownership

• Ownership on final payment only, with no interim assignment, so a dispute at the end leaves you with nothing
• Vendor cloud accounts: the system runs in infrastructure you do not control and cannot export
• Methodology carve-outs broad enough to cover prompts, evaluation approach or architecture
• Licence to use, not to modify, which blocks an internal team from changing the system
• Data use rights allowing the vendor to train on your data or your outputs
• Confidentiality that expires on data that should be protected indefinitely
• No escrow or handover obligation if the vendor ceases trading

Data protection obligations sit alongside IP

Ownership of the system is separate from the rules on the data inside it. If your users are in India, the Digital Personal Data Protection Act shapes what a vendor may do as a data processor; if they are in Europe, GDPR does. The contract should include a data processing agreement, name where data is stored and processed, prohibit training on your data without consent, and require deletion on termination. Our DPDP Act guide covers the Indian obligations in detail.

A worked example

A hospital network had commissioned a multilingual voice agent from a previous vendor. The application code was theirs, but the prompts lived in the vendor's orchestration platform, the speech models were configured in the vendor's provider accounts, and there was no evaluation set. When the relationship ended, the hospital owned a repository that could not be run. We rebuilt the multilingual voice agent with everything in the hospital's own accounts: prompts in their repository, provider keys in their vault, an evaluation set of recorded and transcribed calls with expected outcomes, and runbooks a new engineer could follow. The contract listed each of these as a deliverable with an interim assignment at each milestone. The technical work was similar to the first build; the difference was what the hospital held at the end.

Team and timeline

Ownership terms are settled before any program starts. Our standard terms assign code, prompts, models, evaluation sets, infrastructure configuration and documentation to the client, with milestone-based interim assignment and a perpetual licence to any pre-existing tooling. Sprint Zero, ten working days at $3,250 or ₹2,00,000, produces a scoped build and a deliverables list you can take to your legal team before committing to Launch 6, which delivers a production MVP in six fixed weeks from $26,500. Legal review typically runs in parallel with discovery, so it does not add to the timeline. The pricing page has full program details; contact us if you would like our standard terms to compare against another vendor's.

Before you start: a checklist

• List every asset the project will create: code, infra, prompts, models, evals, derived data, documentation
• Require interim assignment at each milestone, not only on final payment
• Have all cloud, provider and tooling accounts created in your name
• Require prompts and evaluation sets to live in your repository in plain formats
• Get a perpetual licence to modify the vendor's pre-existing tools
• Prohibit vendor training on your data or outputs
• Ask for a third-party component and model-licence inventory
• Add a data processing agreement covering storage location and deletion

Questions clients ask

• Can a vendor reuse patterns from our project elsewhere? General know-how, yes; your code, prompts, data and evals, no. The contract should draw that line.
• Does ownership matter if we plan to stay with the vendor? Yes. Relationships end, vendors are acquired, and internal teams get hired. Ownership is what makes any of those uneventful.
• What about the base model? You do not own GPT-class or open-weight base models; you own your fine-tune, recipe and data, subject to the base model's licence.
• Is source code escrow worth it? If everything is already in your accounts, escrow is unnecessary; that is the better arrangement.

Related reading

See questions to ask before hiring an AI agency, private agentic AI for deployments inside your own environment, and red flags when hiring an AI development partner. For the data-processing side, the UK Information Commissioner's Office publishes practical guidance on contracts between controllers and processors that translates well beyond the UK.

Own everything the project creates, in accounts you control, in formats you can read; a contract that delivers that has done its job.