The Handoff From Discovery to Production That Most AI Roadmaps Skip

A production handoff is a transfer contract between the strategy owner and the people who will build, operate, and support the system. The contract has four parts: the outcome the system is meant to improve, the boundaries that keep it from doing adjacent work, the evidence that demonstrates readiness, and the next action for each predictable failure. The strategy owner remains accountable for the business decision and risk appetite. That does not mean the strategy owner remains the only person who understands the system.

The first mistake is to transfer a capability name instead of a decision. "Automate customer service triage" does not tell a builder what counts as a correct classification, an operator when to pause the flow, or support what a user should see after a bad route. A usable handoff names the workflow, the input, the permitted action, the exception path, and the person who can change scope.

The second mistake is to treat ownership as an org-chart label. Microsoft describes AI responsibility as distributed across the AI platform, the application, and the way people use it, with controls changing by service model. Microsoft's shared responsibility model The implication for a non-software company is direct: a vendor may operate a model or platform, but the company still needs an owner for its workflow, permissions, data, user experience, and escalation path. The handoff makes those boundaries visible.

The strategy owner should leave a decision record, not a mystery. It should answer: why this use case, why now, what is out of scope, what is the cost of a wrong answer, who can override the system, which signals require a pause, and which changes require the strategy owner to decide again. The builder, operator, and support roles should each receive a version of that record that is actionable in their work.

The transfer also needs a definition of done that each receiver can inspect. For the builder, done means the implementation can be tested against the stated boundary. For the operator, done means the service can be observed and controlled during a shift. For support, done means a report can be classified without guessing at the architecture. For strategy, done means the residual risk is legible enough to accept, reduce, or decline. This distinction stops one role's completion signal from masquerading as the whole system's readiness.

Make the record durable enough for turnover. Put the current version, date of the last decision, named owners, links to the runbook, and the location of the evidence pack in the same place. A handoff that works only because one person remembers a workshop is not an operating asset. It is an undocumented dependency that will reappear as an escalation later. The AI RMF gives a useful vocabulary for making those roles and oversight decisions explicit.

Before build work is handed over, the strategy owner needs to package five things. First is the outcome: a named business decision or service movement, not an AI feature. Second is the operating boundary: the tasks the system may perform, the tasks it must refuse, and the cases that return to a person. Third is the evidence standard: the tests, examples, and threshold that make the system acceptable for this workflow. Fourth is the control surface: permissions, data access, audit records, pause conditions, and rollback authority. Fifth is the change rule: what can be tuned within the existing decision and what changes the risk or scope enough to return to strategy.

NIST's AI RMF Playbook recommends documentation that covers business justification, scope, risks, assumptions, limitations, data, tests, dependencies, deployment, monitoring, change management, and stakeholder engagement. NIST's AI RMF Playbook That list is useful because it is written for retrieval. A handoff packet should be findable by the operator at the moment of a failure, not stored as a strategy deck that only the original author can interpret.

The packet should also name the people who receive the work. A role is not enough. Record the function, the decision it owns, its access, its escalation target, and the evidence it must leave behind. If the builder owns code and integrations but not the risk threshold, say so. If support can classify a report but cannot disable the automation, say so. Ambiguity feels efficient during a workshop and becomes delay during an incident.

A useful handoff meeting is therefore a read-back. The builder explains the workflow and its limits. The operator explains the normal run and the pause path. Support explains how a user report becomes a classified incident. The strategy owner corrects only the parts that change outcome, scope, or risk. If every answer still comes from the strategy owner, the transfer has not happened.

The builder does not need a longer vision statement. The builder needs decisions that can become tests. What input is in scope? What output is acceptable? What must never be inferred? What happens when a source is missing, a tool times out, a permission changes, or the model returns a plausible answer with weak evidence? Each answer should map to an example, an assertion, or a known limitation.

The acceptance set should mix ordinary cases with the cases that made the strategy owner nervous in discovery. A successful sample is not enough. Include ambiguous records, empty fields, conflicting instructions, stale source material, an unavailable dependency, and a request that is outside the stated purpose. Record expected behavior, not only expected text. For a triage system, the key result may be the correct route to a person, not a polished explanation.

