At a glance
- A clean AI system handover is a set of concrete deliverables and access transfers, not a knowledge-transfer conversation.
- The checklist below covers what to receive, what good looks like for each item, who on your team should hold it, and how to verify it before sign-off.
- Access, credentials, and monitoring alerts move to accounts your own team controls before handover is confirmed, not after.
- Plan checks at 30, 60, and 90 days so a thin runbook or an unowned credential surfaces before it causes an outage.
Ownership is a set of artifacts
A handover meeting is not a handover. Sitting through a walkthrough, nodding along to an architecture diagram, and thanking the team that built the system doesn't transfer ownership of it; it transfers a memory of a conversation. Ownership exists only in things your team can hold, open, run, and check without the builder in the room: documents, credentials, a runbook, an evaluation set, and a monitoring dashboard your own operators are already watching.
This checklist is written for the process owner and IT operations team receiving a system that has already been designed and built (see AI agent implementation for what precedes it). It isn't a description of any vendor's handover service; it's what you use to decide whether to sign off on one. Who owns the AI after the consultant leaves comes down to who holds these artifacts.
The handover checklist
The deliverables below make up a complete handover. Each has a plain test for whether it's actually done: not delivered, but usable by your team on its own, with the builder out of the room. To record an owner, status, and evidence link for each item as you go, use the handover checklist template (CSV).
| Deliverable | What good looks like | Who receives it | How to verify before sign-off |
|---|---|---|---|
| Architecture and data-flow document | Every system the agent reads from and writes to, the data moving between them, and where a human decision sits in the flow. | IT/architecture owner and the maintainer | Someone who wasn't on the build team traces one real case through it without asking the builder a question. |
| Runbook with alert responses | One entry per alert type: the likely cause, diagnostic steps, and who to escalate to. | On-call operator / IT operations | Pick three real alerts from the last month; the runbook tells the operator what to do for each, unaided. |
| Evaluation set and how to re-run it | A labeled set of representative cases, plus the exact steps to score a new prompt or model version against it. | The maintainer who will change prompts or models | The maintainer runs it alone and gets the same score the builder reported. |
| Prompt/config inventory with versions | Every prompt, rule, threshold, and pinned model version in production, with a version number and the date and reason it last changed. | Maintainer | What's listed matches what's actually deployed, checked live, not from memory. |
| Access and credential inventory | Every account, API key, and service credential the system uses, and who currently holds it. | IT / security | Keys and accounts are already re-issued under your organization's own admin before sign-off, not the builder's. |
| Monitoring dashboards | You can name every dashboard that exists and where it lives, who has view and edit access to each one, and the documented threshold that triggers every alert. | Process owner and operations | Trigger or simulate an alert and confirm it reaches the named person on your team who owns that alert, not the builder. |
| Incident and rollback procedure | The exact steps to revert to the last known-good version, and who is authorized to call it. | Maintainer and process owner | Run a rollback in a test or staging environment; it works without the builder's help. |
| Cost report | Model usage, hosting, and any per-transaction cost, broken out clearly enough to see it change. | Process owner / finance | The report reconciles against an actual invoice from the same period. |
| Training for operators and maintainers | Hands-on sessions on the real system with real or realistic cases, not a slide deck. | Operators and maintainers | An operator handles a live case and a maintainer changes a rule and reruns the evaluation set while the builder only watches. |
| Known limitations | A written list of what the system doesn't do well, and the situations it's known to get wrong. | Process owner | It matches what your own team has actually seen in testing, not a generic disclaimer. |
| Change process | Who approves a change, how it's tested before release, and how it's rolled back if it fails. | Maintainer and process owner | The team can describe what happens the next time a rule needs to change, without prompting. |
Verifying each deliverable before sign-off
Every deliverable in that table has the same failure mode: it reads well and does nothing under pressure. NIST's AI Risk Management Framework lists, as one outcome for the AI model itself, that it is "explained, validated, and documented"[1]. We'd hold every deliverable in your handover to that same bar: a document nobody has tested still falls short of it, whatever it says on the page.
Monitoring gets the same test. The framework expects that "the functionality and behavior of the AI system and its components – as identified in the map function – are monitored when in production"[1], not that a dashboard exists somewhere nobody watches. Before sign-off, trigger or simulate one alert and confirm it reaches the named person on your own team, not the builder's inbox.
That monitoring also covers specific mechanisms: "appeal and override, decommissioning, incident response, recovery, and change management"[1]. Incident response and recovery are your incident and rollback procedure; change management is your change process. Decommissioning is different and larger: NIST describes it as "decommissioning and phasing out AI systems safely"[1] — retiring the system itself, not one model. A provider retiring a model is a smaller, component-level change for your change process and evaluation set to absorb. Watch for three imposters that look like sign-off but aren't:
- A document nobody but the builder has ever opened.
- A monitoring dashboard whose alerts have no name attached to them.
- An evaluation set the team has seen demonstrated, but never actually run themselves.
Training that sticks
A training session that's really a slide deck doesn't transfer a skill; a training session built around the real system and real cases does. The test for training is the same as for every other deliverable: can the person actually do the thing themselves, unprompted.
Google's site reliability engineers build runbooks with the same discipline: on-call "playbooks contain high-level instructions on how to respond to automated alerts"[2], and the practice exists because "these guides reduce stress, the mean time to repair (MTTR), and the risk of human error"[2]. A runbook operators haven't actually used against a live alert is a document, not a guide.
One Google SRE team, ramping up a new on-call rotation, trained against failure directly rather than just reading about it: its engineers drilled against past incidents, "where they role-played recent incidents to practice debugging production problems"[2]. Ask your operators and maintainers to do the same with your own system's past incidents, or synthetic ones built from the runbook, before you sign off on their training.
The first 90 days after handover
- Weeks 1-2
Your team runs the system day to day, on its own; every runbook or documentation gap gets logged and fixed immediately, not noted for later.
- Around day 30
Compare actual model and hosting cost against the handover's cost report, and recalibrate the estimate if usage looks different from the pilot.
- Around day 60
Run a live incident or rollback drill and check the result against the written incident and rollback procedure.
- Around day 90
Re-run the evaluation set with the maintainer driving, not the builder, and confirm training has held up under real conditions.
The first real incident after handover is a better test of the runbook than anything in the pilot, because nobody staged it. Write it up the way Google's site reliability engineers write a postmortem: "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring"[3]. Then check the runbook against what actually happened during the incident, and update it where it fell short.
Make that review blameless on purpose: "blameless postmortems are a tenet of SRE culture"[3], because an operator who's afraid of being blamed for the system's failures stops reporting the gaps in the handover, and the gaps don't go away; they just stop being visible until the next incident.
Red flags in a handover
- The only person who can explain what an alert means is the person who's leaving.
- Credentials still sit in the builder's personal or company accounts, with a promise to transfer them "later."
- Prompts or configuration values change in production with no record of what changed, when, or why.
- Model or API usage is still billed to the builder's account, a quiet form of AI vendor lock-in: you can't change providers or builders without their help.
- No cost report has ever been checked against an actual invoice from the same period.
- "We'll fix that in the runbook later" is a running joke, not a task with an owner and a date.
When this checklist doesn't fit
This checklist is for a system that's already been designed, built, and is ready to hand over. It isn't a tool for negotiating what a handover contract should promise, and it isn't for a system still in pilot, where the open question is whether to build at all rather than how to receive it.
Frequently asked questions
What should an AI handover include?
At minimum: an architecture and data-flow document, a runbook with alert responses, an evaluation set and how to re-run it, a prompt and configuration inventory with versions, an access and credential inventory, monitoring dashboards, an incident and rollback procedure, a cost report, operator and maintainer training, known limitations, and a change process, each verified before sign-off.
Who should own API keys and model accounts?
Your IT or security team, under named accounts your organization controls, not the builder's personal or company accounts. Part of sign-off is confirming keys and credentials are already re-issued under your own admin, with a documented inventory of every account, key, and who currently holds it.
What runbooks does an agent need?
One runbook entry per alert type the system can raise: the likely cause, diagnostic steps, and who to escalate to if the operator can't resolve it. Verify it against alerts that actually fired in the last month, not hypothetical ones, and confirm an operator can follow it without asking the builder.
How do you hand over prompts and eval sets?
Hand over a version-dated inventory of every prompt, rule, and threshold in production, plus the labeled evaluation set and the exact steps to re-run it. Verification means the maintainer runs the evaluation set alone, on a new prompt or model version, and gets a result they trust without the builder present.
What happens when the model is retired?
When a provider retires a model version, the system has to move to a replacement before the retirement date, so treat it as a planned change. At handover, confirm the model version is pinned in your prompt/config inventory, your own account receives deprecation notices, and a named evaluation set qualifies the replacement.
Related reading
- If you want a structured handover built into the engagement itself, rather than assessed after the fact, see AI operations and enablement.
- Deciding which of these deliverables should still route through a person, and which shouldn't, is covered in human-in-the-loop AI governance.
- If you're still choosing a vendor, these questions to ask an AI consulting firm include several about ownership and handover terms.
- To track sign-off against evidence as you go, download the AI system handover checklist template, a four-area CSV covering runbook, training, recovery, and access.
Sources
- National Institute of Standards and Technology, AI RMF Core, Section 5 (Govern, Measure, Manage functions) — AI Risk Management Framework 1.0 (2023) (accessed 2026-09-29)
- Google, "On-Call" — The Site Reliability Workbook (accessed 2026-09-29)
- Google, "Postmortem Culture: Learning from Failure" — Site Reliability Engineering, Chapter 15 (accessed 2026-09-29)
More in Agent governance
Build vs. Buy AI E-Commerce Back Office Automation: Point Tools vs. an AI Implementation Partner
Build vs buy AI e-commerce back office automation: a six-factor decision table comparing packaged tools with an AI-agent layer, plus how to scope one workflow.
Ecommerce OperationsBuild vs. Buy AI for the Energy and Utilities Back Office: AI Agents vs. Entrenched Land, JIB and Billing Software
Build vs buy AI for the energy and utilities back office: a five-factor decision table comparing land, JIB and billing software with an AI-agent layer.
Utilities and Energy CompaniesAI Agent Approval Gates for Finance: A Role and Action Matrix
AI agent approval gates for finance: which actions an agent may do, suggest, or never touch, who approves each one, and what evidence to keep.