Who owns the custom AI software you paid somebody to build

The short answer: possession decides it, not the clause

Who owns custom AI software is decided by four things, not by the word ownership in a contract. You own an AI system when four things are true at once. The accounts it runs on are in your company's name. Somebody at your company holds administrator access today, not on request. The workflow logic and the instructions can be exported in a form another supplier could read. And you can pull a complete copy of your data whenever you want without asking anyone.

If any of those is false, what you have is a licence to use something somebody else possesses, however the contract is worded. Possession is what decides the outcome of a disagreement, because the party holding the credentials sets the terms of the conversation, and a clause you would have to enforce through lawyers is not a control, it is a hope.

None of this makes renting wrong. It makes the difference between the two purchases knowable, and every check below can be run before you sign.

The four layers that get confused with each other

Your data is the easiest layer and almost never the one in dispute, which is why you own your data is the least useful sentence in this industry. Every supplier says it, and it commits them to very little.

The second layer is the outputs the system produces: the replies, the drafts, the reports. Usually straightforward, occasionally not, and worth naming explicitly if the outputs have commercial value on their own.

The third layer is where the value actually sits. The workflow logic, the instructions given to the model, the integration code, the configuration, the decision rules and the documentation. That is the part somebody spent weeks on, and that is what the word deliverables in a contract needs to explicitly include, because a definition that says reports and materials does not obviously cover a workflow definition.

The fourth layer is the one nobody thinks about until it exists. Things made out of your material: an index built from your documents, a model tuned on your records, a dataset of corrections your team produced by fixing the system's mistakes over a year. Those are valuable, they were made from your material, and their ownership should be written down before they exist rather than negotiated once they have become worth arguing about.

• Your data, which is rarely in dispute and is not the question
• The outputs, which are usually yours and are worth naming anyway
• The workflow logic, instructions, configuration and documentation
• Anything derived from your data: indexes, tuned models, corrected datasets
• The instance itself, and who holds administrator access to it

Where it lives, and whose name is on the account

Ask where the system physically runs and in whose account. A build sitting inside a supplier's platform tenant, under their login, billed to their card, is a build you are renting no matter what the ownership clause says. The dull details are the whole answer here: whose company name is on the automation platform subscription, whose card it is billed to, whose email is the account owner, and who holds the model provider keys.

There is a factual platform difference worth knowing while the decision is still cheap. n8n can be self-hosted, which means the instance and its credentials can sit inside infrastructure you control. Make and Zapier cannot be. That does not make either choice wrong, and hosted platforms are the right answer for plenty of businesses. It does mean that if keeping credentials inside your own environment matters to you, the decision is made at the start or not at all.

Then check the admin question directly rather than by asking. Can somebody at your company add and remove users today, including removing the supplier? If the answer requires a request, the answer is no.

The honest test of ownership is what still runs on the day the supplier walks out, and who could change it the week after.

The clauses to ask for, and the ones to strike

Most of this is settled by a handful of provisions, and small suppliers are often willing to agree to them because they have never been asked. Read the definition of deliverables first, and widen it until it names workflow definitions, instructions and prompts, integration code, configuration and documentation. Then check that assignment of rights happens on payment for the work rather than on completion of an open ended engagement.

Ask for an export right that operates at any time rather than only on termination. A right you can only exercise when the relationship has already broken down is a right exercised under the worst possible conditions. Ask for transition assistance with a stated number of days, a defined list of what gets handed over, and whether it is chargeable, agreed in advance rather than quoted at the moment you can least argue with it.

Watch for a reuse clause. There is a reasonable version, where generic components the supplier built before you are reused elsewhere and anything specific to your business is not. There is an unreasonable version, which permits your process to be packaged and sold as a product. Ask which one you are signing.

And ask who else touches the data. Every model provider, hosting provider and third party tool in the chain should be named, along with what happens to your data if you leave: returned, deleted, and with what evidence.

• Deliverables defined to include workflow logic, instructions, configuration and documentation
• Rights assigned on payment, not on completion of an open ended engagement
• An export right exercisable at any time, in a machine readable form
• Transition assistance with a stated duration, scope and price, agreed up front
• Reuse limited to generic components, never to your process as a product
• Named sub-processors, and a written answer on deletion and return

The test that settles it in an hour

Contracts describe intentions. Run the test instead, and run it while the relationship is good, because that is when everyone is helpful.

