Who owns an AI workflow after the pilot?

Separate the rights from the work of operating it

“You own the workflow” can mean several things: you can access the code, you have rights to use the delivered materials, you control the service accounts, or someone is responsible for tomorrow’s failed run. Agree each meaning before the pilot ends.

The contract should state the rights to the delivered code, prompts, workflow definitions and documentation, along with any third-party license or reusable-component limits. Access to a repository alone does not settle those rights. Operating ownership is a separate decision: name the person who accepts results, approves changes and can stop the workflow.

A consultant can help prepare and rehearse the handover. That does not establish that support, incident response or future platform changes are included indefinitely. Those commitments belong in an explicitly agreed scope.

Name the decisions a client owner must make

One person may cover several roles in a small team. The important point is that each decision has an owner and a usable route when that owner is unavailable. The table is a practical starting arrangement, not a staffing requirement.

Leave an operating record, not just a folder of files

Create a small index that points to the accepted version and the materials needed to run it. It should identify the repository or export, workflow configuration, prompt versions, input and destination schemas, deployment environment, runtime identities and external dependencies. Include account ownership and recurring software costs without exposing secrets.

Keep evaluation inputs, actual results and unresolved limits with that version. Clearly separate synthetic examples from any approved real records. Note what was observed, where it ran and what remains untested. A result from a test board should remain a test-board result when the handover is discussed.

The record also needs an operator guide: how to start a permitted run, recognize success at the destination, find a held item, pause new work and investigate an unresolved attempt. Give each step an observable outcome. “Contact the developer if it fails” leaves the essential operating decision with the wrong person.

Use a handover rehearsal as an acceptance check

Ask the designated client operator to work through the guide in the approved environment. The consultant observes and helps identify gaps; the client performs the steps. Record what happened and revise unclear instructions before treating the rehearsal as complete.

• Run one agreed normal example and locate its actual destination result.
• Handle a missing-input or review-held example using the named decision route.
• Pause new triggers and check what happens to work already in progress; preserve unresolved attempts for reconciliation.
• Restore the approved configuration using the documented process, then repeat the relevant check.
• Remove the consultant’s human access and verify that the intended client-owned route remains operable, or close runtime access if the pilot is being retired.

Accept the tested boundary and keep its limits visible

Agree acceptance criteria before the rehearsal. They might cover destination fields, required approval, held-item visibility, recovery evidence and the effort needed to review the result. Choose thresholds that matter to the workflow rather than borrowing an arbitrary accuracy percentage.

The NIST AI RMF Playbook’s MEASURE 2.3 discusses demonstrating performance under conditions similar to deployment and documenting the measures. MEASURE 2.5 addresses documenting limits beyond the tested conditions. For a small pilot, the practical consequence is simple: retain the environment and examples with the result, then identify the extra checks needed before broadening it.

NIST describes the AI RMF as voluntary guidance. The ownership roles and rehearsal here are my commissioning recommendations; completing them does not establish NIST certification or regulatory compliance.

Decide who watches it and what requires another check

Before leaving a pilot running, agree who checks its run status, where users report a problem, how a held item reaches its owner and which conditions cause a pause. Confirm the monitoring mechanism actually configured. A proposed alert or a scheduled check is not evidence that delivery and recovery work.

Treat changes to a model, prompt, schema, tool permission or destination as potential changes to the accepted workflow. Record the changed version and rerun the relevant cases before relying on the broader route. Define who can approve that decision and how the prior version can be restored when restoration is supported.

NIST’s GOVERN 2.1 calls for clear, documented responsibilities and communication. MANAGE 4.1 includes post-deployment monitoring, override, decommissioning, incident response, recovery and change management. These are useful reference points for assigning the work; they do not supply an on-call team or a response-time promise.

Finish with an explicit continue, extend or retire decision

A synthetic example makes the boundary concrete. A pilot creates reviewed tasks in a test board. The client can find accepted tasks, resolve held requests and pause the trigger. Later, the live board introduces mandatory fields absent from the test board. That is a new validation question; the earlier result does not prove the live route works.

The client can accept operation within the tested boundary, commission a revised scope for the new destination, or retire the pilot. If retiring, name who disables the triggers, reconciles unfinished work, removes grants and handles samples and logs under the agreed retention policy. If continuing, state any separately commissioned support, its owner and its limits.

I work as an independent FDE engineer and AI implementation consultant. For a one-workflow pilot, the proposed handover should be part of the written scope, alongside the connections, permitted environment and acceptance evidence. The pilot checklist is a useful starting point for that conversation.