Who Owns Your AI System After the Consultants Leave

The IP clause is necessary. It is nowhere near sufficient.

You own an AI system when you can change it without the people who built it. That is the working test, and the intellectual property clause in your contract does not deliver it on its own. A clause assigns rights. It does not produce a repository you can open, an environment you can deploy to, accounts in your own name, documentation somebody can read, or a person inside your company who has read it. Companies usually discover the gap seven or eight months after launch, when an upstream API changes or a model version is retired and the only honest answer to “can we fix this ourselves” is no. Who owns your AI system is settled by a checklist of artefacts rather than by a paragraph in a contract, and the checklist has to be enforced at the handover meeting rather than negotiated afterwards.

AI system ownership, and the four places it leaks

Start with what should be assigned to you on payment, in one clause rather than scattered across three: the source code, the prompts, any fine-tuned weights, the evaluation set, the infrastructure configuration, and anything derived from your own data. Prompts and evaluation sets are the two that get left out most often, and they are the two that took the longest to get right. A supplier who assigns the code but keeps the prompts has kept the part that encodes what your business actually wanted.

Even with a clean clause, ownership leaks in four practical ways, and none of them is a contract problem.

• The system runs in the supplier’s cloud account. You own the code and they own the environment it lives in, which means the exit is a migration project you have not budgeted. Insist that production runs in a subscription billed to you from day one, even while they operate it.
• The model-provider accounts and API keys are theirs. Usage history, rate limits, spending caps and any negotiated terms sit with the supplier. When the relationship ends you get a key rotation and a surprise invoice profile.
• The repository lives in their organisation. A zip file emailed at the end is not a handover: you lose the commit history, which is the only record of why the odd-looking decisions were made.
• Something licensed sits underneath. A no-code platform, a proprietary framework, a per-seat product doing the actual work. No clause can assign what the supplier does not own, and this is the leak that turns an owned system into a rented one without anybody lying to you.

Ask which of those four apply before signing. A supplier who answers all four plainly is describing the ownership position accurately, which is worth more than one who says “yes, you own everything” and means it loosely. Reliability over the following two years is predicted by exactly this kind of operational answer rather than by the pitch, which is the argument we made in how to find a reliable provider for custom AI software.

What a real AI project handover contains

Five artefacts, plus one person. Ask for the list in writing at proposal stage, not at the end, because a supplier who intends to produce them prices them in and a supplier who does not will quote lower and hand you a login.

• A repository in your organisation, with its history. Not a copy. The account is yours, the supplier has access rather than the other way round, and the commits are intact.
• Infrastructure written as configuration. The environment rebuilt from a file rather than from somebody’s memory of which settings they clicked eighteen months ago. This is the artefact that decides whether a third party could ever take the system over.
• An architecture note a new engineer reads in an hour. What the system does, how the pieces connect, and, most usefully, what was considered and rejected. The rejected options are what stop your next developer rediscovering a dead end at your expense.
• The evaluation set and instructions for running it. Fifty to two hundred real examples with known correct answers. This is how anyone later proves the system still works, and without it quality arguments become arguments about impressions.
• A runbook for the six most likely failures. Symptom, first action, who to escalate to, and what the acceptable degraded behaviour is. Six is a realistic number. A hundred-page operations manual nobody opens is worse than six pages somebody has read.

Then the person. One named individual inside your company who has read all five and can find their way around the repository. They do not need to have written it and they do not need to be a specialist in AI. They need enough engineering literacy to change a prompt, read a log and open a support ticket with real detail. Without them the five artefacts are a filing cabinet. The WA Center platform runs across four countries with several distinct user roles, and it was structured on this assumption from the first week: somebody on the client side would own it, so the documentation was written for that person rather than for us. Our other case studies were built the same way, and the capabilities page sets out what running one involves.

What degrades, and how quickly

An AI system is not a static asset. Four things move underneath it and every one of them arrives without an announcement addressed to you.

Model deprecation. Providers retire model versions, usually with a few months of notice sent to the account holder, which is one reason the accounts should be yours. Your prompts were tuned against a specific version. Moving to the next one is rarely dramatic and it is never zero: budget a few days of work and a re-run of the evaluation set each time.

Input drift. A supplier changes an invoice template. A team starts using a free-text field for something new. The extraction that was 94 per cent accurate at launch is quietly 80 per cent by spring, and nobody notices because nobody is measuring. This is the most common way a working system loses the trust it earned, and it is entirely preventable with a quarterly evaluation run.

Upstream changes. The CRM you integrated with ships a new API version and sunsets the old one. This has nothing to do with AI and it will consume more of your maintenance budget than the model does.

People. The person who understood the system takes another job. If the five artefacts exist this is an inconvenience. If they do not, it is the moment your owned system becomes a black box that nobody wants to touch, and the practical consequence is that the next team rebuilds rather than inherits.

Support models, and what AI maintenance actually costs

Plan on 15 to 25 per cent of the build cost per year to keep a system healthy, the same figure we use when quoting, and which sits behind the numbers in what a custom AI build costs. That covers monitoring, the evaluation re-runs, model and API migrations, and small changes. It does not cover new features. Three arrangements deliver it, and the right one depends on what you already have internally rather than on what a supplier prefers to sell.

Internal ownership. Cheapest in cash and the most demanding in attention. It works when you already employ someone technical and the system is close to what they do anyway. It fails quietly when that person is nominated rather than resourced, because AI maintenance loses every scheduling contest against whatever is on fire this week.

A retainer with the people who built it. The fastest response and the most context, at the price of a continuing dependency. Make it a monthly fee with a stated response time and a stated included-hours figure, not an open-ended arrangement, and make sure the handover artefacts exist anyway. A retainer you could leave is a healthier retainer.

A third party takes it over. Only possible if the handover was real, which is the practical argument for enforcing the five artefacts even when you have no intention of changing supplier. Holding that option is what keeps the relationship honest, and it costs you nothing.

Two cases where you should not take ownership

The system is generic and a product already exists. Owning a scheduling assistant or a transcription pipeline means owning maintenance of something a vendor maintains for thousands of customers at a fraction of your cost. Ownership is worth paying for when the process is specific to you. When it is not, ownership is a liability with a nice name.

You have nobody and you are not going to hire. A handed-over system with no internal owner degrades faster than a managed one, because nobody is watching and nobody has the standing to raise it. The honest answer is to buy the outcome as a service and accept that you are renting. We hand systems over by default and there are clients who should not accept the handover, which is a conversation worth having at proposal stage rather than at the end.