What to own when you build an AI product with a vendor

When you hire a team to build an AI product for your business, you're making a bet on two things: that they can build it, and that you'll keep control of it. The second part matters more than most founders realise.

Three assets live inside every AI product. Understanding what you own—and what you should own—is the difference between a tool you control and one that controls you.

The code

Code is the set of instructions that makes your AI product work. It's the skeleton. When a vendor builds a tool for you, ask whether you own the code or whether you're renting access to it.

Owning the code means you can:

• Read it and understand how it works
• Hire a different team to modify it later
• Move it to a different cloud provider if costs rise
• Keep it running even if the vendor closes or stops supporting it

Not owning the code means the vendor can:

• Raise prices without warning
• Shut off access if you miss a payment
• Change how it works without your input
• Delete it if the business relationship sours

A dental clinic in Kelowna hired a small agency to build a tool that flags overdue patient records. The code lives on the agency's servers. When the clinic wanted to add a feature six months later, the agency quoted $8,000 and a three-week wait. If the clinic owned the code, a different developer could do it in days for half the cost.

Get this in writing: you should own the code, or have a right to a copy of it that you can run yourself.

The data

Data is the information your AI product learns from. It's the fuel. This is where most founders get nervous, and they should.

Your data is yours. Full stop. If you collected it, you own it. The vendor should never claim ownership, and the contract should say so explicitly.

Why this matters: a property manager in Surrey built a tool with a vendor that learns from five years of tenant applications. That data—names, credit scores, rental history—is sensitive and valuable. If the vendor claimed ownership or had the right to use it for other clients, the Surrey manager has a liability and a negotiating problem.

More practically, you need to know:

• Where does your data live (which cloud, which server, which country)
• Can you download a copy of it anytime
• Can the vendor use it to train tools for other clients
• What happens to it when the contract ends

A distributor in Calgary feeds sales data into an AI tool that predicts inventory needs. That data is competitive. The contract should say the vendor can't touch it except to make the tool work, and that the Calgary team gets a full backup whenever they ask.

The trained model

The trained model is the AI brain that learned from your data. It's the engine. This is the trickiest one to negotiate because most vendors don't want to give it up.

Here's the real situation: you pay a vendor to build a tool. They feed your data into an AI system, and the system learns patterns from it. That learning—the model—is valuable. The vendor may want to keep it, or keep the only copy of it, so you stay dependent on them.

If you own the model, you can:

• Use it with a different vendor later
• Understand what it learned from your data
• Know it won't be used to train tools for your competitors

If you don't own it, the vendor can:

• Hold it hostage if you want to leave
• Use it to train better tools for your competitors
• Charge more knowing you're stuck

A 12-person software company in Gastown built an AI tool that reads customer support emails and sorts them by urgency. The vendor trained a custom model on six months of real emails. The Gastown team asked for a copy of the trained model. The vendor said no—it's proprietary. Now the Gastown team is nervous: if the vendor raises prices or shuts down, they lose the tool and can't easily rebuild it.

Negotiate for model ownership or a right to download it. If the vendor won't budge, at least get a commitment in writing that they'll hand it over if the contract ends.

The contract language

None of this matters if it's not in the contract. When you're talking to a vendor, ask these three questions:

• Do I own the code, or do I have the right to get a copy of it
• Do I own the data, and can I download it anytime
• Do I own the trained model, or will you give it to me if we stop working together

If the answer to any of these is no or unclear, dig deeper. A vendor who won't commit to these terms is betting they can lock you in. They might be right, but you should know the bet you're making.

The best time to negotiate this is before you sign and before they start building. Once the tool is live and your team relies on it, your leverage is gone.

Where to start

• Draft a list of three questions about code, data, and model ownership, and send it to any vendor you're considering. See how quickly and clearly they answer. Evasion is a signal.
• Ask your lawyer to review the vendor's contract and flag any language about who owns what. This costs a few hundred dollars and saves tens of thousands later.
• If you're already working with a vendor, ask for these commitments in writing now. It's an awkward conversation, but it's better than discovering the problem when you want to leave.