The builder also needs a dependency map. Google Cloud describes generative AI production systems as complex systems with interacting components and recommends continuous evaluation using production outputs, feedback, and ground truth. Google Cloud's deploy and operate guidance That means the handoff must name more than the model. It must identify retrieval sources, prompts, tools, identity, queues, downstream systems, and the signal that says the result is no longer trustworthy.

Keep the builder's decision surface narrow. A builder can choose an implementation detail inside the agreed outcome and constraints. A builder should not silently broaden the workflow because an adjacent automation is convenient. When a proposed change alters who is affected, what data is exposed, what action is taken, or how a failure is recovered, it becomes a strategy decision again. This boundary keeps delivery moving without making scope drift look like technical progress.

The builder's handoff deliverable is a production evidence pack: architecture and data path, permissions, test set and results, known limitations, dependency owners, deployment version, rollback target, and the changes that still need an explicit decision. It is the bridge between discovery language and an operator's runbook.

The operator inherits the system after the builder has shown that it can work. The operator's question is different: can this service be run repeatedly, watched cheaply enough, paused safely, and restored without waiting for the person who designed it? A runbook must describe the normal day and the bad day. It needs the entry condition, expected signal, owner, action, and evidence for each step.

Monitoring should be tied to a decision. Microsoft Foundry's observability guidance groups operational signals such as latency, errors, token consumption, and quality scores, while its evaluation guidance separates pre-production edge-case testing from post-production continuous or scheduled evaluation. Microsoft Foundry observability guidance Those are not a universal dashboard specification. They are a reminder to connect each signal to an action. If latency rises, who checks the dependency? If quality falls, who samples the outputs? If cost grows, who pauses the route?

Google's MLOps blueprint describes a path from a validated model through a registry into production and calls out monitoring for training-serving skew and prediction drift. Google Cloud's MLOps blueprint An operator does not need to own those concepts as vocabulary. The operator needs to know which alert means the service is outside its tested conditions and what to do next. A good runbook translates technical signals into operational choices.

Write the pause path before the launch path. It should state who can disable the automation, how to preserve in-flight work, what users are told, how a manual route starts, and what evidence the builder receives. It should also state the restore condition. "Turn it back on when fixed" is not a condition. Name the test, approval, or review that demonstrates the service is inside its known boundary again.

The operator's ownership ends at a clear boundary. They can run the service, classify an alert, pause or route work, and provide evidence. They should not be forced to decide whether a new use case is inside the original risk appetite. That decision returns to the strategy owner with facts attached.

Support is where the handoff becomes visible to a person who did not attend discovery. Give support the service boundary in plain language: what the system helps with, what it does not decide, what a user can do next, and what information should accompany a report. Support does not need to explain model architecture to every user. It needs to recognize a known failure and preserve the evidence that helps the next owner act.

A support route should capture the user's task, the input or record involved, the output shown, the time, the visible error, and whether a person corrected the result. Do not ask support to collect every possible log. Ask for the smallest evidence that distinguishes a user misunderstanding, a known limitation, a dependency failure, a permissions problem, and a new behavior. The form should route each category to a named next move.

NIST's generative AI profile calls for incident response and recovery plans to account for value-chain participants and downstream points of contact, including communication and deactivation procedures. NIST's Generative AI Profile Support is a downstream actor in that chain. If support cannot tell who can pause the system or who can explain a changed behavior, the incident plan has a missing link.

The support handoff also needs language for uncertainty. A report can be important without proving that the model is wrong. Support should be able to say that the route is being checked, offer the manual path, and avoid promising a technical explanation before the builder has inspected the evidence. This protects the user and keeps an unverified guess from becoming the next support article.

Treat repeated support reports as production evidence. Microsoft recommends monitoring users, anomalies, accuracy, and cost for generative AI applications. Microsoft's monitoring guidance A single report may need triage. A pattern may change the threshold, the runbook, the test set, or the original business decision. The strategy owner should receive the pattern, not every individual ticket.