Ask for a full export today. Not a demonstration of the export feature, an actual file. Then have somebody on your side who did not build it open it and describe what one workflow does. If your team cannot follow it, you own something you cannot maintain, which behaves like a dependency regardless of what the paperwork says.

Then ask the ninety day question in plain terms. If we gave notice this afternoon, what would still be running in ninety days, what would we hold, and who would we have to pay for it to keep working? A supplier who has thought about this answers specifically. One who has not tends to answer in reassurance, which is itself the finding: they are describing a relationship they assume will not end.

When renting is the sensible purchase

Ownership costs something, and pretending otherwise would be dishonest. Holding the instance means holding the platform bill, the model usage, the credential hygiene and the responsibility for noticing when something fails quietly. If nobody in your business is going to do any of that, an owned system slowly becomes an unmaintained one, which is worse than a rented one that somebody else is watching.

So renting is the right call when the work is seasonal, when you are still testing whether the thing is worth doing at all, or when you genuinely have nobody to own it and are not going to have anyone this year. What makes that decision sound rather than passive is writing down what would change it. A volume, a date, a moment when the work has become routine enough to bring inside.

The failure is not renting. It is renting for years without ever having decided to, then discovering that the capability you use every day belongs to somebody else and the price of it has just changed.

Running the hour long test against the company publishing this

The test in the last section is only worth anything if a supplier will submit to it, so here is this one's answer. The accounts are registered in your company's name from the first day rather than transferred at the end. The workflow definitions, the prompts and the credentials sit under your logins. The documentation lists every account, key and connection the system depends on, and it is handed over as each piece lands instead of being written when somebody finally asks. That holds on every model except renting the output, which is called renting for precisely that reason.

The section above is right that ownership costs something, and it is fair to name what moves the figure: how many systems are connected, how much volume runs through them, and who is answerable for the platform bill, the model usage and the credential hygiene afterwards. There is no price published on this site because those differ per business. The timing is published instead. The audit takes the first week, one named system is live inside a fortnight, and the handover document exists from that point rather than at the end of the engagement.

One layer the four above do not name is the stop, and it belongs to you regardless of who built the thing. Money, pricing, anything published in your name and any serious complaint wait for human approval, and a workflow meeting a case outside its scope hands it to a person. That is worth writing into the same contract as the ownership clauses. It is also an argument for keeping a build in-house where you can, because your own team is already the person standing on the other side of that stop.

Moiz Khan owns automation architecture at Wobble and decides what gets built and how it runs, which includes where it runs and in whose name. The published work is the evidence that ownership and operation can be separated in practice rather than in a clause: three purpose built ERP systems live at RM Gulistan Engineers in Karachi, and Quillon's delivery line running as a single audited automation of 34 AI nodes.

Common questions

Who owns custom AI software that a vendor builds for you?

Whoever the contract assigns it to, in theory, and in practice whoever holds the accounts and credentials. If the system runs in the supplier's platform tenant under their login, you hold a licence to use something they possess, regardless of the ownership wording. Check the accounts before you check the clause.

What should an ownership clause actually cover?

Deliverables defined to include the workflow logic, the instructions given to the model, integration code, configuration and documentation. A clause covering reports and materials does not obviously cover a workflow definition, and the workflow is the part that took the time and carries the value.

Who owns an index or a tuned model built from our data?

It should be written down before it exists. An index of your documents, a model tuned on your records, or a dataset of corrections your team produced over a year were all made from your material. Ownership of them is easy to agree at the start and contentious once they are valuable.

Can we take the system to another supplier?

Only if you can export it and somebody else can read it. Ask for a real export now rather than a demonstration of the export feature, and have someone on your side who did not build it describe what one workflow does. If they cannot, you have a dependency, whatever the contract says.

Does it matter whether the platform can be self-hosted?

It matters if credentials and customer data need to stay inside your own environment. n8n can be self-hosted, so the instance and its credentials can sit in infrastructure you control. Make and Zapier cannot be. Hosted is the right answer for many businesses, but the choice is hard to reverse later.

Is renting an AI system ever the right choice?

Yes, when the work is seasonal, when you are still testing whether it is worth doing, or when nobody in the business can maintain anything this year. Owning carries real duties. What makes renting sound rather than passive is writing down in advance what would make you stop.