An AI system handover checklist verifies that your company can access, operate, test and change the complete system. It also covers how to retire the system after the builder steps away.
The demonstration worked. The AI answered the test question, processed the sample file or completed the workflow. Everyone leaves the call impressed.
Then Monday arrives.
A password expires. The source data changes. The provider releases a new model. An answer looks wrong. A cloud bill jumps. The person who built the system is unavailable.
Who should respond?
A working demonstration proves that one path worked under selected conditions. However, a completed implementation should leave your business able to operate and change the system. It should also support eventual retirement. Therefore, handover requires more than source code and a meeting.
Before accepting an AI implementation, verify seven kinds of ownership.
1. Own the accounts, not just a copy of the code
List every account that the live system depends on:
- source-code repository;
- cloud provider and production subscription;
- model or AI provider;
- database and file storage;
- domain and DNS;
- identity and access management;
- monitoring and alerting;
- automation, email or messaging services;
- third-party data sources and business applications.
For each account, record the legal owner, billing owner, primary administrator and recovery method. A production system should avoid personal logins and agency accounts that the client cannot administer.
However, the company does not need to give every person broad access. It does need an intentional access model and a recoverable route if one administrator leaves.
2. Define what “you own it” actually includes
Teams often use ownership language too loosely.
Your company may own custom code, configuration files, documentation and implementation-specific database designs. That does not mean it owns the cloud platform, model, open-source dependencies, provider software or third-party data. Those remain governed by their respective accounts, terms and licenses.
Ask the implementation partner to separate the deliverables into four groups:
| Asset group | Questions to resolve |
|---|---|
| Custom deliverables | What code, prompts, schemas, tests and documentation are transferred, and under what rights? |
| Company assets | Which data, accounts, domains, credentials and existing systems remain under company control? |
| Licensed dependencies | Which model, library or commercial-product terms govern continued use? |
| Ongoing services | What hosting, support, monitoring or maintenance continues only while a subscription or contract remains active? |
As a result, this makes replacement and budgeting possible. It also prevents a future dispute in which both sides thought “ownership” meant something different.
3. Assign a business owner and an operating owner
One person rarely owns every part of an AI system. At minimum, distinguish these responsibilities:
- Business owner: accountable for the workflow and whether the system remains useful.
- Data owner: approves sources, access, quality rules and retention requirements.
- Technical operator: manages deployments, credentials, monitoring and recovery.
- AI quality owner: maintains representative tests and decides whether output quality is acceptable.
- Implementation partner: performs the specifically contracted build or support responsibilities.
Names matter more than department labels. Therefore, assign a person who understands the decisions attached to the role.
NIST's AI Risk Management Framework Core calls for documented roles, responsibilities and communication lines across AI risk management. The reason is practical. When a live system behaves unexpectedly, the business needs a decision path instead of a debate about ownership.
4. Receive the evidence that defines “working”
Do not treat “the model is good” as evidence of AI quality.
The receiving team should have:
- representative test cases;
- expected or acceptable outcomes;
- the current results and known limitations;
- the model, prompt, retrieval and configuration versions tested;
- an explanation of human review requirements;
- a process for adding new failure cases;
- the threshold and authority for approving a material change.
Also test the deterministic foundation: imports, field validation, duplicate handling, permissions, database writes, notifications and recovery. A high-quality model cannot compensate for missing or stale source data.
The test set does not have to be enormous. However, it must represent the work that matters and remain usable after the system changes.
5. Make the failure procedures executable
Documentation is useful only if another person can follow it.
Create short runbooks for the events the business is likely to face:
- a data delivery is missing;
- an import fails validation;
- a user loses access;
- the model or provider is unavailable;
- output quality drops;
- spending crosses an agreed threshold;
- a credential is exposed or expires;
- a change must be reversed;
- the system must be paused safely.
Each runbook should state the trigger, owner, required access, steps, expected result, escalation route and evidence to retain. Then ask someone other than the original builder to perform the procedure in a safe environment.
AWS's Well-Architected guidance on runbooks recommends an owner, documented permissions, error handling and escalation. It also recommends validation by another team member. Similarly, Microsoft's operational-excellence guidance emphasizes clear responsibilities and repeatable procedures.
6. Make the ongoing bill explainable
The handover should show costs when the system is quiet, when usage is normal and when something goes wrong.
Include:
- model usage and retry costs;
- cloud compute, storage and networking;
- databases, monitoring and backup;
- software and connector subscriptions;
- human review and exception handling;
- maintenance and support;
- minimum commitments or idle capacity;
- which party receives each invoice.
Define alerts and spending controls before launch. Also decide what happens when usage reaches a limit. For example, automatically stopping an important workflow may create a larger problem than the cost overrun.
Measure cost per successful business task where possible, rather than treating the model invoice as the whole operating cost. See AI operating costs: calculate cost per successful task.
7. Decide how the system changes and how it ends
Handover is not the end of change.
The source format may evolve. A provider may deprecate a model. The business may alter approval rules. Users will find cases the original test set missed.
Agree on:
- how changes are requested and prioritized;
- who can approve a production release;
- which tests must pass;
- how rollback works;
- who updates documentation and runbooks;
- how incidents become new tests;
- when cost, quality and usefulness are reviewed;
- how the system and its data can be exported, replaced or retired.
Microsoft's Operational Excellence design principles stress explicit ownership, observability, standardized procedures and safe deployment practices. Those principles apply whether the system runs in Azure, another cloud, on premises or across several providers.
A practical AI system handover checklist and acceptance test
Do not finish with “the documents were delivered.” Instead, finish with evidence that the receiving team can operate the system.
Ask the responsible people to complete this exercise without the original builder driving:
- Identify the production version and its critical dependencies.
- Find the current operating cost and alert thresholds.
- Add or remove a user's access through the approved process.
- Trace one input from its source to the final result.
- Explain what happens to a rejected or failed item.
- Locate the quality tests and run the approved evaluation.
- Respond to a simulated alert using the runbook.
- Show how to roll back a material change.
- Name the person authorized to approve the next release.
- Explain how to pause and eventually retire the system.
Any missing answer becomes a handover item with an owner. The goal is not a perfect binder. It is a business that can continue operating when the implementation team steps away.
Bring handover requirements into the engagement early
The best time to discuss ownership is before the build begins. Put account structure, deliverables, licenses, documentation, evaluation, support and exit requirements into the scope. Waiting until the final week turns design decisions into negotiations.
If you are unsure whether the business can own an assembled system, discuss the implementation with Levi. Bring the current architecture, account list and the failure or transition scenario that concerns you most.
We can review what already works and identify the missing operating pieces. Then we can scope the smallest useful path to a system your business can run.
