The pilot has worked. People want to keep using it. The next decision is whether the organisation can operate the whole workflow once the people who built the demonstration return to other work.
An AI system changes more than the speed of a task. It introduces a model dependency, a set of data movements and a new path by which an incorrect suggestion can become an action. Each of those needs someone with the authority and means to respond.
Ownership becomes visible when the system produces a plausible but wrong result, a provider changes its behaviour or the only person who understands the integration is unavailable. Prepare for those situations before calling the pilot an operating service.
Assign ownership to the workflow
Name a business owner for the result the workflow is meant to produce. That person accepts its limits and decides whether its benefit justifies continued operation. Name a service owner for the day-to-day system, including dependencies, monitoring, releases and recovery.
One person may hold several roles in a small organisation. The responsibilities still need to be explicit, and a deputy must be able to act. An external provider can operate a component while an internal owner remains responsible for the organisation's use of it.
NIST's AI Risk Management Framework calls for defined responsibilities, ongoing monitoring and safe decommissioning. The map below translates those concerns into questions an operator can use during a handover.
Keep an ownership map beside the service
| Responsibility | Decision that needs an owner | Evidence to keep |
|---|---|---|
| Business result | Continue, narrow or stop the use case | Intended outcome, limits and accepted residual risks |
| Service operation | Release, pause and recover the workflow | Runbook, deputy, release history and tested fallback |
| Data use | Permit inputs, retention and third-party processing | Data-flow record and approved usage boundaries |
| Output review | Accept, correct or reject consequential results | Review criteria, escalation route and sampled outcomes |
| Supplier dependency | Accept a model change or move provider | Version record, evaluation set and exit procedure |
| Incident response | Contain a problem and authorise resumption | Decision log, affected-work inventory and recovery evidence |
Put actual names and deputies into the organisation's private copy. Keep contact details and credentials out of public documentation. A role label in a diagram is useful only if the assigned person has the time, access and authority to perform it.
Define what the system may do
Describe the unit of work: summarise a document, prepare an offer draft, classify a support request or propose a scheduling change. State which actions require approval and what the approver must see. Approval should bind the actual recipient, content and intended action, so later changes prompt a fresh decision.
Distinguish preparing an action from executing it. If a tool reports an uncertain delivery outcome, the operator needs to inspect the existing provider record before trying again. Repeating the instruction can duplicate a message, payment or publication. Build that recovery path into the service rather than leaving it to whoever notices the problem.
Monitor the result people depend on
Keep a small evaluation set that represents the real task, including difficult cases and cases the system should decline. Record the model, instructions, retrieval sources and relevant configuration used for each release. Repeat the checks when those inputs change.
In operation, inspect a proportionate sample of completed work and record corrections, overrides, complaints and unresolved failures. Technical success alone is incomplete evidence: a request can return successfully while attaching the wrong document or producing an unusable answer. The business owner should define what counts as an acceptable result.
Connect each monitored condition to an action. Name who receives the signal, the circumstances that require a pause and the evidence needed to resume. An alert that nobody is expected to handle becomes another unattended dependency.
Rehearse escalation and fallback
Use a synthetic case in a controlled environment. Make a required input unavailable, return a wrong answer from the provider fixture or interrupt the worker after an external action may have happened. Ask the deputy to locate the affected work and follow the recovery procedure.
The fallback can be smaller than the normal service. A team may temporarily review every result, accept work into a queue or stop one class of action while preserving other functions. Define that reduced state in advance, including its capacity and the conditions under which it becomes unsafe to continue.
Record the parts that were only described. A verbal explanation of how to revoke a key or reconcile a delivery does not demonstrate that the operator has the required access.
Make exit part of the operating agreement
The service owner should know how to stop new work, account for in-flight operations, export the required records and remove access that is no longer needed. Check the retention obligations and customer commitments that remain after the model or provider is replaced.
Test a representative task against a proposed replacement before switching. Preserve the old evaluation results and configuration so a change in behaviour can be investigated. Cost savings need to be considered alongside review effort, failure handling and the work required to maintain the replacement.
Before handover, ask the business owner and service owner to agree on the operating scope, named deputies, review schedule, escalation limits and resources. Revisit the agreement when the use case or provider changes. A pilot becomes an operating service when the organisation can keep those commitments over time.
Read this alongside Why AI projects fail, AI strategy without operational ownership is theatre and The optimisation trap. Each examines a different point at which a promising technical result can lose its connection to the organisation responsible for using it.