An AI prototype explores whether an idea can work. A production service accepts a defined responsibility for real work: who may rely on it, what it will deliver, under which conditions and how problems will be handled. Production can begin with a limited audience and human checking. The change is a supported operating commitment, not a particular number of users or a more polished demonstration.
For an adoption lead preparing a launch decision, make that commitment specific enough for the receiving business team to accept. Keep technical release requirements, output quality and operating support visible. A good result in one of those areas does not settle the others.
If the team cannot explain why the pilot is waiting, use the stalled-pilot guide first. This article addresses the next question: what exactly are you prepared to put into regular use?
Describe the first service people may rely on
Suppose Claire Bennett leads production planning at a 350-person commercial printer. An assistant drafts job tickets for catalogue reprints from an approved customer order and the corresponding artwork approval. The ticket identifies the paper stock, quantity and delivery date, with references to the source records.
A planner checks the ticket against the order and approved artwork before entering the job into the normal production schedule. The assistant cannot authorize printing, alter artwork or commit to a different delivery date.
Claire proposes an initial release for the day-shift planning team at one plant, covering routine catalogue reprints. That is a more useful starting point than “the print assistant is ready.” It names work the team can examine and conditions it can support.
Write the initial offer in terms its users understand:
- Eligible work. Routine reprints with the required order and artwork approval available through the permitted route.
- Finished result. A checked job ticket entered into the ordinary production schedule by an authorized planner.
- Coverage. The named planning team, plant and working hours, with an agreed route for help.
- Unresolved work. Missing or conflicting records stay with a named person for resolution; an attractive draft does not complete the job.
- Alternative. Planners can continue through the supported manual ticket process when AI drafting is unavailable or unsuitable.
Those boundaries need to be reflected in access, instructions and the working process. A line in a launch memo does not prevent another shift from using a shared link or stop a draft being mistaken for an approved ticket.
The pressure to skip this distinction is recognizable. In a July 2026 product-management discussion, a Reddit user described being asked to make prototypes ready to ship. They said they explained to management that the prototypes helped illustrate a solution and gather feedback, while design and engineering work still remained. The employer, organization size and subsequent results were not established. The useful practice is making the purpose of the current artifact explicit before someone relies on more than it demonstrates.
Test the conditions inside that boundary
Before accepting live demand, ask the responsible business, technical and control owners what evidence the proposed service needs. Test the intended configuration, access and workflow, including important failure conditions. A production release is not a way to postpone required security, privacy or action-approval checks.
For Claire, the question is whether the first service can prepare checked reprint tickets under its stated conditions. The evidence should extend beyond a developer generating a clean document from selected files.
| Condition to examine | What the team needs to establish | What the result does not establish |
|---|---|---|
A routine reprint with the approved records | The planner can verify the ticket and complete the normal scheduling step | That unfamiliar artwork or another plant follows the same rules |
An order whose artwork approval is missing | The missing approval is recognized and the job remains unresolved with the responsible person | That a plausible draft supplies permission to print |
An unavailable source or failed drafting request | The planner can identify the affected job and use the agreed alternative without losing it | That every outage or recovery situation has been tested |
Several planners submitting work during a busy period | The service and receiving people can handle the proposed demand within agreed conditions | That an off-peak trial proves readiness for a larger peak |
Choose cases and test depth according to the consequences of failure. Include the people who receive the ticket, not only the people developing the assistant. Use the output-quality guide to define the requirements for a usable result and resolve reviewer disagreement.
Google's guidance on reliable product launches examines dependencies, capacity, failure modes and rollout contingencies together. It also distinguishes a working test configuration from a successful live rollout. This is engineering guidance from Google's services, rather than evidence that an AI workflow has met its own release requirements. Use it to ask concrete questions of the proposed service, without importing Google's scale or organization chart.
The resulting decision may be narrower than the original ambition. If the supported source route works only for one plant's catalogue records, state that boundary. If an essential approval cannot be established, keep the affected work out of the release. A smaller scope can be defensible; an unexplained exception to a required control cannot.
Watch completed work as well as system availability
A service can be online while failing the person who needs it. Claire's assistant might return a ticket quickly but cite an older artwork approval. It might produce the right draft while the job never reaches the production schedule. Neither problem is resolved by showing that the drafting request succeeded.
Agree what the team will observe before launch. For the first release, Claire needs to distinguish:
- Eligible jobs received, including those the process could not complete.
- Tickets checked and entered into the schedule through the agreed route.
- Corrections, unresolved approvals and jobs completed manually.
- Delays or support problems that prevented the promised work.
Define how those observations will be collected and reviewed. If only a sample is checked, describe the sample and what remains unknown. Do not call a manually completed ticket an AI success merely because the assistant was tried earlier in the task. Nor should a properly identified missing approval be hidden as an inconvenient failure of adoption.
The Google SRE workbook's guidance on service objectives separates the outcome that matters to users from the way it is measured. It explains why different measurements have different coverage and limitations. For this print service, the business outcome and the technical signals need to be connected, with agreed definitions. The workbook does not supply a universal target for AI-generated ticket quality.
The people accepting the service should agree what findings require investigation, restriction or a pause. A permission breach needs the appropriate incident response; a ticket-format problem may need a different correction. Do not collapse every issue into a single average score or leave the response to whoever happens to read the dashboard.
Expand one part of the offer deliberately
Once the first release is operating, ask what a proposed expansion changes. More users may bring different orders, less experienced reviewers, another source collection or hours without the same support. A larger audience can therefore change the service itself.
A wider release can change the service being offered
Day-shift catalogue reprints
One plant, approved order and artwork, with a planner checking the ticket before scheduling.
Night-shift reprints
Establish who resolves a missing artwork approval when the day-shift route is unavailable.
Jobs with new artwork
Evaluate the additional approval and checking requirements before including these jobs.
Night-shift reprints and new-artwork jobs raise different questions for Claire. The night shift may use the same ticket format but lack the day shift's route to the artwork-approval owner. New artwork introduces work that the reprint cases did not examine. Neither gap is settled by saying the first team liked the assistant.
Google's canary-release guidance describes evaluating a change on a limited part of a service before proceeding. It cautions that the population, duration, traffic and time of day affect what the evaluation can reveal. Claire's first launch is not automatically a controlled canary experiment. The useful principle is to connect each increase in exposure to evidence about the conditions being added.
For the next decision, record:
- The changed condition. Specify the additional shift, work type, plant or authority being proposed.
- The evidence still needed. State what the current release did not cover and who will examine it.
- The response if it fails. Agree how to limit the affected use and carry unfinished jobs through the supported process.
- The person deciding. Name who can accept the revised commitment and when they will review the evidence.
A quiet week may contain no unusual orders or busy periods. Keep that limit visible rather than turning elapsed time into proof. A rollout plan also cannot make every consequence reversible: stopping new AI drafts does not undo an incorrect ticket already acted on. The service-recovery guide covers the separate work of reconciling completed, pending and uncertain tasks.
Accept an operating commitment that can be reviewed
The launch decision should identify the supported use, the evidence accepted, unresolved restrictions and the people carrying the continuing work. Keep the conditions in a maintained place that users and operators can find. Revisit them when the source material, work, access, dependency or service arrangement changes.
Ownership and cost remain part of that decision, but each deserves more than a name or a token allowance in a launch document. The internal-agent ownership guide explains how to test the receiving arrangement and its permissions. The internal-software cost guide separates recurring operations, known changes and contingent work.
For Claire, an honest decision might authorize the supported day-shift reprint service while keeping night-shift use and new artwork outside the current offer. It should also identify what would cause the accepted use to be restricted or stopped. The value of that decision is its clarity: planners know what they can rely on, and the next expansion has a question to answer.
Questions about moving an AI prototype into production
What does production mean for an internal AI tool?
Production means people use the tool for real work under an accepted operating arrangement. Define the permitted task, users, information, checking, support and response to problems. It can be a small internal service. A polished interface or a live web address alone does not establish that the arrangement works. Start by describing the first supported service.
Can a limited launch still be production?
Yes. A service can support one team or one kind of work while excluding others. If employees rely on it for live jobs, treat those jobs as real operating responsibilities, with the required controls and support. Calling the release a pilot or beta does not remove those duties. Keep the boundary visible and explain what remains outside it.
How many users should the first production release have?
There is no universal user count or percentage. Choose a population the team can support and whose work can answer the immediate release question. Then identify the conditions it does not represent, such as another shift, plant or order type. A small group limits exposure but does not establish readiness for a much wider service. Review the changed conditions before expansion.
Does good uptime prove an AI service is ready?
Uptime shows availability under its measurement definition. It does not establish that outputs are correct, approvals are present or the business task finishes. For a print-job assistant, a generated ticket still needs checking and entry into the authorized schedule. Agree observations of completed work, corrections and exceptions alongside technical health, then act on what each reveals.
When can we expand beyond the first team?
Expand when the responsible owners accept evidence for the additional conditions and can support the revised service. Results from day-shift reprints do not automatically cover night-shift support or new artwork. State what changes, test what remains uncertain and agree how affected work will be handled if the expanded use fails. Do not substitute elapsed weeks or enthusiastic feedback for missing evidence.
Is a signed readiness checklist enough to launch?
A checklist can organize questions and approvals. It cannot establish that a source is accessible, a ticket is checked or an exception reaches someone who can resolve it. Keep the supporting evidence with the decision, complete required reviews and make unresolved restrictions explicit. If the team is still unsure what prevents acceptance, use the stalled-pilot diagnostic to identify the next useful action.
