Who Owns the AI Your Development Company Builds?
IP ownership in AI development contracts is more complicated than in traditional software — and the defaults often favor the vendor, not you.
When you hire a software agency to build a website, the default expectation is clear: you pay for it, you own it. Custom AI development has a more complicated ownership landscape. The trained model, the training data, the fine-tuned weights, the inference infrastructure, and the application code are all distinct assets — and each can be owned differently depending on your contract. Most clients don't realize this until after the project is signed.
This guide covers the key ownership questions in AI development contracts, what the dangerous defaults look like, and what to insist on before you sign.
What assets are actually created in an AI project?
An AI development project typically produces several distinct deliverables that each carry their own ownership questions: the application code (backend API, frontend, integrations), the model weights (the trained or fine-tuned parameters that encode what the AI "knows"), the training pipeline (the scripts and infrastructure used to train or retrain the model), the training data or the data processing pipeline, the evaluation framework and test sets, and the inference infrastructure configuration. Each of these should be addressed explicitly in your contract.
Model weights are the core IP asset. Without ownership of the weights, you cannot retrain, modify, or replicate the AI without the vendor.
Training pipelines give you retraining independence. Without them, you are dependent on the vendor for any future model updates.
Application code is where most standard "work-for-hire" clauses apply clearly. This is often the only thing explicitly addressed in basic contracts.
Owning the application is like owning the car without the engine. The model weights are the engine. Make sure the contract gives you both.
Common contract traps buyers miss
The most common dangerous default in AI development contracts is a clause that assigns code ownership to you but retains model weights and training infrastructure for the vendor "for purposes of operating and improving their services." This is particularly common with vendors who build on their own proprietary platforms or who plan to use your training data to improve models they sell to other clients. Other traps include:
License-not-own clauses: you receive a license to use the model, not ownership of the weights. The vendor can change terms, raise prices, or discontinue the license.
Training data reuse: clauses that permit the vendor to use your proprietary data to train other models or improve their own foundation models.
Hosted-only delivery: the model is only available through the vendor's API; you receive no weights, no portable deployment, no way to run it independently.
No retraining rights: you own the weights but are contractually prevented from retraining or modifying the model without re-engaging the vendor.
What you should insist on
At minimum, your contract should give you: full ownership of all model weights and parameters produced during the project, full ownership of all application code, the right to retrain and modify the model independently, explicit prohibition on the vendor using your training data for any purpose other than your project, and portable delivery in a format you can run on your own infrastructure (or standard cloud infrastructure) without the vendor. If a vendor cannot agree to these terms, you need to understand exactly what you are buying and why.
The foundation model question
Many AI systems are built on top of commercial foundation models (GPT-4, Claude, Gemini, Llama). In these cases, the underlying model is owned by its creator under its own licensing terms — you cannot own that layer. What you should own is everything built on top of it: the fine-tuning applied to that base model, the retrieval system and prompt engineering, the application layer, and the custom evaluation and testing infrastructure. Ask your vendor to explicitly separate these layers in the contract. For context on how this affects build decisions, read custom AI vs off-the-shelf AI tools.
The IP ownership question is closely related to questions about vendor lock-in and long-term operating costs. See what to ask before hiring an AI development team and AI development red flags for how to surface these issues before you sign.
What if the vendor uses proprietary tooling to build my system?
Some vendors build on their own platforms or use internal tooling that is not transferable. This is not necessarily a dealbreaker, but it must be disclosed and priced into your decision. You are accepting vendor dependency in exchange for faster delivery or lower upfront cost. Understand that dependency explicitly before agreeing to it.
Can I get IP ownership even if I didn't pay for the full development?
In some cases, vendors will offer a model-as-a-service arrangement at lower upfront cost but with shared or retained IP. This can make sense for early-stage validation but creates long-term dependency. If you plan to build your business on this AI capability, negotiate full ownership upfront rather than trying to buy it back later at a higher price.
Sources
US Copyright Office — Copyright and artificial intelligence: ownership and authorship. copyright.gov
World Intellectual Property Organization — Emerging AI IP frameworks. wipo.int
Law.com — AI development contracts: key clauses and negotiating points. law.com
At TTGC, you own everything we build — model weights, code, pipelines. Let's talk about your project.
Book a free Brand and Tech Assessment to see exactly how we would grow your organic visibility.
