What should a complete AI system handover include?

Six things: the code in your repositories, the prompts documented and versioned, the infrastructure in your cloud accounts, the evals that prove the system works, every credential and API key under your control, and runbooks for operating and changing the system without the vendor.

Is owning the code enough?

No. An AI system whose prompts are undocumented, whose evals do not exist, or whose infrastructure lives in the vendor’s accounts is not owned, whatever the IP clause says. You hold the source of a system you cannot safely run or change.

Why do evals belong in a handover?

Evals are the system’s proof of correct behavior. Without them, every future change (a model update, a prompt tweak, a provider deprecation) is a blind edit to a business-critical system. Handover without evals transfers the system but keeps the confidence.

When should handover terms be agreed?

Before the engagement starts, in writing. A vendor who resists specifying the handover before the build is telling you what their business model is.

The ownership handover: what you should hold when the vendor leaves

The short answer

A complete AI system handover moves six things into the client's hands: code, prompts, infrastructure, evals, credentials, and runbooks. Anything less transfers a dependency, not an asset. The standard is checkable in a contract before the engagement starts, and vendors who resist it are disclosing their business model.

Every services vendor now promises you will "own everything." The promise is cheap because almost nobody specifies what everything means for an AI system. Handover is how our engagements end by design, so here is the specification we think the industry owes you.

The dependency nobody prices

Software engagements have always ended with a code transfer and a handshake. AI systems quietly broke that tradition, because the code is no longer where most of the system lives. The behavior lives in prompts. The correctness lives in evals. The viability lives in infrastructure choices and model dependencies that expire on someone else's schedule, as our own June incident demonstrated on us. A vendor can honor the IP clause to the letter, hand you a repository, and still leave you unable to run, change, or trust the system you paid for.

The market is catching up in language, if not yet in practice. When AWS launched its forward-deployed organization, it marketed leaving customers self-sufficient as a headline feature. Self-sufficiency is the correct goal. It needs a checklist.

You can hold the source code of a system you do not own in any sense that matters.

The six-part standard

The ownership handover · six transfers, each checkable, none optional

01Code in your repositories. Not a zip file, not access to theirs: your organization owns the repos, with history, from the start of the engagement or transferred whole at the end.
02Prompts documented and versioned. Every system prompt and template, with intent notes: what each constraint is for, what broke before it existed. Prompts are behavior; undocumented behavior is technical debt.
03Infrastructure in your cloud. The services run in your accounts, deployable from your repos. If the vendor vanished tonight, the system keeps running and you can redeploy it tomorrow.
04Evals transferred with the system. The golden datasets, the test conversations, the thresholds. Proof the system works, and the safety net for every future change.
05Credentials and keys under your control. Model API keys, database credentials, third-party integrations: issued under your accounts, rotatable by you, with the vendor’s access revocable in one action.
06Runbooks for operating and changing it. What to monitor, what alarms mean, how to swap models when a provider deprecates one, how to add a feature. The document that makes keeping the vendor a choice.

Why each part matters

Each missing part has a specific failure it invites. Missing prompt documentation means the next engineer edits behavior blind. Missing evals means model updates become gambles; evals for business buyers covers what they are and what to demand. Missing infrastructure control means your workflow has a landlord. Missing runbooks means the first incident happens at the vendor's pace, not yours. And missing credentials means all of the above, permanently. These are not hypotheticals; they are the anatomy of every "we cannot leave our agency" story you have heard, and the quiet mechanism behind the rented-not-owned failure mode.

How to demand it

–Put the six parts in the contract before the build. Name them individually. "Client owns all IP" does not cover evals that were never written.
–Make the last milestone a cold-start test. Someone on your side deploys the system from your repos, using your credentials and the runbook, with the vendor watching and not touching.
–Treat resistance as disclosure. A vendor who cannot hand over prompts "for proprietary reasons" or wants hosting to stay in their accounts is describing their retention strategy. It is one of the plainest partner-selection signals you will get.

Handover complete enough that you never need us again is how we define finished. Choosing to keep us around is the only lock-in we believe in.