Who owns the code when you build an AI product with a vendor

When you hire someone to build an AI product for your business, you're making a bet on their skill and your partnership. But the contract you sign determines whether you own what gets built, or whether you're renting it.

This matters more than it sounds. A plumber in Richmond who builds a scheduling tool with a vendor might discover two years later that the vendor owns the code. If the vendor raises prices, goes out of business, or stops supporting the tool, the plumber is stuck. They can't switch vendors without starting over. They can't hire someone else to improve it. They can't sell the business without the vendor's permission.

Ownership of three things matters: the code, the data, and the models.

Your code belongs to you

The code is the instructions that make the tool work. You should own it outright. This means you can read it, modify it, move it to another platform, or hand it to a new team if the original vendor stops working with you.

Some vendors will agree to this immediately. Others will push back and offer alternatives like escrow—a legal arrangement where the code is held by a neutral third party and released to you only if the vendor goes out of business or breaks the contract.

Escrow sounds safe. It isn't, not really. If your vendor disappears on a Friday, you might not have access to the code until Monday. If the code is complex and poorly documented, you'll need weeks or months to understand it well enough to maintain it. Escrow is insurance, not ownership. It costs $500 to $2,000 to set up and $200 to $500 a year to maintain. That money is gone whether you ever use it or not.

Better to own the code outright from the start. If a vendor won't agree, ask yourself why. The honest answer is usually: "We want to keep you dependent on us so we can raise prices later."

Your data stays yours

Your data—customer information, transaction records, documents, feedback—is the fuel that makes the tool useful. You must own it, and you must be able to get it out.

Ask the vendor three questions:

• Where does my data live. Is it in a Canadian data centre, or in the US or another country. This matters for privacy law and for your peace of mind.
• Who can access it. Can the vendor's support team read your customer records. Can they use it to train their tools or improve their service for other clients.
• How do I get it back. If you stop working together, can you export all your data in a standard format—CSV, JSON, a database dump—in a matter of hours, not weeks.

If the answer to any of these questions makes you uncomfortable, keep negotiating. A property manager in Surrey who stores tenant information should know exactly where it lives and who can see it. A dental clinic in Kelowna has legal obligations around patient records. Don't guess.

Models and training

Models are the mathematical patterns that let AI tools make predictions or decisions. If you're paying to train a custom model on your data, you should own it.

Here's where it gets murky. Some vendors will train a model on your data and then own the result. This means they can use what they learned from your data to improve their product for competitors. That's a bad deal. You paid for the training, but they own the upside.

Negotiate ownership of the model in the contract. If the vendor won't agree, ask them to commit in writing that they won't use your data or insights to train models for other clients in your industry.

For most small to medium Canadian businesses—a 12-person software company in Gastown, an accounting firm in Burnaby, a distributor in Calgary—the model question is less urgent than code and data. You're more likely to use off-the-shelf models that the vendor licenses from a larger company. That's fine. Just confirm that you're not paying to train a model that the vendor then owns.

The money question

Vendors who insist on ownership will usually offer you a lower price. The savings are real. You might save 15 to 30 percent on the build. But you're not saving money. You're prepaying for lock-in.

If the vendor raises prices by 20 percent a year, or stops supporting the tool, or goes out of business, you've lost the discount and more. You can't shop around. You can't move to a cheaper alternative. You're stuck.

A fair deal is this: you pay a bit more upfront, you own the code and data, the vendor makes their money on the build, and you both move on. If you want to hire them again later, great. If you want to hire someone else, that's your choice.

Get this in writing before the first meeting. Include it in the statement of work or the contract. Be specific: "Client owns all source code, all data, and any models trained on Client data." Not "Client owns the deliverables." That's vague and leads to arguments.

Where to start

• Write down what you want to own before you talk to any vendor. Code. Data. Models. Anything else. Then add one sentence for each: why it matters to your business. You'll negotiate better when you know what you're protecting.

• Ask three vendors the same ownership questions and compare their answers in writing. Don't settle for verbal promises. If a vendor hesitates or changes the subject, that's a signal.

• Have a lawyer who knows software contracts review the statement of work or service agreement. A one-hour consultation costs $200 to $400 and will catch gaps that cost thousands later.