# From pilot to operating capability AI-assisted editorial draft • Bill Allred review pending • Draft and sources checked 19 October 2026 ## Executive answer A pilot becomes an operating capability when the business can depend on the workflow within a defined boundary, including when something changes or fails. That requires more than a working model: named decision owners, reliable checks, an exception process, user adoption, support, maintenance, and evidence of business value. Make the transition explicit. Decide which work will move into the new process, which existing work will stop, and which responsibilities remain with people. If nobody can answer who owns an incorrect result or a broken integration after the pilot team leaves, the capability is not ready for routine operation. ## Change the object of management During a pilot, teams often manage experiments: prompts, examples, demonstrations, and feedback. In operation, they must manage a service with inputs, dependencies, decision rights, and consequences. Write a one-page operating agreement. Name the business owner accountable for outcomes, the technical owner responsible for the running system, the data owner responsible for authoritative records, and the operational role handling exceptions. Identify who can authorize scope changes and who can stop the workflow. A supplier can perform tasks, but the business still needs an internal owner who understands what has been delegated. The NIST AI RMF organizes risk management into Govern, Map, Measure, and Manage. That offers a useful structure for connecting accountability to context, evidence, and action throughout operation. It is voluntary guidance, not an operational certification. [NIST AI RMF 1.0](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) ## Make verification part of the service The operating design should show how AI-generated work is checked before it affects a customer, record, or decision. Put dependable checks close to the action: reconcile totals before posting a value, verify a source identifier before linking a record, and enforce action permissions outside the model's discretion. A second model may help evaluate text against a rubric. It should not become an unexamined authority for its own or another model's correctness. Track its missed errors against independently assessed cases. Preserve human judgment for the decisions that actually require it, and make exceptions visible with enough context for someone to resolve them. This division matters economically. If employees quietly recheck every answer because they distrust the service, a dashboard showing high usage may conceal duplicated work. Measure both dependable automatic completion and the effort needed to resolve uncertainty. ## Worked example: a hypothetical maintenance-request service Consider a property operations team piloting an assistant that organizes incoming maintenance requests. Its allowed role is to extract location and issue details, suggest a queue, and identify missing information. It cannot diagnose hazards, dispatch emergency work autonomously, or decide tenant eligibility. The pilot demonstrates that ordinary requests can be categorized. The operating transition adds different requirements. The location must match a current property record. The requester must be associated with the correct authorized context. Missing information must route to a queue with an owner. Potentially urgent or ambiguous reports must follow the organization's existing human response process, with no claim that the assistant can reliably detect every emergency. In this hypothetical transition, the business owner starts with one routine request class in one team. Staff practice handling a wrong location, an unavailable property system, and an unassigned exception. The technical owner proves that the old intake route remains usable. The operations lead verifies that employees can see why a request was routed and correct the underlying record. A proposed benefit is faster preparation of complete requests. The team measures elapsed time to a complete record, staff handling time, correction rate, and exception backlog. These are proposed measures, not claimed results. Expansion depends on evidence that the service improves work without creating an unmanaged queue or transferring hidden effort to another team. ## Treat adoption as workflow design Give users a clear trigger for using the new process and an equally clear route when it does not apply. Show examples of accepted, rejected, and escalated outputs. Explain who sees feedback and what happens after an error is reported. Remove redundant steps only after their replacement is verified and approved. During transition, distinguish temporary double-running from the intended steady state. Ask users where they still copy information, repeat checks, or work around missing context. Those observations reveal costs that technical logs cannot show alone. ## Fund maintenance before expansion Assign ownership for changes in source systems, permissions, business rules, models, prompts, and checking logic. Define which changes require reevaluation and who can approve deployment. Maintain versioned examples of previous failures so that fixes are tested again when components change. Operational monitoring should connect signals to decisions. A rising exception backlog needs an owner and a response, not just a chart. An unavailable source may require a fallback. A violated authorization boundary may require stopping the affected capability. Log enough evidence to investigate while applying appropriate access and retention rules; more logging is not automatically better. OpenAI's evaluation documentation recommends rerunning evaluations as systems change and adding newly observed cases. That supports an explicit regression-testing responsibility in the operating plan. [Official evaluation guidance](https://developers.openai.com/api/docs/guides/evaluation-best-practices) ## Decide whether to expand, repair, or stop Review the capability against the original business outcome, operating burden, and residual risk. Expansion is justified by evidence for the next scope, not by enthusiasm for the first demonstration. A smaller dependable service can be the right outcome. Retirement is also a legitimate decision when maintenance exceeds value or the business need changes. This proposed playbook requires adaptation and qualified review for the actual setting. It makes no security, safety, legal-compliance, or delivery guarantee. **Next step:** use the [operating-readiness checklist and ownership matrix](https://altiport.ai/downloads/pilot-to-operating-capability-worksheet.md) to expose the decisions a pilot has not yet tested.