Building products with AI
Who owns the AI product you're building with a vendor
When you hire someone to build an AI tool for your business, make sure you own the code, data, and models at the end.
· 5 min read · Product strategy · Vendor relationships · AI ownership
When you hire a team to build an AI product for your business, you need to own three things: the code that runs it, the data you feed it, and the trained model that makes decisions. Without ownership, you're renting your own product.
This matters because AI products aren't like traditional software. A vendor can write code and hand it over. But they can also train a model on your data, lock it into their servers, and make you dependent on them to change anything. You end up paying a monthly fee forever, unable to switch vendors, unable to hire someone else to improve it, unable to even understand how it works.
What ownership actually means
Owning your AI product means three separate things.
Code ownership. You get a copy of the source code—the human-readable instructions that make the tool work. You can read it, modify it, or hire someone else to improve it. This is standard with good software vendors and should be non-negotiable.
Data ownership. The data you provide to train and run the tool stays yours. You can download it, move it, use it elsewhere, or delete it. The vendor should never use your data to train models for other customers or to improve their own product without explicit permission and payment.
Model ownership. The trained model—the thing that actually makes predictions or decisions—is yours to keep, move, or modify. A vendor can host it for you, but you should be able to download it and run it elsewhere if you need to.
Hosting and maintenance can stay with the vendor. You don't need to run servers yourself. But the underlying work should be yours.
Why vendors resist this
Some vendors push back on ownership because it's their business model. They build tools that are hard to move. You get locked in. They keep you as a customer not because you love the product, but because switching costs too much. Over three years, that lock-in costs you 20 to 40 percent more than it should.
A vendor who won't give you ownership is telling you something: they don't trust the product to keep you around on merit alone.
Good vendors—the ones who build things customers actually want to keep—have no problem with ownership. They know you'll stay because the tool works, not because you can't leave.
How to write it into your contract
Before you sign anything, add three clauses.
Source code. "At project completion, the vendor will provide the client with full source code in a standard format, with all rights to modify and distribute it."
Data. "All data provided by the client remains the client's property. The vendor will not use it for any other purpose, including training other products, without written permission. The client may request a copy of all data at any time."
Model. "The trained model is owned by the client. The vendor will provide it in a portable format and document how to run it. The client may host it elsewhere or modify it."
These aren't unusual requests. Any vendor who builds for serious businesses will have done this before. If they hesitate or ask for a premium, that's a signal.
What it costs
Ownership adds 2 to 4 weeks to the project and typically 10 to 15 percent to the price. You'll pay for documentation, for packaging the code so someone else can understand it, for model export and testing. It's real work.
But compare that to the cost of being locked in. A dental clinic in Kelowna paid a vendor $800 a month to run a scheduling tool that could have cost $300 elsewhere. They were locked in because the vendor owned the model and wouldn't export it. Over three years, that lock-in cost them $18,000 in extra fees. The upfront cost of ownership would have been $3,000.
The middle ground
Some vendors offer a compromise: you own the code and data, but they keep the model running on their servers. You pay a monthly hosting fee—$200 to $500—but you're not locked in. If the relationship ends, you download the model and run it somewhere else.
This is often the right balance. You get ownership and control. The vendor gets a sustainable business. You both win.
A 12-person software company in Gastown used this model. They paid $8,000 upfront to build a document reader and $300 a month to host it. After two years, they had paid $16,000 total. They owned the code and the model. When they wanted to improve it, they hired a contractor who understood the codebase and made changes in a week. That contractor would have been impossible to hire if the vendor owned the model.
Where to start
- Before you talk to a vendor, write down what you need to own. Decide now whether you want to own the code, the data, and the model, or whether you're comfortable with a monthly hosting fee as long as you can leave. Know your answer before the conversation.
- Ask the vendor directly: "Do we own the code, data, and model?" Listen for hesitation. A vendor who says yes immediately and offers to put it in writing is worth talking to further. One who says "We can discuss that" is already hedging.
- Get legal to review the contract. Have a lawyer in your province read the ownership clauses before you sign. It costs $500 to $1,000 and saves you thousands later. Make sure the contract is clear about what happens if the relationship ends.


