# How to move an AI pilot to production: 7 steps

> How to move an AI pilot to production in 7 steps: production definition, integration, evaluation, security review, approval gates, release and ownership.

- URL: https://www.ornsoft.com/blog/how-to-move-an-ai-pilot-to-production/
- Published: November 2, 2026
- Updated: November 2, 2026
- Author: OrNsoft team, OrNsoft Corporation
- Category: Production AI
- Publisher: OrNsoft (https://www.ornsoft.com/)

To move an AI pilot to production, take it through seven steps: write the production definition with its owners, connect the real data and systems, build the evaluation set, pass the security review, add approval gates for sensitive automated actions, release in stages, and name the owner who runs it. Each step ends with something you can check, so you always know where the system stands.

**Moving an AI pilot to production means turning a system that works on chosen examples into one the operation depends on, on live data, under the rules that apply, with a named owner.**

AI is easy to demo. Production is the hard part. This article is the operational how-to: one deliverable per step, who owns it, and what usually blocks it. The map behind it, with the stages, the gates and who signs each one, is in [from AI pilot to production: the path, the gates and the owners](/blog/ai-pilot-to-production/).

> **Key takeaways**
>
> - **Seven steps, seven deliverables.** A step is done when its deliverable exists, not when the work feels done.
> - **Start with one signed page.** The production definition decides what every later step is measured against.
> - **Freeze the evaluation set early,** so "good enough" has a number before anyone argues about results.
> - **Release in stages,** with a rollback, and **name the owner** before go-live, not after.

## What are the 7 steps to move an AI pilot to production?

1. **Define production** with a business owner and a technical owner, on one signed page.
2. **Connect the real data and systems,** under the identity and permissions production requires.
3. **Build and freeze the evaluation set,** then measure against it.
4. **Pass the security review,** with a written file of data flows, hosting and access.
5. **Add approval gates for sensitive automated actions,** so a person decides where a mistake is costly.
6. **Release in stages,** with a rollback, before the whole operation depends on it.
7. **Name the owner who runs it,** and hand over the runbook.

![Pilot to production in seven steps, each with its deliverable: 1 define production, signed production definition. 2 connect data and systems, working integrations. 3 evaluate, evaluation report. 4 pass the security review, security file. 5 add approval gates, approval matrix. 6 release in stages, release plan with rollback. 7 name the owner, runbook and named owner.](../../../assets/blog/how-to-move-an-ai-pilot-to-production/seven-steps.svg)

## Step 1: what does production mean for this system?

Write it down before anything else. The production definition fixes the scope, the success criteria in measurable terms, the examples the system is measured against, the security constraints, the approval rules and the go-live date. It is signed by the business owner, who decides what good enough means, and the technical owner, who decides how the system fits your architecture.

If the page cannot be written, that is the answer: the pilot is not ready, and you learn it before spending on another round. The template and what goes in each section are in [how to define production for an AI system](/blog/define-production-for-an-ai-system/).

## Step 2: how do you connect the pilot to real data and systems?

Build where the system will run. A pilot often reads a copy of the data or a sample export. Production reads live data from the systems you already run, under the identity and permissions those systems require. Work in your repository and your target environment, not in a separate sandbox someone has to port later.

The usual blocker is access, not code: credentials, a service account, a firewall rule, an owner for each source. List them in week one.

## Step 3: how do you know the AI system is good enough?

Build an evaluation set from real cases, with the expected result for each, and freeze it when the production definition is signed. Every later version is measured against the same examples, so progress is a number, not an impression.

Engineering teams that run services in production work the same way. The [Google SRE book](https://sre.google/sre-book/service-level-objectives/) defines a service level objective as a target value or range of values for a service level measured by an indicator. The evaluation set gives an AI system its indicators. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) treats measurement as one of its four functions, next to Govern, Map and Manage.

## Step 4: what does the security review need?

A written file the reviewer can sign: where the data flows, where the system is hosted, who can access what, and how the system behaves when an input is hostile. Start it early, because a review that starts at the end is the step that moves the go-live date.

For systems built on large language models, the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a practical checklist for the reviewer, from prompt injection to excessive agency.

## Step 5: which actions need a person's approval?

Not every output needs a human check, but some must have one. List the automated actions where a mistake is costly or hard to undo (a payment, a message to a customer, a change to a record of reference) and put approval gates for sensitive automated actions in front of them. The result is an approval matrix: which action, who approves, and within what time.

This is also where adoption is decided. People trust a system faster when they can see where a person decides.

## Step 6: how do you release an AI system without risking the operation?

In stages. Start with a part of the traffic, a team, a region or a document type, compare the results with the current process, and widen only when the agreed criteria hold. Keep a rollback ready at every stage.

The [Google SRE workbook](https://sre.google/workbook/canarying-releases/) defines canarying as "a partial and time-limited deployment of a change in a service and its evaluation." The same discipline applies to an AI system, with the evaluation set as the yardstick. For the pipeline side of repeatable releases, see Google Cloud's guide to [MLOps continuous delivery and automation pipelines](https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning).

## Step 7: who owns the AI system after go-live?

Name the owner before go-live. Someone has to watch the measures, handle incidents, approve changes to prompts, models and rules, and decide when the system needs work. Hand over a runbook that says how.

A system with no owner after launch tends to drift back into a pilot: it works, nobody trusts it, and nobody fixes it. We describe that pattern in [why AI pilots stall](/blog/why-ai-pilots-stall/).

## What usually blocks each step?

| Step | Deliverable | Owner | Usual blocker |
| --- | --- | --- | --- |
| 1. Define production | Signed production definition | Business and technical owners | No owner named |
| 2. Connect data and systems | Working integrations in your repository | Technical owner | Access arrives late |
| 3. Evaluate | Frozen evaluation set and results | Business owner | No agreed examples |
| 4. Security review | Signed security file | Security contact | Review starts at the end |
| 5. Approval gates | Approval matrix | Business owner | Every output checked, or none |
| 6. Staged release | Release plan with rollback | Technical owner | Big-bang launch |
| 7. Ownership | Runbook and named owner | Business owner | Nobody runs it after launch |

![Checklist, one row per step with a tick box, its deliverable, its owner and the usual blocker. 1 define production: signed production definition; business and technical owners; blocker, no owner named. 2 connect data and systems: working integrations in your repository; technical owner; access arrives late. 3 evaluate: frozen evaluation set and results; business owner; no agreed examples. 4 security review: signed security file; security contact; review starts at the end. 5 approval gates: approval matrix; business owner; every output checked, or none. 6 staged release: release plan with rollback; technical owner; big-bang launch. 7 ownership: runbook and named owner; business owner; nobody runs it after launch.](../../../assets/blog/how-to-move-an-ai-pilot-to-production/step-owner-checklist.svg)

## How do you know the pilot is ready to start?

Three things should exist before step 1: two people who can sign (a business owner and a technical owner), access to the pilot as it is (code, prompts, data, the examples it was tried on), and a short list of the decisions the system is meant to help with. Without them, the early weeks go to finding them.

## Where does forward-deployed engineering fit?

When a pilot works but nobody owns the path to production, a forward-deployed team takes these seven steps with your teams and stays accountable until the system runs. How that engagement runs, week by week, is in [how a forward-deployed engineering engagement works](/blog/how-a-forward-deployed-engagement-works/), and the offer itself is on our [forward-deployed engineering](/forward-deployed) page.

## What should you do next?

If you have a pilot that works and has to run in production, start with step 1: the two names and the one page. Then [book a call](/contact). One call is enough to know whether we can help.

## Questions

### How do you move AI from pilot to production?

In seven steps: write the production definition with its owners, connect the real data and systems, build the evaluation set, pass the security review, add approval gates for sensitive automated actions, release in stages, and name the owner who runs it.

### How do you scale an AI pilot?

Take one system through every step first. The production definition, the evaluation set, the security file and the runbook it produces become the starting point for the next system, so the second one moves faster.

### What is the AI pilot-to-production gap?

The distance between a pilot that works on the examples people tried and a system the operation depends on every day. It is made of open decisions: data access, measurement, security, approvals and ownership.

### What should be in an AI production checklist?

One line per step: a signed production definition, working integrations, a frozen evaluation set with results, a passed security review, an approval matrix, a staged release plan with a rollback, and a named owner with a runbook.

### How long does it take to move an AI pilot to production?

It depends on the open decisions, not on the model. A pilot whose owners, data access and security contact are known moves through the steps faster than one where they still have to be found.