The last weeks of an external build
Many organisations commission their first AI system from outside: an agency, a software vendor’s professional-services team, or a contractor. The system works, the contract is ending, and the internal team is told it now owns it. Then the first incident arrives, or the first request to change how the assistant answers, and it becomes clear how much of the system lived in the outgoing team’s heads and accounts.
Handover is often treated as a documentation task at the end of a contract. For AI systems it is an operational one. Your team needs to be able to deploy, roll back, change behaviour safely and recognise when quality has slipped. This engagement makes that transfer explicit and tests it.
What the work involves
I work as an independent party between the outgoing team and your engineers. The work covers five areas:
- Code and infrastructure. Repositories, build and deployment pipelines, environments and infrastructure definitions, all owned by your organisation, with the deployment process run by your engineers.
- Model dependencies. Provider accounts, API keys, model versions in use, data-retention and training settings, rate limits and billing, transferred and documented.
- Behaviour assets. Prompts and their version history, tool definitions, evaluation sets, quality thresholds and the reasoning behind them. These are the assets most often lost in AI handovers.
- Data and indexes. Data sources, pipelines, vector indexes and how to rebuild them, and where personal data flows.
- Operations. Monitoring, alerts, known failure modes, cost patterns and the incident procedures that have actually been used.
Runbooks are written by doing: each procedure is performed while it is written, by someone other than the original author. That is the only reliable way to find the missing step. The same principle runs through my published account of forward deployment engineering: a system is not delivered until the people who own it can run it.
The signature deliverable
You receive an operational acceptance checklist, runbooks, access transfer and teach-back exercise. Illustrative example of a checklist extract:
| Item | Evidence required | Status |
|---|---|---|
| Model provider account owned by client, outgoing users removed | Account admin screenshot; access review | Done |
| Client engineer deploys a change to production unaided | Teach-back record, deployment log | Done |
| Prompt change made and evaluated before release | Pull request with evaluation result attached | Done |
| Vector index rebuilt from source in staging | Rebuild log; retrieval evaluation within tolerance | Gap: rebuild script missing a source; fixed, re-test scheduled |
| Simulated incident: provider outage | Fallback engaged; runbook followed; time to recover recorded | Done |
| Cost alert thresholds owned by client | Alert configuration; named recipient | Done |
Illustrative example. Not taken from a client engagement.
How acceptance is judged
Your engineering manager owns the checklist and signs it off item by item. An item is complete only when its evidence exists, usually a record of your engineer doing the task. The handover is accepted when every item is complete or explicitly accepted as a known gap with an owner and a date.
Ownership afterwards
From sign-off, your team owns the system outright: the code, accounts, credentials, runbooks and evaluation suite. The outgoing team’s access is removed. If your team wants a safety net for the first months, maintaining production AI workflows offers a bounded, capacity-limited arrangement.
When to choose something else
If the system is not yet working, see rescue an AI application that cannot ship. If you need engineering cover until a permanent hire starts, see bridge AI engineering until a permanent hire. If you are hiring a contractor now and want to avoid this problem later, the contract AI engineer route builds handover in from the start.