AI automation handover checklist and runbook template

The automation is ready to leave the project team. An operations manager now needs to know who checks failed runs, what happens when a connection expires and how work continues if the AI output becomes unreliable. Use this page in a handover meeting with an internal builder or an implementation partner. The checklist and template are available without an email form.

What is an AI automation handover?

An AI automation handover transfers the knowledge, access and responsibility needed to operate a specific workflow. It should cover the business process, connected systems, permitted actions, quality checks, exception handling and recovery procedures. A runbook is the step-by-step document an operator follows to carry out those procedures.

AWS recommends documenting the intended outcome, tools, permissions, error handling and escalation route, then having another team member validate the runbook. For AI workflows, also record which model and prompts are in use and how their outputs are checked.

This is a transfer of operating responsibility. It is separate from deciding whether a pilot deserves a wider rollout, covered in moving an AI pilot into production. The checklist below is Kastling's suggested working template, informed by the linked guidance. Adapt it to the workflow and the responsibilities agreed in your engagement.

What should an AI automation handover include?

Request evidence for each item, a named owner and a clear acceptance status. Mark an item ready only after the receiving team has checked it. Use open for a gap, or not applicable with a reason. A folder full of documents does not establish that the new operator can use them.

Add an evidence link, the verifier's name and the verification date to each row in your own copy. Check access with the receiving person's account. A screen recording made by an administrator can be useful training material, but it cannot demonstrate that an operator has the permissions they need.

AWS operational readiness guidance treats personnel, procedures and support plans as part of readiness. Apply that principle to the handover: an unstaffed exception queue is unfinished operational work even when every integration is functioning.

Who should own the workflow after handover?

Give the business owner authority over outcomes and acceptable exceptions. Give the technical operator responsibility for system health, access and approved changes. Name a backup for each role, along with the support hours and escalation route that actually apply. In a small team, one person may cover several roles, but the responsibilities should still be explicit.

The process lead should know which decisions require human approval and how to handle overdue reviews. IT should know which accounts and connections need maintenance. Finance or the budget owner should know where to find usage charges and who can authorize a spending change.

Microsoft's incident management guidance calls for defined roles, communication paths and procedures from detection through recovery. Translate those into names and working contact routes. Writing "contact support" is insufficient if nobody has established which support service, when it is staffed or what happens outside its coverage.

For payments, contractual commitments or other consequential actions, document the authorized human decision and the information that person receives. The guide to AI agents with human approval explains how to separate preparation from permission to act.

What should you test during the handover meeting?

Ask the receiving operator to demonstrate the procedures with approved test records in a suitable test environment. Agree the expected result before each exercise. Where a production check is necessary, scope it with the relevant owners so it cannot accidentally send a message, change a customer record or trigger a payment.

1. Trace a routine item from its trigger to the final business record. Confirm what counts as complete.
2. Submit an incomplete or ambiguous input. Confirm it reaches the correct reviewer with enough context to decide.
3. Simulate a failed dependency. Check that an alert reaches the person expected to act.
4. Replay an already completed test item. Confirm it cannot create a duplicate consequential action.
5. Pause the workflow while test items are queued. Identify what stops immediately and what can still finish.
6. Continue one item through the documented manual fallback, then reconcile it before resuming automation.
7. Restore the previous approved configuration in the test environment and rerun the relevant acceptance cases.

Record the operator, environment, test input, expected result, observed result and evidence link. If an exercise depends on the builder quietly fixing a missing permission or supplying an undocumented step, update the handover and repeat that exercise.

How do you handle failed runs without duplicate actions?

Check the destination system before retrying an action with an uncertain outcome. A timeout can mean the receiving system completed the request but its response never reached the automation. Replaying the whole workflow could create a second record or send the same message again.

Idempotency means that repeating the same operation has the same effect as performing it once. AWS's reliability guidance describes using a stable request token to identify repeated operations. Ask the builder which steps support this protection, how long duplicate records are retained and what to do where a connected system offers no equivalent guarantee.

The runbook should distinguish pending, completed, failed and uncertain items. Define who investigates an uncertain result, where they check the final record and who may authorize a replay. Put limits on retries and route exhausted attempts to an accountable person.

Illustrative example: A professional services firm uses AI to extract onboarding details from approved documents, prepare a CRM record and queue a welcome email for review. The CRM request times out after the record is created. During handover, the receiving operator finds the existing record using the workflow's reference, confirms that the email remains unsent and resumes only the incomplete step. The exercise checks the recovery procedure; it is not a claim about a delivered Kastling project.

What belongs in the editable runbook template?

Keep one runbook for each workflow, in a place the operators can reach during an incident. Open the editable Markdown runbook and save a working copy, or copy the structure below into your documentation tool. Replace every placeholder with a specific instruction, named owner or evidence link.

For every action, write the location of the control, required permission and expected result. "Check monitoring" is too vague. "Open the workflow's failed-items view, compare unresolved items with the CRM and assign each unmatched item to the operations queue" tells a trained colleague what to do. Your exact view names and instructions will depend on the system.

For AI quality checks, hand over the test set and the scoring criteria as well as the latest result. OpenAI recommends evaluating on changes and extending the evaluation set as new cases appear. Record when to rerun checks after a model, prompt, source-document or integration change. The guide to testing AI before production covers how to prepare those cases.

When should you delay accepting the handover?

Delay acceptance when the receiving team cannot control the workflow or account for the work it has processed. An inaccessible administrator account, an untested pause procedure or a retry that might duplicate a payment is an unresolved operating dependency. Name the gap, its owner and the evidence needed to close it.

Pause and rollback are different. Pausing limits new activity; restoring an earlier version changes configuration or software. Neither automatically undoes an email already sent or a record already changed. Microsoft's safe deployment guidance highlights the complexity of restoring stateful systems. Document how business records will be reconciled separately from restoring the workflow version.

Some gaps may be acceptable for a restricted rollout. For example, a reporting workflow could operate for a limited group while a nonessential dashboard is completed. Record the restriction, interim procedure, accountable owner and review date. Do not turn an unresolved control into a checked box simply because the launch date has arrived.

The receiving owner should finish with an explicit decision: accept for the agreed scope, accept with documented restrictions, or return for correction. Keep that decision with the tested runbook version so future operators can see what was actually accepted.

How does Kastling approach an automation handover?

Kastling scopes integration, training and operating responsibilities as part of its AI Integration & Automation work. The engagement defines the workflow, human approval points and measures of success, then tests development against real business scenarios with the people who will use it.

Agree the handover deliverables in the proposal, including documentation, access, training and acceptance evidence appropriate to the workflow. Ongoing maintenance is optional under a separate agreement; monitoring, incident response and support coverage should be explicitly scoped. Bring the checklist to a discovery conversation to identify which responsibilities your team wants to retain and which it needs help operating.