What your team should receive when an AI project ends.

The supplier’s team rolled off on a Friday. On Tuesday the returns policy changed, and the assistant needed one sentence added to its instructions. Nobody on your side knew where the prompt lived, whether changing it would break anything, or how they would find out.

A handover is complete when your team can change a prompt, re-run the evaluation set, roll back a model and explain a decision to an auditor, all without calling the supplier. Anything less is a dependency with a nicer name.

What does handed over mean for an AI system?

For ordinary software, handover means code, documentation and credentials. An AI system adds parts that change its behavior without any code change: prompts, retrieval sources and indexes, model versions the provider may update, thresholds and routing rules. Your team has to be able to operate all of them, and to prove it before the supplier leaves. That is why handover is a step of its own in how we work: it ends with a practice your team runs, not a folder of documents.

Which documents and assets should you receive?

1. Code and infrastructure definitions, in your repositories, building from scratch in your environment. If it only builds on the supplier’s machines, you don’t own it.
2. Prompts with version history, each version linked to its evaluation results. Prompts are behavior; the history shows what changed and why.
3. The evaluation set and its results, including the held-out part, the scoring rules and results by case type at acceptance. It is how you will know whether any future change helped.
4. A data-flow and access map: sources, what goes to which model, where it is processed, what is stored and who can see it. Your data protection officer and your auditors will ask.
5. The runbook: what to do when quality drops, a source fails, costs spike or someone reports a harmful answer, how to roll back and who to call. Bad days don’t wait for the supplier.
6. A model and vendor list: each model and version, provider, processing region, the terms that apply and the fallback option. You need it the day a provider changes or retires a model.
7. A cost dashboard, with cost per task, the ceiling and the alerts. Spend drifts.
8. A decision log: why this model, why this approval point, what was tried and rejected. Without it, someone eventually reverses a decision whose reason nobody remembers.

Which skills should your team have by the end?

At least two named people, so the system survives a holiday, should be able to:

• change a prompt safely: edit, evaluate, compare by case type, release and roll back;
• read the monitoring and act on an alert, starting with a rise in overrides;
• refresh a source or rebuild the index when documents change;
• compare a candidate model on the evaluation set before switching;
• trace one decision from input to approval in the logs.

These are learned by doing them during the project, not in a training session at the end.

Which accounts, keys and access rights must move?

Cloud subscriptions, model provider accounts and API keys belong in your organization’s name, not the supplier’s. Repositories, build pipelines, monitoring and alert routing move to your teams, and alerts go to your people. Every key the supplier has seen gets rotated. The system’s own service accounts keep least privilege, and the supplier’s access is removed, or reduced to what a written support agreement needs.

A system that runs on the supplier’s API key is still the supplier’s system.

How do you test that the handover worked?

With a drill, before the final milestone is signed. An illustrative example: an invoice-drafting system at handover. The supplier’s engineers watch and say nothing, while your team does four things:

1. Change a prompt. A new rule: credit notes from one supplier always go to review. They edit the prompt in the repository and run the evaluation set.
2. Read the results. The rule works, but drafts for invoices with several purchase orders got worse. They spot it in the results by case type.
3. Roll back. They restore the previous prompt version, confirm in monitoring which version is live and log the decision.
4. Explain a decision. They pull one past invoice and show the input, the sources, the model and prompt versions, the output and who approved it.

If your team had to ask the supplier anything, the handover isn’t finished. Write down what was missing, fix it and run the drill again.

What should be written down about support afterwards?

Ownership first. Who owns the code, prompts, evaluation sets and documentation should already be in the contract, with licenses for anything the supplier keeps; ask counsel to check the wording. In our custom AI software work the default is that you own what was created for you.

Then the support model, which ranges from running it yourself with the runbook, through an agreement for incidents only, to a monthly partnership covering monitoring, regression checks and improvements. Whichever you choose, write down who is on call for what, who may change models and prompts and how changes are approved, how costs are reported, when the system is reviewed and how the arrangement ends. The notes on support agreements and incident plans go deeper.

Test the handover before you pay

Put the drill in the contract as an acceptance step, and schedule it before the last payment. It puts the eighth go-live condition, runbook, documentation and training, to a practical test. If you would rather not run the system alone, AI reliability through an Embedded AI Partnership covers monitoring, regression checks and improvements alongside your owners.