The AI pilot went well in the demo. How do I know it works before scaling it?

In 1 minute

A demo shows what AI can do with hand-picked examples. A pilot has to answer a different question: whether it does the everyday work better, cheaper or faster than it is done today, with the cases that actually come in. To know that, three things are needed, and it pays to set them before starting: how much the work costs and how long it takes today, a sample of real cases —including the hard ones— and written criteria that say which result leads to scaling, adjusting or stopping.

Imagine a services company that receives hundreds of requests from its customers every day: invoice queries, data changes, certificates. It is fictitious, but it looks like many. A team of five people reads them, sorts them and drafts the reply.

A vendor proposes an AI pilot: the system sorts each request and leaves a reply ready for a person to review and send. In the demo, in front of the board, the AI handles twenty examples without a stumble. The replies are clear, the tone is right and everything takes seconds. Someone asks: "When do we roll it out to everyone?"

It is the natural question. And it is the one worth not answering yet, because the demo did not provide the data to answer it.

This article is for those who have to approve —or stop— the move of an AI pilot into operation. It makes one argument: a pilot is measured against today's work, with real cases and an exit criterion set before starting; not against the demo. You do not need to know about models to apply it; you need to know how the work is done today.

What a demo cannot tell you

A demo is made to show. The examples are chosen, the setting is clean and nobody asks how much each reply cost or how long the person took to review it. That does not make it misleading: it makes it incomplete for deciding.

That is why a demo on its own gives limited evidence about three things:

• The cases that actually come in. OpenAI's evaluation guide recommends that tests "reflect model capability in real-world distributions" [3]: the cases with the mix and difficulty the operation has, not the ones that look best.
• Variation. The same guide warns that "Generative AI is variable": the model can give different answers to the same input, which makes traditional software testing insufficient [3]. Twenty hits are an initial signal; they are not enough to estimate how the system will behave with a month's volume.
• The point of comparison. "It went well" — compared with what? Without knowing how that same work turns out today, there is no way to say whether AI improves it.

Step 1 · Measure today's work, before touching anything

The machine learning rules Google publishes put this first: before formalizing what the system will do, design and implement metrics, and track as much as possible in the current system [1]. The reason is simple: if the before is not measured, the after has nothing to be compared against.

In the fictitious company, measuring today means answering, with data from a normal month:

• How many requests come in, and of what types?
• How long does a reply take on average, from arrival to sending?
• How many go out with an error and have to be corrected, and how many lead to a complaint?
• How much does handling one cost, adding up people's time?

The same Google document has another rule worth reading before any pilot: don't be afraid to launch a product without machine learning, because a well-thought-out simple rule can outperform a model with no data [1]. Sometimes, measuring today reveals that half the requests are solved with a template and a rule. That is also a good finding: AI is kept for what truly needs it.

Step 2 · Write the criteria before starting

The second piece is deciding, before the pilot, which result counts as good. If the criteria are set after seeing the results, they tend to bend to them.

Anthropic's documentation for those who build with its models asks for success criteria with four traits: specific ("sort requests correctly", not "good performance"), measurable (with numbers or well-defined scales), achievable (based on real references, not wishes) and relevant (aligned with what the business needs) [2]. It also suggests comparing against a reference —a baseline model or an earlier version— and measuring edge cases separately [2].

In boardroom language, the criteria fit in a table. This one is an example, with figures made up for illustration; each company's figures come from its Step 1:

The thresholds are illustrative: each company sets them according to the process, whoever is accountable for it and the risk limit it has approved. Two details of that table matter more than the figures. First, it separates high-impact events from minor errors: a tone that could be better gets corrected; sending one customer's data to another does not. Second, it has a column for stopping: if it is not written down which result stops the pilot, the pilot does not stop.

Step 3 · Test with real cases, including the hard ones

With the criteria written, a sample of real cases is prepared with the operation, one that resembles the work that comes in —for example, those of a normal month, in the proportion in which they arrive—, not the twenty from the demo. Three rules make it useful for deciding:

• Separate the cases for adjusting from the cases for deciding. The first are used to fine-tune instructions; the second are kept aside and only used at the end. Anthropic's documentation calls these held-out evals [2].
• Write down beforehand what counts as a correct reply, who grades it and how a disagreement between two reviewers is resolved.
• Decide in writing which data goes in: who can see it, what information is hidden or replaced for the test and who authorized that use. The fact that the operation has controls does not, by itself, mean the sample can go out to a test environment or to a vendor.

