AI Production Readiness Checklist: Pilot to Production

A good demo is weak evidence that an AI workflow is ready for production. The demo uses a clean input, a patient operator, and no concurrent failures. Real work brings incomplete records, changing APIs, impatient users, sensitive data, and actions that cannot simply be undone. An AI production readiness checklist turns that gap into a launch decision.

The practical goal is one evidence packet. It should show the business result, evaluation results, operational limits, security controls, accountable owner, staged rollout plan, and rollback authority for a single workflow. If the packet has an unresolved red item, pause. If it passes, expose a small canary and verify the same evidence with real traffic before widening access.

Why pilots pass while production workflows fail

A pilot usually answers a narrow question: can the model complete the happy path? Production asks several harder questions at once.

Can the workflow complete the job across representative inputs? Can it detect when it lacks enough information? Can it fail without duplicating a payment, message, ticket, or record update? Can an operator explain what happened? Can the company cap spend and latency? Can the system protect credentials and private data? Can a named person stop it?

Model quality covers only part of those questions. A better prompt cannot provide database isolation, idempotency, rollback, ownership, or an incident path. The Ask HN discussion about agents stuck at proof of concept reports inconsistent decisions, opaque reasoning, tool failures on edge cases, incomplete outputs, and weak missing-information handling. Treat that thread as practitioner evidence, not a universal failure rate. It still describes why a clean demonstration is weak acceptance evidence.

The failure often starts before engineering. A team says the pilot should be “accurate” or “save time” without defining the baseline, acceptable error rate, or unacceptable outcome. Every later review becomes subjective. Product likes the fluent output, engineering worries about edge cases, security asks for a data map, and operations has no staffing plan. Nobody has the authority or evidence to say yes or no.

Fix that by making readiness a recorded decision with named evidence. Do not use a single blended score to hide a critical failure. A workflow that saves ten hours a week but can expose another customer's data is not 80 percent ready.

Define the production contract before adding features

Start with one written production contract. Keep it short enough that product, engineering, security, and the operating team can review it together.

Record these fields:

• Business job: the exact unit of work the workflow accepts and completes.
• Population: users, tenants, languages, document types, and systems included at launch.
• Baseline: current time, cost, quality, and error rate for the manual or existing process.
• Success target: one primary KPI and its measurement window.
• Unacceptable outcomes: events that block launch regardless of average performance.
• Decision authority: who approves, pauses, rolls back, and restarts the workflow.
• Operating owner: who receives alerts and reconciles failed or uncertain work.
• Exposure plan: shadow, internal canary, limited production group, then wider rollout.

For example, consider an invoice-intake pilot. “Extract invoices accurately” is not a production contract. A useful contract says the workflow accepts English PDF invoices from three approved mailboxes, extracts six required fields, and stages a draft payable for human approval. It must never post a payment, merge vendors across tenants, or treat a low-confidence total as valid. The primary KPI is median handling time per invoice, compared over two weeks with the existing process.

This contract constrains evaluation and rollout. It also stops scope from expanding during the readiness review. If handwritten receipts were not in the launch population, they should not delay launch, and the workflow must reject or route them rather than pretend to support them.

Build a representative evaluation set

Evaluation data should look like the work the system will receive, including the cases that make operators slow down. OpenAI describes evaluations as tests of model outputs against criteria you specify and recommends a cycle of describing the task, running test inputs, and analyzing results. Use any suitable tooling, but keep that discipline.

Freeze a versioned set before the go-live review. Include ordinary cases, boundary cases, known historical failures, malformed inputs, missing fields, conflicting evidence, and attempts to induce unsafe behavior. Remove or transform sensitive data according to the project's data policy, but preserve the features that made each case difficult.

Each case needs an expected disposition, not necessarily one exact sentence. Useful dispositions include:

• complete automatically
• request missing information
• route to a human
• reject as unsupported
• stop before a side effect
• retry safely after a transient failure

Measure the complete workflow. A correct model response followed by a duplicate tool call is a failed case. A refusal that prevents legitimate work is also a failure, even if it looks safe in a model-only test.

Use separate measures for task success, unsafe outcomes, human-review rate, latency, and cost. Report counts and denominators. “92 percent passed” hides whether the remaining failures were harmless formatting issues or unauthorized actions. Every unacceptable outcome should have a count of zero in the frozen set and the canary.

Test the workflow around the model

Production readiness requires deterministic tests below and around model inference. The model can vary while the execution boundary stays strict.

Test authentication and authorization with the real identity path. Verify that one tenant cannot retrieve another tenant's context or invoke its tools. Confirm that credentials never enter prompts, traces, or generated output. Review every external destination and data store against the system's data map.

Test side effects with duplicate delivery, retries, concurrent work, stale approvals, timeouts, and uncertain responses. Every mutation needs a durable operation identity. If the provider times out after receiving a request, reconciliation should determine whether the action happened before another attempt runs.

Test limits. Set maximum model calls, tool calls, elapsed time, input size, output size, and spend per unit of work. OpenAI's production guidance covers access controls, key protection, spend limits, scaling, and operational planning. Provider limits help, but a workflow also needs its own per-run budgets so one loop cannot consume the team's monthly allowance.

