AI small business SME buying procurement data ownership

Who owns the code and the data when you hire an AI consultant?

Ask an AI consultant who owns the work and you’ll get a confident yes. You own the code. It’s in the contract.

That answer can be completely true and still leave you stuck. Two years later you want to move the system elsewhere, or bring in a second firm to extend it, or simply find out what it costs to keep running without asking the people who built it. That’s when you learn that owning the code was the easy part, because the code was never the thing holding you in place.

With ordinary software, ownership is mostly one question about one set of files. With an AI system it splits into about eight, and the ones that decide whether you can walk away are rarely the ones anybody raises on the call.

So this post is the list. What you can own, what you probably don’t, the questions that settle each one, and the wording worth arguing about before money moves. If you haven’t shortlisted anyone yet, how to choose an AI consultant is the post that comes first. This is the one you read with a proposal open in front of you.

Paying for it doesn’t mean owning it

Start with the part that catches most owners out.

In the UK, the person who writes the code owns the copyright in it by default. A contractor stays the owner after you’ve paid the invoice in full. Ownership moves to you only when they have signed something saying it does.

Your own staff are a different case. Work an employee produces as part of their job belongs to the business automatically. A consultant, an agency, a freelancer, a dev shop: all contractors, all owners of what they wrote, until there’s a written assignment saying otherwise.

Which makes “we’ll sort the paperwork at the end” the opposite of an administrative detail. It’s the whole question, deferred to the exact point where you have no room to push back: the system is live, your team depends on it, and the person holding the rights knows it.

We build software, we’re not solicitors, and none of this is legal advice. Get the contract read by someone qualified before you sign it. But you don’t need a solicitor to ask the questions below, and asking them on the first call costs you nothing.

Assignment or licence, and why the difference is everything

Two words do very different jobs here.

An assignment transfers ownership to your company. The work is yours. You can change it, move it, or hand it to somebody else without asking.

A licence leaves ownership with them and gives you permission to use it on their terms. Terms that can carry a time limit, a restriction on who else is allowed to touch it, a cap on how you use it, or a monthly fee attached to carrying on at all.

Both get described as “you own it” in a sales conversation. Only one of them is. Find out which word the contract uses. If it’s a licence, read what the licence permits, what breaches it, and what happens when it ends.

One carve-out is reasonable and you should expect it. Anyone who builds for a living has their own libraries and internal tools they reuse on every project, and they won’t be signing those over to you. That’s normal. What matters is that the thing built specifically for you is yours, and that anything reused inside it comes with permission wide enough that you can keep using it, changing it and hosting it yourself indefinitely, with nobody to ask.

If a proposal is quiet on that distinction, it isn’t an oversight. It’s the business model.

The code is the smallest part of what you’re buying

Here’s where AI work differs from a normal software project. The repository is one of eight things, and it’s rarely the one that traps you.

1. The application code. The software your team logs into. The part everyone remembers to ask about.

2. The prompts and the rules. The instructions that tell the system how your business actually works: which customer gets invoiced differently, when to escalate to a person, what never to send without sign-off. This is the real asset. It’s the bit that took weeks to get right and it encodes years of how you operate. We’ve written separately about how that knowledge gets out of your team’s heads, and the short version is that it’s expensive to rebuild from scratch. It also fits in a text file, which means there is no technical reason you shouldn’t have a copy of it. Only a commercial one.

3. The examples that prove it works. Any system doing real work has a set of test cases, say 50 or 100 past jobs with the right answer attached, used to check that a change hasn’t broken anything. Hand-built, slow to assemble, and the only thing standing between you and silent failures after an edit. Firms that treat this as their own property have handed you a car with the brakes locked in the boot.

4. Your data going in, and the output coming out. Covered properly in the next section, because it’s the half that gets skipped.

5. The processed copy of your documents. Most AI systems that answer questions about your business keep a searchable version of your files, contracts, emails and records, converted into a form the model can look things up in. That copy is built from your material, it sits somewhere, and somebody is paying to store it. Ask where it lives and what happens to it when the relationship ends.

6. The accounts. The model provider account, the hosting, the code repository, the domain, the monitoring. If all of that is in their name with their card attached, you don’t have a system, you have a subscription to one. Changing supplier means rebuilding, and they know roughly what rebuilding costs you.

7. Where it runs. A system built to run only inside one firm’s private setup is portable on paper and nowhere else. Ask what moving it would involve. A straight answer sounds like a couple of days of work. A vague one means it has never been tried.

8. The knowledge of how to run it. The operating knowledge, rather than the code itself. How to deploy a change, what breaks and how you’d know, what the monthly bill is made of, what to do when the model provider changes something. Undocumented, this is worth more to them than any clause in the contract.

You can own items 1 to 7 outright and still be unable to move, because nobody wrote down item 8.

Three questions that settle all eight

You don’t need to memorise that list. Take any one of the eight and ask three things:

  1. Can we get it today? Not on request, not at the end. Today, without asking anyone’s permission.
  2. Can we run it on our own accounts? Our model provider account, our hosting, our card, our keys.
  3. Can someone else change it? A different firm, or a developer we hire next year, without needing your sign-off and without it quietly breaking.

Three yeses across all eight items means you own the system. Anything else is a licence with a friendly face, and now you know which parts to negotiate.

Ask the questions in that form, too. “Do we own it?” invites a reassuring answer. “Can we export the prompts and the test cases this week?” invites a real one.

Your data is the half nobody asks about

Code ownership gets argued over. Data handling gets a paragraph of boilerplate nobody reads, and it’s the side with the sharper consequences, because this is where your customers’ information goes.

