What should an AI supplier hand over before launch?

An AI handover is complete when the business can operate the agreed workflow, recognise a problem and get the right help. A working demonstration and a folder of documents are not enough on their own.

Agree the handover evidence when you scope the work. This checklist is an operational guide, not advice to ignore contractual payment terms or a substitute for legal or security review.

Ask for evidence against each responsibility

Use four columns in your acceptance record: requirement, evidence location, business owner and status. Mark missing evidence as missing, not assumed. Give unresolved items an owner and a date.

Avoid a single sign-off that bundles unrelated questions together. A workflow can pass its functional tests while its support arrangements remain unclear. Record both facts.

1. A scope somebody can explain

The handover should say what starts the workflow, who uses it, what it produces and what it must not do. Include the points where a person reviews, approves or takes over.

Ask a user to explain the boundary without the supplier prompting them. If a draft-only assistant is being described as an automatic sender, resolve that misunderstanding before release.

2. Business access and recoverable ownership

Identify who owns each account, subscription, integration and administrative role. Confirm the business can reach the agreed administration and support routes. Do not put passwords or API keys into the handover document.

Where a supplier-managed service is part of the agreement, document that dependency honestly. The business may not own the provider's infrastructure or underlying model. What matters is knowing what it controls, what it can export and what happens if the arrangement ends.

Use a safe test to demonstrate access recovery or staff offboarding. Do not remove a real administrator merely to prove the checklist works.

3. The configuration and its limits

Record connected systems, approved data sources, prompts or rules, software dependencies and important service limits. Separate the live configuration from old experiments.

The NCSC's secure-development guidance recommends tracking and protecting AI-related assets and documenting their lifecycle. For a small business, a clear inventory and a known location for the current configuration are useful starting points.

List recurring charges, usage-based costs and who checks them. Do not assume a monthly support fee includes every software licence or future change.

4. Test evidence that matches the delivered version

Request the acceptance criteria, checked examples, results and unresolved failures. The evidence must relate to the configuration being handed over, not a previous demonstration.

Include normal work, incomplete inputs, permission failures, rejected approvals and unavailable dependencies. Confirm that a failed action can be investigated without repeating it accidentally.

Our AI model evaluation guide explains how to keep a repeatable record. Passing those tests supports a decision about the agreed scope; it does not prove that the system is error-free.

5. A manual fallback people have tried

Name the person who can pause the workflow and the person who handles waiting work. Explain what happens to partly processed records and how the team checks which actions already completed.

In a fictional order-intake exercise, the destination system becomes unavailable after a document is read. The team should be able to find the pending record, process it manually if appropriate and prevent a duplicate when service returns.

Run the exercise with synthetic records in a test environment. This is a rehearsal scenario, not a claim about a client outage or a recommendation to interrupt production.

6. Monitoring and support with named owners

State which failures generate an alert, where it goes and who responds. Agree support hours, contact routes, exclusions and the process for requesting a change. Do not turn an informal promise of help into an assumed round-the-clock service.

The NCSC's operation and maintenance guidance covers monitoring and managing updates. Decide which supplier or configuration changes require the business to rerun its acceptance checks.

Keep logs proportionate and access-controlled. A useful diagnostic record does not require an unrestricted archive of every customer's raw information.

7. A practical exit route

Write down what can be exported, the format, any assistance required and the agreed handling of supplier access and retained information. Test a non-sensitive export before it becomes urgent.

Be explicit about what cannot transfer. A proprietary service may have no portable equivalent for part of its configuration. That is a dependency to understand, not a detail to discover on the final day.

Hold a show-me acceptance meeting

Ask the receiving team to find the current instructions, run a synthetic example, explain a rejection, locate an alert and start the documented fallback. Let the supplier observe where people get stuck.

Close each gap with evidence or record the limitation and the person accepting it. A support agreement can be a sensible outcome; the goal is informed ownership, not pretending every business must maintain specialist software alone.

Blue Canvas builds, tests and hands over agreed workflows through AI implementation and automation. Scope the documentation, training and support alongside the build.

Book a free conversation.