What you own at the end, and what it costs when the answer is nothing.
Every AI engagement produces two things: a capability that runs, and an asset that either does or does not transfer to you. Most buyers evaluate only the first, because the first is what gets demonstrated. The second is decided in a paragraph of the agreement that nobody reads closely, and it determines whether the money you spent bought you a durable piece of company infrastructure or a service you will keep renewing indefinitely on terms somebody else revises.
The failure mode is easy to state. An AI system you cannot read, host, modify, or take to another vendor is a rental, and calling the payment a build fee does not change what you are holding. You can tell the difference with one question: if this vendor stopped answering the phone tomorrow, could a competent engineer you hire pick this up and put a change into production? When the answer is no, you do not own the system. You own a dependency, and you will pay for that dependency on a schedule the vendor sets.
The cost of that arrives in three ways, none of them on day one. The first is switching cost, which builds up quietly the way it does with any subscription; the more of your operation runs through the system, the more expensive leaving becomes, and the mechanics of that are the same compounding trap laid out in the real cost of off-the-shelf AI at scale. The second is renewal leverage, or the lack of it. A vendor who knows you cannot leave is negotiating from a different position than one who knows you can, and that shows up in the price long before anybody says the word lock-in out loud.
The third is the one owners underweight most, because it feels unlikely until it happens. Vendors get acquired. They pivot from services to a product. They lose the single engineer who understood your system. They raise prices past what the workflow is worth, or they close. None of those events ask your permission, and none of them care that the system had become load-bearing in your operation. If you hold the repository and the accounts, any of them is an inconvenience you solve by hiring someone else. If you do not, the same event is an outage in a process your business now runs on, and your options are whatever the vendor decides to offer you at the moment you have the least leverage you have ever had.
This is why ownership is a commercial term rather than a technical one. The engineering question of whether the code is any good matters, but it comes second. The first question is whether the thing you paid to have built is an asset on your balance sheet or a rental you have been describing to yourself as an asset, and that question is answered by the contract and the handoff, not by the demo.
What a real handoff contains, and what a thin one leaves out.
Handoff gets promised loosely and delivered unevenly, so it helps to define it as a list of specific artifacts rather than as a principle. A complete handoff has seven parts, and the useful thing about the list is that a vendor's reaction to it tells you most of what you need to know.
The source repository comes first, with its full commit history, transferred into an organization your company controls rather than shared out of theirs. History matters more than owners expect, because a repository without it is a snapshot that hides why every decision was made, and the next engineer has to rediscover all of it. Second is the infrastructure and environment configuration: deployment scripts, container definitions, environment variables, and a written runbook for standing the whole environment up from nothing. Code with no path to production is a document, not a system.
Third is the prompts, and with them the evaluation sets and test cases that define what good output looks like. This is the piece most often skipped and the one that most determines whether you can actually change anything. A prompt is easy to hand over. A prompt without the evals is unsafe to edit, because nobody can tell whether a change improved the system or quietly broke a case that used to work, so a team that receives prompts alone tends to freeze them and never touch them again. Fourth is the data layer: the pipelines, the schemas, the transformation logic, and a plain description of where data enters, where it lands, and what depends on it.
Fifth is documentation written for a new engineer rather than for you. Architecture, known limitations, the operational tasks somebody has to perform, and the things that will break under conditions the original build did not anticipate. Sixth, and the one that is easiest to check and most often wrong, is accounts and credentials. Every cloud resource, API key, model provider account, and third-party subscription should be registered to your company, billed to your payment method, with your team holding owner-level access. Credentials in a vendor's name are the most common quiet dependency in the whole category, and they are trivially fixable at the start of an engagement and painful to fix at the end.
Seventh is the legal right to use all of it: a written statement that you may modify, redeploy, and hand the system to another vendor without their involvement or consent. The other six pieces are worth little without this one, because possession of code you are not licensed to change independently is not ownership. Vendors who intend to hand off will confirm all seven in the agreement without much friction. Vendors who do not will agree warmly in conversation and resist putting any of it in writing, which is itself the answer.
Thin handoffs tend to arrive in three recognizable shapes, and all three can be defended as compliance with a loosely worded agreement. The first is a zip file of the current code with no history, no environment configuration, and no path to deploy it, delivered on the last day against a clause that promised source code would be provided. The second is read access: a repository you can look at inside the vendor's organization, which feels like transparency and confers nothing, because visibility is not control and access granted can be access revoked. The third is documentation written as a sales artifact rather than an engineering one, describing at proposal altitude what the system does while omitting how it is built, what it assumes about your data, and what conditions break it. None of those leaves you able to change anything, which is the only test that matters, and each of them is the predictable result of a contract that named the deliverable without defining it.
When renting is the right call, and why saying so is not a concession.
A memo arguing that every AI system should be owned would be marketing rather than advice, and it would be wrong in a way that costs readers money. There are clear cases where paying for ownership is the worse decision, and they are common enough that most companies will encounter several.
The first is commodity capability. When a task is standardized and every business does it the same way, there is no advantage hiding in a custom version, and owning it means taking on maintenance for a return that does not exist. Transcription, document handling, general drafting, scheduling: these are solved, well served by products, and a company that commissions its own version is paying for an asset that will never differentiate it from anyone. Rent those, and spend the attention elsewhere.
The second is the team with nobody to steward a codebase. This one deserves more honesty than it usually gets from firms that sell builds. A repository nobody at your company can read, run, or change is not an asset; it is a liability wearing an ownership label. If the realistic answer to who will maintain this is nobody, then ownership buys you the theoretical right to change a system you have no practical ability to change, and you will pay for that theory in complexity and in a false sense of security. The right move there is either to rent, or to solve the stewardship question first, which is a real staffing decision worth its own analysis; the tradeoff between hiring that capability and commissioning it is worked through in the comparison of an AI consultant against an in-house hire.
The third is the genuinely undifferentiated workflow. Some processes are necessary but sit nowhere near how you compete, and owning them adds surface area without adding advantage. The fourth is speed. When a decision needs a capability running this week rather than in four months, renting is simply the correct answer, and treating that as a compromise mistakes the goal. Buying time is a real benefit, and shifting maintenance, security, and upgrades onto a vendor is a genuine service with genuine value.
What connects the four is that ownership is worth paying for on workflows specific to how your business wins, and rarely worth paying for on workflows that are not. That is the same axis that decides most of these questions, and it is examined at length in the build versus buy decision for a mid-market company. Ownership follows the differentiation, not the other way around. Where the workflow is close to your edge, renting it means renting your advantage back from somebody else; where it is not, owning it means paying to maintain something that was never going to matter.
There is also a middle position that gets lost when the conversation is framed as own or rent. A vendor can host and operate the system while you hold the rights and a defined path to take possession, usually structured as an escrow arrangement or a handoff trigger: the code, configuration, and credentials are placed somewhere you can reach under named conditions, such as termination, a missed service commitment, or the vendor ceasing to operate. That gives a team with no engineers the operational relief of a managed service without leaving them with nothing if the relationship ends badly. It costs more to negotiate than a plain subscription and it is less clean than outright possession, and for a company that genuinely needs the system run for them but cannot afford to lose it, it is frequently the right shape. The thing that makes it work is specificity: an escrow clause that does not name the trigger conditions and the exact contents of the deposit is a comfort, not a protection.
The questions that settle it before you sign, and the plan that has to follow.
Ownership is decided at the contract stage and confirmed at the handoff, and almost never recovered in between. Six questions do most of the work, and they are worth asking directly, in writing, before a signature.
Who owns the repository and the intellectual property in the delivered work? Get it in the agreement, not in an email thread. What happens on termination, specifically what do we receive, in what format, and within how many days? Vague termination language is where most ownership quietly evaporates. Is there a handoff or escrow clause, and what triggers it? Whose name will the cloud accounts, API keys, and third-party subscriptions be in, and who is the billing contact? Can our team, or a vendor we choose later, modify and redeploy this without your involvement or consent? And what documentation is delivered, written for whom?
How a vendor answers those six matters as much as the answers themselves, and reading that reaction well is part of the broader diligence covered in how to choose an AI consultant. A firm that builds for handoff will treat the questions as routine and answer them in a paragraph. A firm whose model depends on you not leaving will reframe them, reassure you about the relationship, and avoid the page. Notice which one you are talking to. It is also worth understanding how the engagement is priced, because ownership terms and pricing structure are related; a retainer that never ends and a fixed-scope build that transfers an asset are different commercial animals, and the differences are set out in the four common AI pricing models.
Then there is the trap on the other side of a successful handoff, and it catches companies that did everything right at the contract stage. Owning the code is not the same as owning the outcome. A repository with no maintenance plan degrades on a predictable schedule: model providers deprecate versions, dependencies age out, the data drifts away from what the evaluation sets assumed, and the workflow the system was built around changes as the business changes. An unmaintained owned system fails slowly and silently, which is worse than failing loudly, because by the time anyone notices, the trust is gone and so is the usage. That drift is a recurring theme in why mid-market AI rollouts stall in month four, and it is one of the more common findings when diagnosing what to do after a failed AI pilot.
So the handoff has to arrive with a plan attached, and the plan is short. Somebody is named as the owner of the system, internal or contracted. There is a defined cadence for reviewing evaluation results and model updates. There is a budget line for maintenance rather than an assumption that a finished build stays finished. And there is a decision about who does the work: your team, the original vendor under a support arrangement, or someone else entirely, which is a choice you only get to make because the handoff was real. Understanding what that maintenance commitment looks like alongside the original build is part of scoping the whole thing honestly, which is the subject of what a mid-market AI engagement actually costs.
The version of this that works is unglamorous. Decide whether the workflow is core enough to be worth owning. If it is, put the seven handoff artifacts in the contract before you sign, confirm each one at delivery rather than trusting that it happened, and fund the maintenance the same way you fund anything else the business depends on. If it is not core, rent it deliberately and spend the ownership budget where it compounds. What you should not do is pay build prices for a system somebody else holds the keys to, and find out which one you bought on the day you needed to leave.