The Transfer Test is a small decision framework for moving work out of a strategy owner's head. It has four steps.

1. Name the outcome and risk owner. Write the business result, the in-scope workflow, the out-of-scope work, the risk appetite, and the person who decides when that boundary changes.
2. Package production evidence. Give the builder tests and limits, the operator signals and controls, and support the service boundary and minimum report.
3. Run an owner-free failure drill. Remove a dependency, produce a known bad outcome, or cross a threshold. The receiving roles must classify, contain, communicate, and recover without asking the strategy owner to narrate the runbook.
4. Return only changed decisions to strategy. A defect inside the agreed boundary goes to build or operations. A new use case, new risk, new data access, or new user impact returns to strategy with evidence.

This framework is intentionally less ambitious than a full operating model. It is a release conversation that forces the missing transfer. The UK AI assurance questionnaire treats verification, human oversight, monitoring, and change control as lifecycle work. the UK AI Assurance Questionnaire Its practical value appears when each receiver demonstrates a next move.

NIST's incident response guidance places response inside broader risk management and emphasizes roles, coordination, and continuous improvement. NIST incident response recommendations The Transfer Test follows that logic: recovery requires the wider operating team, and learning requires the strategy owner to see the pattern. Each role contributes the evidence that makes the next decision safer.

Use the test with a real workflow and a real support route. A tabletop that only discusses a hypothetical failure can leave the actual permissions, queue, alert, or rollback path untouched. Make the drill uncomfortable enough to expose the dependency while the team can still change it.

Go-live is ready when the receiving roles can act on the same decision record. The builder can point to the tested behavior, limits, version, data path, and rollback target. The operator can identify normal signals, thresholds, pause authority, manual routing, and restore conditions. Support can recognize the service boundary, collect the minimum evidence, communicate uncertainty, and route the issue. The strategy owner can see what remains unresolved and decide whether the residual risk fits the original outcome.

This is not a demand for perfect AI. It is a demand for visible responsibility. NIST notes that deployed AI monitoring practices and validated methods are still developing, which makes local decisions and clear evidence more important, not less. NIST's report on monitoring deployed AI systems OWASP's 2026 GenAI LLM Top 10 also reflects an expanding threat surface that includes agency, supply chain, and unbounded consumption risks. OWASP's GenAI LLM Top 10 2026 The handoff should state which of those classes matter for this workflow and what control is in place.

A strategy owner who keeps every decision may feel accountable, but the system becomes fragile. A builder who receives a vague goal may ship a feature that cannot be operated. An operator without pause authority may watch a failure without being able to contain it. Support without a service boundary may turn every user report into an escalation. The handoff is the design that prevents those four conditions from reinforcing one another.

For a non-software company, this matters even when the system is assembled from a vendor platform. Buying the components does not buy the operating decision. Your team still owns the workflow, user promise, data boundary, escalation route, and choice to continue or stop. A fractional AI officer can help make that ownership explicit and move the work to the people who will carry it after launch.

Before you approve go-live, ask each role to finish this sentence: "When this system is wrong, I can..." The builder should say diagnose with evidence. The operator should say pause or route work. Support should say classify and preserve the report. The strategy owner should say change or hold the boundary. If one sentence ends with "find the strategy owner," the handoff still has work to do.

The final check is a short absence test. Remove the strategy owner from the launch room and ask the builder to point to the acceptance evidence, the operator to execute a pause, and support to create a useful report. Then ask the strategy owner to review only the unresolved decision. This exposes whether the organization has transferred a working system or merely transferred a set of meeting notes. It also makes the cost of delay visible: every missing owner, missing signal, or missing recovery step is a dependency that will be paid for under pressure.

Keep the review cadence proportional to the workflow. A low-impact internal drafting route may need a lighter exercise than a customer-facing decision or a system that can trigger a downstream action. The principle stays the same. The receiving roles need enough evidence and authority to act inside the boundary, and the strategy owner needs enough signal to decide when that boundary no longer holds.