The ownership conversation almost always happens at the wrong time. It comes up at handover, when the build is done, the invoice is paid, and someone finally reads the agreement closely enough to notice it says "licence" rather than "assignment." By then your leverage is gone. The right time is before work starts, and the reason people skip it is that ownership sounds like one question when it is actually eight.
TL;DR
- Paying for a build does not automatically give you ownership. Contractors typically own what they create unless the contract assigns it in writing.
- There are eight separate artifacts, and a contract that says "deliverables" covers none of them clearly.
- The most commonly forgotten items are prompts and evaluation sets. Both encode more of your business logic than the code does.
- Ask whether your data trains anything, whose cloud account holds production, and whether a fine-tune can actually be exported.
- A vendor keeping generic reusable tooling is normal and healthy. A vendor keeping your business logic is not.
The short answer
Ask for written assignment, effective on final payment, naming five things explicitly: source code, prompts and system instructions, configuration and infrastructure-as-code, evaluation and test sets, and all conversation and business data. Separately confirm that your data trains nothing, that production runs in cloud accounts you control, and that any fine-tuned model is exportable or, if it is not, that you know that before you depend on it.
Ownership is eight questions, not one
Here is the full list, with who typically ends up holding each one when nobody negotiates.
| Artifact | Default outcome | What to ask for |
|---|---|---|
| Application source code | Vendor owns, you get a licence | Full assignment on final payment |
| Prompts and system instructions | Undefined | Named explicitly as assigned deliverables |
| Fine-tuned model | Lives in vendor's provider account | Your account, or written export path |
| Evaluation and test sets | Vendor keeps, treated as method | Assigned, delivered as files |
| Vector store and embeddings | Vendor's infrastructure | Your infrastructure, or exportable |
| Conversation and business data | Ambiguous, sometimes shared | Yours outright, no training use |
| Infrastructure configuration | Vendor's internal tooling | Delivered as code, in your repo |
| Third-party model terms | Provider's default | Confirmed no-training tier in writing |
Read down the middle column. None of those defaults involve anyone acting in bad faith. They are what happens when a contract says "the Developer shall deliver the Software" and nobody defines what the software includes, in a system where most of the behaviour lives outside the code.
The two nobody thinks about until it is too late
Prompts carry more of your business than your code does. The application logic around an AI system is often unremarkable: receive input, retrieve context, call a model, take an action. What makes it yours is the instruction set. Your tone, your escalation thresholds, your rules about what the system must never do, and the accumulated wording fixes from every failure you found in testing. That is months of tuning expressed as text, and text is exactly the kind of asset a contract forgets to name.
If your agreement does not use the word "prompt," you have not covered them. A new team receiving code without prompts is receiving a shell, and they will rediscover your edge cases the expensive way, with your customers.
Evaluation sets are the second one. A mature AI build has a fixed set of test cases with known-correct answers, built from real failures. That set is what lets anyone change the system safely afterwards. Vendors often treat it as internal methodology rather than a deliverable, which is defensible for the harness and indefensible for the cases, because the cases came from your business. Ask for the test cases and expected outputs as files. Without them, your next developer cannot tell whether their change improved anything.
The fine-tune question has a technical answer, not a legal one
People ask "who owns the fine-tuned model" as a contract question. Often the contract cannot help, because the constraint is architectural.
If the model was tuned on a hosted provider, what exists is a resource inside a provider account. Whoever controls that account controls the model. Many hosted fine-tunes cannot be exported as weights under any circumstances, so a clause assigning you ownership of something you cannot take possession of is decorative. What matters is whose account it lives in and what happens to it if the relationship ends.
If it was tuned on open weights running on infrastructure you control, you have a file, and ownership works the way you would expect.
Ask three questions before the work starts: whose account, can it be exported, and what is the fallback if it cannot. There is nothing wrong with a hosted fine-tune. There is something wrong with discovering its constraints in month fourteen.
Data: three separate promises
Ownership. Your conversation logs, customer records, and business documents are yours. This is rarely disputed and should still be written, because "rarely disputed" is not the same as "settled."
No training. Confirm that your data trains nothing: not the foundation model, not the vendor's internal tooling, not a shared benchmark. Major providers offer no-training tiers for business and API usage, but that is a configuration choice someone has to actually make, and the default is not always the one you want. Ask which tier your build runs on and get the answer in writing.
Deletion and retention. What happens to conversation history when you leave, how long it is kept, and whether the vendor retains a copy. This is also the question your own procurement team will ask, which we cover in the security review checklist.
Where our line sits
Since this post is a list of things to demand from a vendor, it seems fair to say what we do.
Everything specific to your business becomes yours on final payment: the application code, the prompts, the configuration, the evaluation cases, the infrastructure definitions, and all of your data. It is written into the agreement as an assignment rather than a licence, and the handover is a defined package rather than a promise to be helpful.
What we keep is the generic scaffolding we bring to every project. Internal libraries, patterns, and tooling developed across previous builds that contain nothing about you. We are explicit about this rather than quiet, because a vendor who claims to assign you everything is either inexperienced or not reading their own contract. Nobody builds from zero, and the parts that get reused are exactly the parts that are not yours.
Production runs in your cloud accounts. Not ours with your name on a folder. If the relationship ends, you remove our access and nothing stops.
That is the standard we would want as a buyer, which is the only real test of whether a policy is reasonable. What actually goes into an AI agent engagement covers the rest of the scope question.
What to do before you sign
Ask for the assignment clause in writing and read whether it says "assign" or "licence." Those words are not interchangeable and the difference is the whole deal.
Ask for the handover package to be listed as line items in the contract: repository, prompts, configuration, evaluation set, credentials, and documentation. A vendor who will not enumerate it is telling you something.
Ask whose cloud account production runs in, and ask it in exactly those words.
Ask what happens on day one after termination. Not what they hope. What technically occurs.
If any of those questions produce a vague answer, that is your finding. Questions to ask an AI consultant has more in this vein, and what to know before hiring covers the earlier stage of the same conversation.
The bottom line
Ownership is cheap to settle before work starts and expensive to argue about afterwards, which is the opposite of how most teams schedule the conversation. The fix takes one email: ask for written assignment of code, prompts, configuration, evaluation sets, and data, effective on final payment, plus confirmation on training use and account control.
A good vendor will answer all of it in a paragraph, because they have answered it before. A vendor who treats the question as unusual is showing you how the handover will go.
Next step: If you want a second read on an AI development agreement before you sign it, send us the ownership and data clauses and we will tell you what is missing. No pitch attached, and we will say so if it looks fine.
Does paying for custom AI development mean I own the code?+
Not automatically. In most jurisdictions, a contractor owns what they create unless the agreement assigns it to you in writing. Employees are different, and that difference catches people out. If your contract says "deliverables" without defining them, or grants you a licence rather than assigning ownership, you may have paid for the build and received permission to use it. Ask for a written assignment of the specific artifacts, effective on final payment.
Do I own the prompts and system instructions?+
You should, and this is the item most often left undefined. Prompts encode your business logic, your tone, your escalation rules, and the accumulated fixes from every failure the system had. Losing them means the next team rebuilds the tuning from scratch. Prompts are usually treated as part of the source deliverable, but only when the contract names them explicitly. If the word "prompt" does not appear in your agreement, it is not covered.
Who owns a fine-tuned model?+
It depends on where it was trained. A model fine-tuned on a hosted provider is usually a resource inside an account, so the ownership question becomes whose account holds it and whether it can be exported. Many hosted fine-tunes cannot be extracted as weights at all. An open-weights model tuned on your infrastructure produces a file you can hold. Ask specifically: whose account, can it be exported, and what happens if the vendor relationship ends.
What contract terms should I ask for on an AI project?+
Five: written assignment of code, prompts, configuration, and evaluation sets, effective on final payment; confirmation that your data is not used to train anything, including the vendor's own tooling; a defined handover package listing every artifact and credential; a clause confirming production infrastructure lives in accounts you control; and a stated position on background IP so you know what the vendor is reusing. Get these before work starts, not at handover.
Is it reasonable for a vendor to keep some IP?+
Yes, and be suspicious of one that claims otherwise. Every experienced team brings reusable scaffolding, internal libraries, and patterns developed across previous projects. A vendor assigning you all of that would be assigning work they do not own and could not deliver. The reasonable line is that generic reusable tooling stays theirs, everything specific to your business becomes yours, and the split is written down rather than assumed.
Free PDF · No fluff
The 2026 AI Development Rate Sheet
Real build, agent, RAG, and consulting rates by tier — the numbers vendors quote behind NDAs, in one PDF.
Written by
Pankaj Kumar
Founder · Metageeks Technologies
Metageeks builds production-ready AI products for $1M–$15M companies — shipped in fixed-price sprints, not open-ended retainers. We write about what actually works in the field.
Connect on LinkedInThe AI Build Brief
Ship AI that actually works.
Practical playbooks on building, pricing, and shipping production AI — one email, every other week. No fluff.