Four things worth having in writing.

What leaves your business, and where it goes. Which systems the data passes through, which companies are in that chain, and which country it’s processed in. An AI build usually involves at least a model provider and a hosting provider alongside the firm you hired. Those are your subprocessors and you’re entitled to a list.

Whether anything you send trains somebody else’s model. This one varies wildly, including between tiers of the same product. The free or consumer version of a tool and the paid business version of that same tool often have completely different terms on whether your inputs get used for training. Check the plan you’re actually on rather than the headline on the marketing page, and get the answer in the contract rather than from a sales email. If your team is already pasting work into free tools, you have a live version of this problem today and it’s worth reading what your team is probably already doing with company data.

How long it’s kept, and how it gets deleted. Retention periods, and what “deleted” means in practice. Gone from the live system is not the same as gone from backups, logs, or the searchable copy in item 5.

What you get on the way out. Named formats, a named timeframe. “Reasonable assistance with migration” is not a commitment, it’s a hope. Your data in CSV or a standard database export within 10 working days of a written request is a commitment.

Worth saying plainly: this is your obligation, not theirs. You are the one who answers to your customers about how their information was handled, and “our supplier did it” has never been much of a defence.

Who owns what the AI produces?

This question comes up a lot and it deserves an honest answer rather than a confident one.

Copyright in material generated by a machine without meaningful human input is unsettled ground in most of the world, and anyone who gives you a flat answer either hasn’t looked at it or is selling you something. It’s being litigated and legislated in several places at once, and the position may well look different in two years.

The practical move is to stop treating it as the important question. For almost every business, the commercial value doesn’t sit in the copyright of an AI-written draft. It sits in access and control: the prompts and rules that produced it, the record of what went out, and the ability to export all of it. Hold those and the legal question stays academic.

Where it genuinely matters is when AI output is part of your product rather than part of your admin. Published content, customer-facing copy, anything you intend to license to someone else. If that’s you, get it looked at properly, and keep a record of the human contribution at each step.

Red flags in a proposal

Patterns we see, each of which should prompt a direct question:

  • “You own the code” with nothing anywhere about the data. The sentence is doing the work of a clause that isn’t there.
  • A licence described as ownership. Check the word, not the pitch.
  • Everything on their accounts, “for simplicity”. It is simpler. For them.
  • No sight of the work until the end. Assignment on final payment is standard and fair. No access during the build is different, because you can’t tell what exists or whether it’s any good until you’ve paid for all of it.
  • Hosting that only they can run. Ask what moving it would take. Listen for whether anybody has ever tried.
  • No handover in scope. Documentation and a walkthrough treated as an optional extra is a deliberate choice about who holds the knowledge afterwards.
  • No breakdown of the running cost. They should be able to tell you what the system costs to run each month, split between third-party fees and their own charge. If they can’t or won’t, you can’t budget and you can’t compare.
  • “To improve our services” sitting in the data terms, unexplained. Ask exactly what that covers.
  • A “proprietary platform” everything is built on top of. Sometimes genuinely the right tool. Also the most common way a build becomes unmovable, so ask what happens to your system if that platform’s terms or prices change, or if the firm stops trading.

None of these means walking away on its own. Each one means getting a specific answer in writing before you sign, and watching how the answer arrives. A supplier who answers these briskly and in plain language is telling you a lot about the next 12 months.

What a straight answer sounds like

For the avoidance of doubt, here’s our own position, which you’re welcome to hold any supplier to, us included.

You own everything built for you. Written assignment, not a licence. The code sits in your repository from the first week, not at the end, so the work is visible while it’s happening rather than after you’ve paid for it.

It runs on your accounts. Your model provider account, your hosting, your keys, your card. We get access, and you can take that access away without the system stopping.

Your data stays yours, nothing you send goes into training anybody’s model, and the export format is named in the contract rather than promised on a call.

Handover is part of the build, not an upsell. Documentation of how it runs, what it costs, how to change it, and what to watch. The test we hold ourselves to is simple: if you stopped working with us tomorrow, could a competent developer you hired pick it up? When the answer is no, we haven’t finished.

Support afterwards is monthly with no lock-in, and that only works as a promise if leaving is genuinely possible. Founderise runs on its own and takes 12 hours a week out of the business, with 3.5x the margin it started with. MidShift has served more than 20,000 professionals. Neither of those is a system we’re holding hostage, and both would still be running if we vanished.

Price is fixed and agreed in writing before anything starts. No day rates and no scope-creep invoices, which matters here because ownership arguments have a habit of turning into change requests.

The short version

Owning the code is table stakes and it isn’t the question. The question is whether you could leave.

Take the eight things, ask the three questions, and get the answers in writing while you still have a choice of supplier. Assignment, not a licence. Your accounts, not theirs. Your data, named formats, named timeframes. Handover in scope.

Do that at the proposal stage and it’s a 20-minute conversation. Leave it until you want to move and it’s a negotiation you enter from the weakest position you’ll ever hold.

Got a proposal in front of you and want a second pair of eyes?

Send us the ownership and data clauses. We’ll tell you what you’d actually be able to take with you, and we’ll say so even when the answer is that the proposal is fine.

What we build is yours, on a fixed price agreed in writing before anything starts, with a full refund if you don’t approve the prototype.

Book a free call, or read what the AI audit covers first.

Want to see what this looks like for your business?

Book a free architecture audit. We'll map out where the bottlenecks are and what a custom platform could look like.

Book a free audit