The generative AI profile from NIST, the United States standards and technology institute, is a guide intended for voluntary use that puts it this way in its measurement function: system performance is measured and demonstrated for conditions similar to the deployment setting, and the measures are documented [4]. OpenAI's guide also suggests logging everything while testing, to mine those logs for new test cases [3].

Within that sample it pays to set aside a group of hard cases —even if there are few, including the high-impact ones— and measure it separately: the ambiguous request, the one with two topics, the angry customer, the one that mentions a piece of data that is not in the system. That is where a pilot wins or loses the trust of the team that will use it.

Step 4 · Measure what it costs, not only what it gets right

A pilot can get a lot right and still not be worth it. Before scaling, it pays to look at four costs the demo does not show:

• Review time. If the person takes almost as long to review the reply as to write it, the saving is small.
• The cost of running the case. Use of the model, according to your contract or your infrastructure, plus a person's review. Multiplied by a month's real volume, that number can change the decision. The initial preparation is presented separately, so it is not mixed up with the cost of operating.
• The cases it hands to a person. It is good that the AI recognizes what it should not resolve; handing over almost everything means it is not saving work.
• The work of maintaining it. Someone has to review the results every month, adjust instructions and deal with whatever changes in the systems it takes data from.

Step 5 · Decide in writing: scale, adjust or stop

At the end, the result is compared against the criteria and one of three decisions is made, in writing:

• Scale, if it meets the agreed targets and stays within the approved risk limit.
• Adjust and repeat, if it comes close and there is a clear cause that can be fixed: an instruction, a missing piece of data, a type of request that is better left out.
• Stop, if it does not meet them and there is no clear cause. Stopping in time is also a good result: it is what prevents scaling a cost.

Among its suggested actions, NIST proposes to "Share results of pre-deployment testing" with those who have "system release approval authority" [4]. In boardroom language: the decision to scale is made by whoever is accountable for the operation, with the results document in hand, not with the memory of the demo. That same record names whoever is accountable for the process, states how an incident is reported and handled, and sets the next review. Risk limits are treated separately from savings or speed targets.

The signs that a pilot is not ready yet

Five questions for your next board meeting

1. How long does it take, how much does it cost and how many errors does today's work have, the work the pilot wants to improve? If there is no number, that is the first to-do.
2. Which result would make us scale and which would make us stop, and has it been written down since before starting?
3. Which cases was it tested with: hand-picked, or a real sample from a month, with the hard ones measured separately?
4. Were there high-impact events, and how much does each case cost adding up processing and a person's review?
5. Who signs the decision to scale, with which document, and who is accountable for the process once it is in operation?

If several answers are "I don't know", the pilot is not ready to be decided on yet; it is ready to be measured.

Where to start this week

Write your pilot's criteria on a single page, even if the pilot is already running. Four blocks:

• Today's work: volume, time, errors and cost in a normal month.
• The indicators: three to five, with today's value, the one that leads to scaling and the one that leads to stopping.
• The sample: where the test cases come from, who chooses them and which are the hard ones.
• The decision: who makes it, on what date and with which document.

If the page cannot be filled in, that already tells you what is missing before scaling.

What Hábil does

At Hábil we build custom AI that works with the data and rules of your systems.

If your pilot needs those exit criteria, the proposal is in Hábil AI. We choose with you a process where you are losing time, money or customers today, and we leave it running with an indicator, an exit criterion, and scope and cost agreed before we start, including the processing cost with its cap. Before it operates, it is tested with your real cases and an agreed exit criterion. The route is: diagnosis → proposal with scope, cost and risk → test with an exit criterion → operation. We can work with the AI you already have —ChatGPT, Copilot, Gemini or Claude— or with one installed on your servers; and anything that moves money or data is carried out with a person approving.

The conversation can start with your criteria page, even if it is half done: which process, how it is measured today and what result you expect. With that, we review together whether it makes sense to continue, adjust or start with a different process. Write to us on WhatsApp; to protect your information, do not share data about your customers or your systems through that channel: we will agree in the conversation on the channel for the case.

Request your first conversation, at no cost.

Consulted on 12 November 2026. Each reference carries its confidence: high (primary source read).