What you should own when the AI build ends
The code is the least valuable thing you funded. Name the prompts, the eval set, the embeddings and index configuration, the fine-tuned weights if any, and the infrastructure definition, in usable formats. The eval set matters most, because it is the artifact a successor cannot cheaply rebuild.
Most AI contracts assign ownership of the software, which sounds comprehensive and is not. The code in one of these systems is frequently the least interesting thing that was built: a few thousand lines of orchestration that a competent team could rewrite in a fortnight. Everything that made the system work is somewhere else, and standard deliverables clauses do not mention it.
A vendor contract guide from August 2026 puts the requirement well: ownership must "name the derived artifacts rather than only the code, meaning the prompts, any fine-tuned weights, the embeddings built from your documents and the evaluation set, because those are made from your material and are the parts a successor cannot cheaply rebuild". That last clause is the whole test, and it is worth applying item by item.
The five things to name
The prompts, with their history. A production prompt is not a paragraph somebody wrote once. It is the residue of months of iteration, and most of its lines exist because something went wrong. Ask for them in version control rather than as a final export, because the reasons are in the commits and the reasons are what stop your next team removing a line that was load bearing.
The evaluation set. Covered separately below, because it is the one that decides whether the rest is usable.
The embeddings and, more importantly, how they were made. The vector index itself is regenerable. What is not obvious is the configuration that produced it: the chunking strategy, the embedding model and version, the metadata schema, the preprocessing. Without that, rebuilding the index produces a system that behaves differently, and as we cover in why RAG gives wrong answers, chunking decisions are frequently the difference between correct and confidently wrong.
Fine-tuned weights and the training data behind them, where fine-tuning happened at all. Weights without the dataset are a dead end: you can run the model and never produce another one. This is the item legal teams already look for, which is why it is the one most often handled correctly.
The infrastructure definition. Not access to the running system, the definition of it. If the deployment lives in a vendor account and is reproducible only by the person who built it, you have bought a service and called it a build.
Why the eval set is the one that matters
Everything else can be reconstructed with effort. Prompts can be rewritten. An index can be rebuilt. The evaluation set cannot, because it is not a technical artifact, it is accumulated institutional judgement about what a correct answer looks like for your business.
A real one contains the case where two policies contradict each other and the answer is the newer one. The customer phrasing that means something specific in your industry. The edge case that caused an incident in March and the behaviour that was agreed afterwards. Every entry is a decision someone made, and most of the people who made them will not be available to make them again.
The practical consequence is the test for the whole handover: without the eval set, a new team cannot safely change anything. They can read the code, but they cannot tell whether a change made things better or worse, so they will either freeze the system or break it slowly. If you do not own the eval set, you do not own the system, whatever the contract says about the software.
This is the same asset that makes model migrations routine rather than frightening, which we go into in moving off a retired model. A system whose eval set you own survives its provider changing underneath it. One whose eval set you do not own has to be rebuilt or re-hired for, roughly annually.
Format is half of ownership
Owning something you cannot open is a technicality. Specify the form as well as the right, because the difference between these is months.
- Version control, not archives. A repository you can clone, with history, not a zip file at the end.
- Your accounts, not theirs. Model provider, vector store, hosting, monitoring. Vendor accounts with your data in them are a dependency dressed as a convenience.
- Structured, not documented. The eval set as data a harness can run, not a spreadsheet describing tests somebody performed.
- Runnable, not described. A new engineer should be able to stand the system up from what you hold, and the only real proof is that someone has done it.
The clause and the test
Ask for the deliverables section to list the five items explicitly, in language a technical person would recognise, transferring at completion. Most reasonable vendors will agree, because for a competent team none of it is the moat. If a vendor resists specifically on the eval set or the infrastructure definition, that is worth understanding before you sign rather than at the end.
Then verify rather than assume, with a rehearsal partway through rather than a clause you rely on at the end. Take what you currently hold, hand it to an engineer who did not build it, and ask them to stand up the system and run the evaluation. Whatever they cannot do is the real gap, and finding it in month three costs a conversation while finding it in month twelve costs a rebuild.
This pairs with the questions worth asking before signing, which we set out in AI vendor security questions, and with the scoping side in what custom AI development costs.
Our own answer to all of this sits in the procurement pack, and how we structure engagements covers what transfers and when. We would rather you asked these questions of us than discovered the answers later.
Related reading
Get this applied to your business.
The free AI audit measures your live setup and shows where AI would actually pay off.