AI pilot to production: a go, refine or stop checklist

An AI pilot can produce impressive outputs and still be unfit for production. A demonstration proves that something can work on selected examples. Production requires evidence that it works reliably inside a real process, with owners, controls, integrations and support.

The right decision is not always “go” or “no go”. Many pilots should be refined: narrowed to a safer task, given better context, moved behind human review or rebuilt around a clearer workflow.

Use the following twelve gates to make that decision deliberately.

1. The operational outcome is clear

State the intended result in workflow terms. It might be lower preparation time, fewer missing items, faster triage or more consistent quality review.

If the pilot goal is framed as “prove we can use a large language model”, it is not ready. A production owner cannot manage a technology demonstration as an outcome.

Evidence to request:

• A defined user and workflow.
• A documented current process.
• A baseline and target.
• A named operational owner.

2. AI is the right intervention

Compare the proposed system with simpler alternatives. Better search, standard templates, deterministic rules, process simplification or improved data may solve the problem more reliably.

The UK Government AI Playbook explicitly advises teams to use the right tool for the job. This is not anti-AI. It protects the investment from avoidable complexity.

3. The scope is bounded

Production scope should define what the system does, what it does not do and which cases are eligible.

For example, a pilot might prepare a claim summary from approved documents but not assess coverage, determine liability or send a customer communication. Those boundaries should be enforced in the workflow, not left as a sentence in a training guide.

Check whether the system can recognise cases outside scope and route them safely.

4. The evaluation set represents reality

A handful of curated examples is not enough. The evaluation set should cover common cases, difficult cases, known failure modes and important groups or segments.

The AWS guidance on generative AI quality evaluation recommends a human-curated gold-standard dataset and a multi-faceted evaluation approach. That matters because a single aggregate score can hide severe failures.

Record where each example came from, why it is included and what a good output looks like. Protect personal and confidential information appropriately.

5. Quality meets task-specific thresholds

Do not use a general model benchmark as the release gate. Measure what the workflow needs.

For a document summary, that might include:

• Material facts are supported by the source.
• Required items are present.
• Conflicting evidence is identified.
• No unsupported conclusion is introduced.
• The format helps the user complete the next step.

Set separate thresholds for severe and minor errors. A system should not pass because many easy cases offset a small number of unacceptable failures.

6. Human oversight is meaningful

“Human in the loop” is not a sufficient control description. Define what the reviewer sees, what they check, how much time they have and whether they can reject or reverse the output.

Reviewers need the competence, authority and information required to challenge the system. Monitor overrides and corrections. If users routinely approve outputs without checking, the nominal control is not working.

The ICO’s human review framework is a useful operational reference for meaningful review, logs, reviewer competence and fallback processes. The ICO notes that some guidance is being updated following changes to UK data law, so regulated teams should confirm the current legal position with their advisers.

7. Failure modes have controls and fallbacks

List the ways the system and surrounding workflow can fail. Include missing data, prompt injection, retrieval errors, unsupported claims, unavailable dependencies, latency, model changes and user misuse.

For each material failure mode, record:

1. How it could be detected.
2. Which control reduces its likelihood or impact.
3. What the system or user should do next.
4. Who owns the response.

A fallback might be a manual queue, a read-only result, a request for more information or a return to the current process.

8. Privacy, security and compliance have shaped the design

Approval at the end cannot repair a fundamentally inappropriate data flow. Confirm the lawful use of data, access controls, retention, supplier terms, auditability and the treatment of sensitive information.

Threat-model the whole system, including connected tools and retrieved content. If the pilot uses realistic data, ensure that the pilot environment itself has suitable protection.

Evidence should be proportionate to the use case, but “the vendor has certifications” is not a complete assessment.

9. Integration and operational resilience are proven

Production work rarely happens in a standalone chat window. Test the actual flow of inputs, identities, permissions, outputs and records.

Ask what happens when the model provider, retrieval service or downstream system is unavailable. Define timeout behaviour, retry rules, duplicate prevention and manual recovery. Confirm that logs contain enough information for diagnosis without exposing unnecessary sensitive data.

10. Users can operate the new workflow

Test with the people who will do the work. Observe whether they understand the scope, interpret the output correctly and know when to escalate.

Measure correction effort and workarounds. A tool can save generation time while adding cognitive load or creating a second unofficial process.

Training should cover limitations, not just features. Managers also need to know how the new measures affect workload, quality and performance management.

11. Monitoring and change control are ready

Before launch, define the live measures, alert thresholds, review cadence and owner. Monitor quality, adoption, cost, latency, exceptions and incidents.

The NIST AI Risk Management Framework treats governance, mapping, measurement and management as connected activities across the lifecycle. A pilot is not production-ready if its evaluation stops on release day.

Model versions, prompts, retrieval sources, policies and workflows can all change performance. Use version control and repeat critical evaluations before material changes are released.

12. The value case survives real operating costs

Recalculate the business case using observed adoption, review time, correction effort and production running cost. Include monitoring, support, training and exception handling.

The pilot should show a credible path to an operational outcome, not just theoretical time saved. Our guide to measuring AI ROI explains how to connect task measures to realised value.

Make one of three decisions

Go

Choose “go” when the workflow has an owner, task-specific evaluations meet their thresholds, material risks have effective controls, users can operate the process and the value case remains credible.

A go decision can still require a phased release. Start with controlled volumes, defined eligibility and a rapid route to pause or revert.

Refine

Choose “refine” when the outcome remains valuable but one or more conditions can be improved without changing the entire premise.

Common refinements include:

• Narrowing eligible case types.
• Reducing autonomy.
• Improving source data or retrieval.
• Requiring review for defined risk tiers.
• Redesigning the user interface around evidence.
• Changing the success metric.

Set a time-limited plan and the evidence required for the next gate. “More experimentation” is not a decision.

Stop

Choose “stop” when the value is too small, failures cannot be controlled, data is unsuitable, the workflow has no owner or a simpler solution is better.

Stopping a weak pilot is good portfolio management. Record the evidence and reusable learning, then redirect investment.

Use a signed decision record

The final record should contain:

• The approved use and explicit exclusions.
• Evaluation results and unresolved limitations.
• Risk owners, controls and fallback.
• Production measures and thresholds.
• Rollout scope and pause authority.
• Value assumptions and review date.
• The decision and accountable approvers.

This turns production readiness from a meeting opinion into an auditable operating decision.

If you need to build the evidence behind a release decision, explore our AI evaluation and governance work or discuss your pilot with Sorsana.