What an AI pilot must prove before you fund the next stage

Write down the decision the pilot informs

Many pilots are approved with a goal such as finding out whether AI can help with supplier invoices. Twelve weeks later the team presents a demo, a survey and a token bill, and the steering group still cannot tell whether to spend more.

Name who makes that decision, what they would fund next and what evidence would change their mind. Then write criteria that do not depend on any product. Anthropic's 2024 guidance on building agents recommends the simplest solution that works, sometimes no agent at all. Tool-neutral criteria let you test that, because a rules engine, a single model call and an agent can run against the same cases and be scored on the same sheet.

Four things a process pilot has to show

• Quality on your own cases. The system handles a held-back set of real past cases at an agreed level, judged by the people who own the process rather than by a public benchmark.
• Consistency. It succeeds on repeated runs, not once. Anthropic's evaluation guidance separates pass@k, at least one success in k attempts, from pass^k, success on all k attempts. If each run independently had a 75 percent chance of being right, all three of three runs would succeed only about 42 percent of the time. Real runs are often correlated, so measure repeated runs instead of calculating them.
• Cost per handled case. The FinOps Foundation describes moving from cost per token towards outcome measures such as cost per case resolved. Include model and platform costs, review time and rework, and compare the total with what a case costs today.
• Failures you can catch. When the system is wrong, the error is flagged, routed to a person or stopped by a control before it reaches a customer or a ledger. Record which errors are tolerable and which are not.

An acceptance sheet for a hypothetical invoice pilot

Criteria are useful when two people would score the same result the same way. Anthropic's documentation asks for criteria that are specific, measurable, achievable and relevant, usually across several dimensions. The sheet below is a hypothetical example for matching supplier invoices to purchase orders. Every number is an illustrative assumption set by the process owner, not a benchmark.

1. 1

   Test set

   400 invoices from the last two quarters with known outcomes, spread across supplier types and including credit notes, partial deliveries and scanned documents. None of them is used while prompts are developed.

2. 2

   Quality

   At least 95 percent of clean matches confirmed correctly, and every mismatch above 500 euros flagged. A missed mismatch above that amount is a critical error, and the acceptable number of critical errors is zero. Zero critical errors in 400 test cases does not mean zero risk in production, especially for rare case types, so high-value mismatches still go to a person.

3. 3

   Consistency

   Each test case runs three times, and a case passes only when all three runs agree with the known outcome.

4. 4

   Cost

   The cost per handled invoice, including model calls, platform costs and the clerk's review time, stays below the baseline measured in the current process.

5. 5

   Control and ownership

   The system releases no payment. Every flagged invoice reaches a named queue with its reason attached, and a person in finance operations has agreed to own that queue if the pilot proceeds.

The sheet also shows what the pilot does not test, such as rollout across several countries. That belongs to the next stage, and writing it down keeps the pilot from being judged on it.

Measure the current process before the first prompt

Cost and error criteria need a baseline: how long a case takes today, how often it goes wrong and what a correction costs. Google's Rules of Machine Learning put metrics before the first model, partly because history that was never recorded cannot be recovered. A week of timed manual work costs less than arguing about estimates later.

Use the baseline for comparison, not as the target. The Google SRE book warns against choosing objectives purely from current performance, because that fixes whatever the system does today. The target should come from what the business needs, such as the error level finance can accept.

Where pilot results mislead

• Tuning on the test set. When the people writing prompts can see the evaluation cases, the score measures how well those cases were memorised. Use the held-back set only for scoring.
• One average over mixed cases. A good overall rate can hide a case type that fails every time, so report results per case type.
• Scores nobody has read. Anthropic recommends reading transcripts from many trials, because a grader can reject a valid answer or accept a wrong one. Have the process owner read a sample before the steering group sees a number.

Agree what each result will fund

Decide in advance what each outcome leads to. If every criterion is met, the next stage funds the work that turns a pilot into a service: monitoring, an owner and a support path. If quality is met but cost is not, the next stage tests a cheaper design, such as a smaller model or a narrower scope. If quality misses on the cases that matter, stop or change the approach, and keep the test set for whatever comes next.

Acceptance criteria for each software changeWhen an AI project should stop or change directionFrom pilot to production