The demonstration works. The invoice arrives. Then the person who built it goes on holiday.
That is an excellent time to discover whether you bought a working service or temporary access to somebody else’s competence. Preferably, you discover it before the invoice.
The short answer: accept an AI implementation against agreed tests and operational handover evidence. Check normal work, difficult cases, access restrictions, costs and recovery. Your own team should demonstrate that it can run the result.
Agree acceptance before development
Write the acceptance criteria alongside the scope. Define the workflow, supported inputs, expected outputs and prohibited actions. Identify the person who can accept each area. The project sponsor may approve the spend, but the system owner should inspect access and the operational owner should assess usefulness.
Separate a successful prototype from a production-ready service. A prototype may use sanitised data and manual supervision. Production may require monitoring, support coverage, stronger access controls and an incident process. Label the milestone honestly.
The NIST AI RMF is a voluntary risk-management reference. The checklist here is a practical acceptance aid; passing it does not establish regulatory compliance.
Test more than the happy path
| Test family | Example | Evidence to retain |
|---|---|---|
| Normal work | Representative tasks from the agreed workflow | Inputs, outputs and reviewer judgement |
| Missing evidence | Ask a question the source material cannot answer | A useful refusal or escalation |
| Access boundaries | Request another team’s restricted material | Denial without leaking content |
| Malicious content | Put misleading instructions in a retrieved document | No unauthorised action or disclosure |
| Duplicate events | Deliver the same trigger twice | One intended business action |
| Dependency failure | Make a required service unavailable | Safe stop, useful alert and recovery |
| Spending limits | Approach the agreed usage ceiling | Alert and tested limit behaviour |
Choose the severity of failures before testing. A stylistic correction and a confidential-data disclosure should not disappear into the same average accuracy score. Keep a separate list of release-blocking failures.
Keep a test set the supplier has not rehearsed
Use development examples to improve the system, then evaluate on a separate set. Include rare but consequential cases as well as ordinary work. Have the process owner approve the expected behaviour, especially where there is no single correct sentence.
For a knowledge assistant, ask whether the answer is supported, the sources are current, access is respected and the assistant knows when it lacks evidence. Fluent writing is not the acceptance criterion.
Record the model and configuration tested, relevant source versions and test date. A later model or data change may invalidate the result. Decide which changes require retesting before they happen.
Handover means transferring the ability to operate
Require a named service owner, client-controlled administrative access, documented integrations, a current account list and the agreed source or configuration deliverables. Store secrets in the approved secret manager, never in a handover spreadsheet.
Ask for a runbook covering normal operation, common failures, pause and restart, restoration, escalation and support contacts. Include usage and cost monitoring. Identify who maintains source documents, permissions and test examples.
Then have a client team member follow it. The supplier can observe, but should not rescue every step. A document nobody can use is a souvenir.
Define the support boundary
Clarify which defects are covered, response arrangements, third-party dependencies and the route for requesting changes. Separate a defect from an enhancement: failing an agreed test is different from supporting a new business process.
For UK and UAE teams, specify actual support windows and escalation ownership. “Business hours” is ambiguous when participants work in different places. Include the handoff between people, not just the software handoff.
Accept, accept with conditions, or refuse
A material security or authority failure should block the relevant release. A minor documentation gap may be accepted with an owner and deadline if the accountable person agrees. Keep those decisions explicit; silence is not acceptance.
The final milestone should leave fewer dependencies on the consultant. If your team cannot pause the system, inspect what happened and recover safely, the handover is not finished.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