Test degraded dependencies. The workflow should distinguish a rate limit, timeout, invalid response, unavailable database, rejected authorization, and policy denial. Operators need a typed outcome and a recovery action. “Something went wrong” is not enough to reconcile business work.

Security review should be tied to the actual architecture. The OWASP GenAI security project maintains a current risk landscape, but a list of risks is only a starting point. For each applicable risk, record the trust boundary, control, negative test, owner, and remaining exposure. Mark non-applicable items with a reason rather than silently omitting them.

Use a readiness scorecard that can block launch

A scorecard should preserve hard gates. Use green, amber, and red for each category, but define what the colors mean before the review.

Green means evidence exists and the approver accepts it. Amber means the issue has a bounded workaround, owner, and deadline. Red means no launch. Never average a red into a passing total.

The sign-off record should name the workflow version, model and prompt versions, evaluation-set version, enabled tools, launch population, approved limits, known amber items, approvers, and timestamp. The team can then identify which system was approved when a later prompt, model, tool, or policy changes.

The NIST AI Risk Management Framework is designed to incorporate trustworthiness into the design, development, use, and evaluation of AI systems. A small team does not need to reproduce the full framework in a launch meeting. It should preserve the underlying practice: identify the context, measure relevant risks, manage them through accountable controls, and review the result as the system changes.

Move through shadow mode and a canary

Do not move directly from the test set to all users. Use exposure stages that can produce new evidence without placing every business process at risk.

In shadow mode, copy eligible inputs to the new workflow without allowing it to create production side effects. Compare its proposed disposition with the existing process. Record disagreements and review a sample from both agreements and disagreements. Shadow mode is useful for decision and extraction workflows, but it cannot prove the behavior of real mutations, permissions, or user interactions.

Next, launch a small canary. Choose a coherent group such as one internal team, one low-risk tenant, or one document class. Do not choose only expert users who can compensate for defects unless expert users are the actual launch population.

Google SRE defines a canary as a partial, time-limited deployment evaluated to decide whether rollout should proceed. Apply that decision structure directly. Name the canary duration, minimum case count, control or baseline, promotion thresholds, and stop conditions before exposure starts.

A canary dashboard should show:

• work received, completed, rejected, and awaiting review
• unacceptable outcomes and authorization denials
• human overrides and their reasons
• latency and cost by completed unit
• retries, timeouts, and uncertain side effects
• user or operator complaints
• comparison with the baseline KPI

Pause automatically on a critical security event, an unacceptable business action, missing audit evidence, or loss of the reconciliation path. A human should also be able to pause immediately. Promotion should require a recorded review, not the absence of an alarm.

Plan rollback as a business operation

A rollback must account for work already created by the newer version, not only the deployed code.

Document how to stop new admission, disable side-effecting tools, preserve in-flight evidence, identify records produced by the canary, and reconcile uncertain outcomes. State whether queued items can run under the previous version or must remain quarantined. Keep the old execution path available only if its data and state contracts remain compatible.

Assign rollback authority to a role that is reachable during launch hours. Do not require a meeting of six people to stop a workflow that is sending duplicate messages. Separate the authority to pause from the authority to resume. Restart should require evidence that the cause is understood, affected work is reconciled, and the repaired version passed the relevant regression cases.

Run one rollback exercise before launch. Trigger a synthetic stop condition, pause admission, inspect in-flight work, revert the canary, and prove that no duplicate side effects occur. Record the elapsed time and every manual dependency discovered.

Hold a seven-day production review

The launch decision is not the end of readiness. Schedule a review after seven days or after a defined case count, whichever comes later.

Compare production results with the frozen evaluation set and baseline. Review every human override, policy denial, uncertain outcome, and complaint. Check whether input mix differs from the pilot. Confirm actual cost and latency distributions rather than relying on pre-launch estimates. Add new failure cases to the evaluation set before changing prompts or models.

The review should produce one of four decisions: widen exposure, hold at the current canary, narrow the supported population, or roll back. Record the evidence and owner for each follow-up. A successful week with ten easy cases is not enough to promote if the launch contract expected hundreds of varied documents.

Run the go-live gate on one workflow

Start with the workflow closest to production. Write its business job, launch population, KPI, unacceptable outcomes, owner, and rollback authority on one page. Freeze representative cases and run them through the complete system, including tools and failure paths. Fill the scorecard with links to evidence, not opinions.

If every category is green or has an accepted amber workaround, run shadow mode and then a bounded canary. If any category is red, stop and assign the missing control. Keep the completed checklist with the launch record so the next model, prompt, tool, or policy change can be tested against the same accepted boundary.

References

1. OpenAI working with evals supports criteria-based model-output evaluation using repeatable test inputs and analysis.
2. OpenAI production best practices supports access, secret, spend, scaling, and operational planning for production API use.
3. NIST AI Risk Management Framework supports accountable trustworthiness and risk management across the AI system lifecycle.
4. Google SRE canarying releases supports partial, time-limited exposure evaluated against rollout criteria.
5. OWASP GenAI LLM risks archive provides the maintained security-risk landscape used to scope system-specific checks.
6. Ask HN: blockers beyond proof of concept is practitioner evidence about reliability, repeatability, tool-edge-case, and trust problems in production agents.

---