What a controlled AI pilot should measure

Most pilots cannot fail

That sounds like a good thing. It is the reason so many of them lead nowhere.

A pilot with no agreed threshold produces a demo, some enthusiasm, and a decision made on impression. Six weeks later nobody can say whether it worked, so the discussion turns on who is most confident rather than on what happened. The system either ships on optimism or dies on politics.

A pilot that can fail is one where the criteria were written down before it started and someone was willing to act on them.

Decide the criteria before you build

The single highest-leverage thing in this entire piece: agree the success threshold before any code is written, in writing, with the person who owns the decision.

This is uncomfortable, which is why it gets skipped. Committing to "the system must agree with our specialists on at least 80% of cases" means accepting that 79% is a failure. Teams avoid that number precisely because it has teeth.

Without it, the pilot measures whether people liked it.

The four things worth measuring

1. Agreement with the current process

Run the system alongside the existing process, on the same real cases, and measure how often they agree.

This is the most informative measurement available in an early pilot, because it needs no outcome data and no waiting. It gives you a number in days rather than quarters.

The disagreements are the valuable part. Sort them into three buckets:

• System wrong. A defect to fix.
• Human wrong. Genuine value, and the thing worth building for.
• Both defensible. The most common bucket, and the one that reveals your criteria were underspecified.

That third bucket usually dominates early, and working through it is how the decision model actually gets defined.

2. Where the human ends up spending time

Measure time-on-task before and during, not just throughput.

The realistic near-term benefit of most decision systems is not that decisions get made faster. It is that the assembly work disappears and the person spends their time on judgement instead of on gathering. Those are different things, and only one of them shows up in a throughput metric.

If a pilot removes two hours of data-gathering and adds twenty minutes of reviewing recommendations, that is a large win that a naive "decisions per day" measure will report as marginal.

3. Whether the controls actually hold

A pilot is the cheapest place to discover that a guardrail does not work.

Measure:

• How often output was held by a policy, and whether the holds were correct
• How often approvals were requested, and the median time to decide
• How often the system escalated, and whether escalation reached the right person
• How often something unmapped occurred

A pilot with zero holds and zero escalations has not been tested. It means the cases were too easy or the constraints too loose, and neither justifies widening autonomy afterwards.

4. Outcome quality, where it is available

Where outcomes arrive within the pilot window, measure them. Where they do not — which is common in clinical, credit and long-horizon operational decisions — say so explicitly rather than substituting a proxy and forgetting the substitution was made.

A pilot that cannot measure outcomes is still worth running. It just cannot claim outcome improvement, and the write-up should say that in as many words.

What not to measure

The last one deserves emphasis. The most confident opinions in a pilot review frequently come from people who never used the system, and they are weighted heavily because of seniority.

A structure that works

1. Name the decision. One decision, one owner. Pilots that improve "our processes" measure nothing.
2. Write the success criteria and the threshold. In writing, agreed by the owner, before building.
3. Define what a failure means and what happens then. If the answer is "we would extend the pilot", it cannot fail and you should fix that now.
4. Capture a baseline. How the process performs today, measured before the system exists. Without it you are comparing against memory.
5. Run narrow and real. A small slice of genuine cases beats a broad slice of synthetic ones. Synthetic data does not contain the malformed records that break things.
6. Run alongside, not instead. Parallel running is what turns a demo into evidence.
7. Instrument the controls, not just the output.
8. Review against the written criteria. Read them out. The temptation to reinterpret a threshold after seeing the result is strong and should be resisted publicly.

The honest failure modes

Three ways a pilot succeeds and the system still fails afterwards.

The pilot was staffed differently. The best specialist supervised every case. In production it will be whoever is on shift. Measure with the people who will actually operate it.

The pilot ran at a tenth of the volume. Approval gates that work at twenty requests a day collapse at four hundred. Thresholds set during a pilot are almost always wrong at production volume, and should be reviewed explicitly at scale-up rather than inherited.

The pilot had no failures because the constraints were loose. Then the guardrails were never exercised, and the first real test happens in production with real consequences.

Where this sits

The controlled pilot is stage three of the engagement model, between constraint assessment and production validation. It is deliberately narrow, and it is the stage where the expensive surprises are supposed to surface — cheaply, on a small scope, before anyone has committed to an architecture.

No fixed duration is quoted for it, because the honest answer depends entirely on whether data access exists and whether the constraints have been written down. Both are usually the long pole, and neither is a modelling problem.