Who Owns the IP in AI Development: Code, Prompts, Models

This is for a founder about to sign a contract with an AI development agency and wants to know, concretely, what "you own the IP" needs to say in writing to actually be true. By the end you will know what counts as your IP, what doesn't by default, and the specific clauses to insist on before you sign.

Who owns the code and IP when you hire an AI development agency?

By default, nobody but the agency, unless the contract says otherwise. Under US copyright law, an independent agency owns the code it writes unless the contract includes a written assignment of IP rights or valid work-made-for-hire language — paying an invoice for the work does not by itself transfer copyright ownership (source). This surprises a lot of founders who assume "I paid for it, so I own it" is how it works. It isn't, unless the paperwork says so explicitly.

There's a further wrinkle specific to custom software: the "work made for hire" doctrine in US copyright law only automatically applies to commissioned work in nine narrow statutory categories, and most custom software doesn't fall into any of them. So even a contract that says "this is work made for hire" may not legally transfer ownership on its own — it needs to be paired with an explicit assignment clause (source).

What should an AI development contract say about IP ownership?

It should say, in plain and specific language, that the agency irrevocably assigns all intellectual property created under the engagement to you — not that you receive a license, and not just "access." A strong clause names the categories explicitly: source code, prompts, fine-tuned model weights, documentation, and any derivative works. Vague language like "work product belongs to Client" is not considered sufficient on its own; a well-drafted clause spells out exactly what's included (source).

Watch for one specific trap phrase: "Client receives a perpetual license to the work product." A license is not ownership. It typically means the agency retains the underlying copyright and can reuse, resell, or relicense the same code to other clients, while you only have permission to use it yourself (source).

Does my AI agency own the trained models or prompts they build for me?

Only if your contract is silent on it, which is a common gap. Prompts and fine-tuned model weights are newer categories than source code, and some contracts still only cover "code" explicitly, leaving prompts, prompt chains, evaluation datasets and fine-tuned weights in a grey area. If you're paying for a fine-tuning run or a carefully engineered prompt library that's central to your product, name it specifically in the IP clause rather than assuming "code" covers it. The same logic applies to evaluation datasets and test suites built during the engagement — valuable IP that's easy to leave out if nobody names it.

What should an AI development contract explicitly cover?

A complete IP clause for an AI engagement should separate four categories, since they're not all treated the same way by default:

• Client materials — your own data, content, brand assets and product information you provide. You already own these; the contract should just confirm it.
• New work product — source code, prompts, prompt chains, fine-tuned model weights, evaluation datasets, and documentation created specifically for your project. This is what the assignment clause needs to cover explicitly.
• Agency background IP — reusable internal tools, templates, libraries or frameworks the agency built independently of your project and uses across clients. Reasonable for the agency to retain, but should be disclosed and, ideally, listed so you know what's "theirs" versus "yours" in the final codebase.
• Third-party and open-source components — libraries and models used under their own license terms. The contract should disclose which licenses are involved, since a copyleft license (GPL, AGPL) folded into your product without disclosure can create obligations you didn't agree to (source).

What about accounts, hosting and infrastructure — who should own those?

You should, from the start, not as a later handover. Hosting, domain registrations, cloud accounts, and AI provider accounts (OpenAI, Anthropic, etc.) should be registered in your name even while the agency manages them day to day. This matters for two practical reasons beyond IP: it means you see real usage and cost data directly rather than a marked-up invoice, and it means there's no awkward account-transfer step if the relationship ends. If an agency insists on running everything through their own accounts "for simplicity," treat that as a request worth pushing back on, not a neutral default.

Should source code be delivered at the end, or live in my repo the whole time?

In your repository from day one, not handed over at project end. A handover-at-the-end model creates real leverage risk: if a dispute arises mid-project over scope, payment, or quality, an agency holding the only copy of your code has significant negotiating power you'd rather not grant them. Commits landing in your own repository throughout the build also give you a running paper trail of what was actually done each week, which is useful well beyond the IP question.

What indemnification should I ask for around IP?

Ask the agency to indemnify you against claims that the delivered software infringes a third party's intellectual property rights. You generally have no independent way to verify that a vendor's code (or a model's training data, in some disputed cases) doesn't infringe someone else's rights, so this clause shifts that risk to the party that actually made the technical choices (source). It's a standard ask in professional services contracts and a reasonable agency won't push back on including it.

Who owns the data used to train or evaluate the AI?

Your own data stays yours by default, but it's worth stating explicitly in the contract, especially for anything involving fine-tuning or a custom evaluation set. If an agency fine-tunes a model on your proprietary data, or builds a labeled evaluation dataset from your real customer interactions, that dataset is as much your business asset as the data it was built from — make sure the contract names it as your IP rather than leaving it as an unstated byproduct of the engagement. The one exception worth negotiating explicitly: if the agency wants to use anonymized learnings from your project to improve their own general capability (not your specific data, just the lessons learned), that's a reasonable ask to allow, but it should be a separate, limited clause, not folded silently into a broad IP waiver.

What happens to subcontractor-created IP?

The same assignment obligations need to flow down to any subcontractor the agency uses, or you end up with a gap. If an agency brings in a specialist contractor for part of the work — a fine-tuning specialist, a UI contractor — and that subcontractor hasn't separately assigned their IP to the agency (or directly to you), the agency may not actually have clean title to assign to you in turn. Ask directly whether subcontracting happens on your project and, if so, whether the agency's contract with subcontractors includes the same IP assignment and confidentiality terms as yours does with them.

A worked example: what a weak clause costs you later

Picture a scenario that plays out more often than founders expect: an agency builds a custom RAG pipeline and a fine-tuned support-response model for your SaaS product over eight weeks, under a contract that says "all deliverables belong to Client" with no further detail. Eighteen months later you want to switch vendors or bring the work in-house. The agency points out that "deliverables" in the contract referred to the application code, not the fine-tuned model weights or the evaluation dataset they built to test it — both of which they argue are their own methodology and tooling, not something explicitly assigned. You now either renegotiate from a weak position (you need the model, they know it) or rebuild the fine-tuning work from scratch. A contract that named "all code, prompts, fine-tuned model weights, and evaluation datasets created under this engagement" explicitly would have closed that gap before it ever became a problem.

Does this work differently outside the US?

The specific legal mechanism varies, but the practical advice doesn't. In the EU and UK, the work-for-hire doctrine as understood in US copyright law doesn't apply the same way, which makes an explicit, well-drafted assignment clause even more important rather than less — you can't lean on a statutory default to fill gaps (source). If your agency is based in India, as many AI development vendors are, the same principle holds: ownership follows the contract's explicit assignment language, not the location of the team that wrote the code. Ask any international vendor which jurisdiction's law the contract is governed by and whether that affects enforceability of the IP assignment.

What are the warning signs of a weak IP clause?

• "Client will have access to the codebase" — access is not ownership.
• "Work for hire" with no accompanying assignment language, especially for custom software outside the nine statutory work-for-hire categories.
• No mention of prompts, fine-tuned models, or evaluation datasets at all — only "code" or "deliverables."
• Agency-controlled hosting and AI provider accounts with no plan to transfer or co-own them.
• No indemnification clause for third-party IP infringement claims.

How we approach this at Venzpire

Client owns all code and IP, full stop, with your repository as the system of record from day one — not a deliverable handed over at the end. AI usage is billed to your own provider accounts at cost, so you see exactly what you're spending and never lose access to usage history if the engagement ends. This is how every engagement is structured, from a $1,500 discovery sprint through a full $5,000 build. See AI MVP development for how a build is scoped, or start at apply.