How to decide whether an AI pilot worked

An AI pilot has worked when it gives the sponsor enough evidence to make the next investment decision. That decision might be to continue with a bounded rollout, change the workflow and test again, or stop.

Agree the baseline, representative work, acceptance criteria and unacceptable failures before testing. Then inspect what happened to the whole task, including the work people still have to do. A convincing demonstration establishes less than a team using the system successfully under ordinary conditions.

This distinction matters when a pilot is technically promising but commercially uncertain. It can justify another experiment without justifying production.

Decide what the pilot must establish#

Start with a sentence the sponsor and workflow owner can both approve:

We are testing whether this system can prepare useful invoice drafts for finance review, reduce total handling effort, and preserve the decisions that require a person.

This is an illustrative objective. A real one needs the scope, evidence required, responsible people and review date. If you have not chosen the task yet, start with how to choose your first AI workflow.

The distinction between delivering something and realizing its benefits predates AI. Research published by the Project Management Institute describes target benefits as part of the initial business case and the basis for later performance review, with explicit baselines, measures and targets. Apply that discipline to the pilot: what useful change would justify its cost?

“Build an invoice assistant” is a deliverable. “Let finance handle the same work with less checking and no loss of control” is a claim to investigate. The pilot needs evidence for the second before the first becomes a reason to invest further.

Combine business evidence with engineering evidence#

Three perspectives help answer different parts of the question.

Management consulting asks whether the organization can turn a capability into value. McKinsey's survey on rewiring organizations for AI associates workflow redesign and adoption practices, including well-defined performance measures, with reported business impact. Those are survey associations, not a guarantee for an individual project. They nevertheless direct attention beyond model quality.

AI engineering asks whether the system does the intended job. Anthropic's evaluation guidance separates an agent's transcript from the resulting state: saying a booking was made differs from a reservation existing. For invoices, a persuasive explanation differs from a correct draft in the review queue.

Embedded delivery adds observation of the customer's actual work. Sierra's account of agent engineering describes engineers working with customers to understand domain rules and integrate underlying systems. For a sponsor, the useful question is whether that understanding survives handover. Can the customer's team operate the workflow when its original builder is absent?

A business case cannot establish correct behavior. A test suite cannot establish adoption. A successful week with an embedded engineer may conceal support effort the customer will later inherit. Collect evidence for each claim separately.

Compare with the current way of working#

Observe the existing task over a period that includes ordinary variation. Record what enters the process, what counts as finished, who touches it, how much active effort it takes and where work waits.

For invoice intake, distinguish time spent reading a document from time spent finding the purchase order, checking a duplicate, correcting a draft and resolving an exception. Separate active handling time from elapsed turnaround. A faster extraction step may leave the queue unchanged.

BCG's analysis of AI pilots and business value makes this broader point: faster tasks can leave the surrounding process and cost structure intact. Its examples are reported by BCG; they are not Hartro results. The practical implication is to measure the outcome the business needs, alongside the activity the system accelerates.

Use the same task boundary when comparing assisted work. Include review, correction, retries, exception handling and operating support. Count setup and training separately so a stable operating estimate does not hide the cost of getting there. Our worked business case for AI project cost and ROI explains how these assumptions affect the investment decision.

Test work that resembles the intended scope#

A development case helps engineers improve the system. An acceptance case helps the sponsor decide whether the agreed behavior has been demonstrated. Preserve fresh cases for that decision; repeatedly inspecting and tuning against every example makes the result less informative.

Representative cases should reflect the mix of work the system is expected to receive. Deliberately difficult cases answer an additional question: how does it behave when something important goes wrong? Report those groups separately. An exception-heavy challenge set does not estimate everyday workload; an easy sample does not establish exception handling.

For a synthetic invoice exercise, expected decisions might include:

These are illustrative expectations for an unrun scenario. They are neither observed results nor a complete finance policy.

Have the domain owner resolve disputed expectations. Record what the case selection omits, including document formats, languages and unusual suppliers. There is no universal test-set size or accuracy threshold that makes every workflow ready. Evidence requirements depend on the scope, variation and consequences of error.

Keep the sponsor's scorecard inspectable#

A useful scorecard connects a measure to its baseline, target, observed result, evidence, remaining uncertainty, owner and next decision. Targets must be agreed for this workflow before acceptance testing; the example below supplies no measured baseline or pass rate.

The named roles are proposed responsibilities, not appointments. Replace them with accountable people. Attach results to the version, environment and cases tested so a later change does not inherit an earlier pass.

For implementation detail, evaluation-driven development covers cases and graders. Completion evidence explains how to connect claims to observable results.

Observe adoption and the work around the tool#

Ask people to use the proposed workflow under bounded, approved conditions. Watch where they leave it, repeat checks elsewhere, ask the builder for help or quietly return to the old process. Usage alone is insufficient if every output is being rebuilt manually.

BCG's capability-building guidance distinguishes learning concepts, applying them in real work and embedding new practices. A training session therefore cannot establish sustained use. Equally, low uptake deserves investigation: the obstacle could be access, timing, unclear responsibility or an interface that adds work.

Count the support supplied during the pilot. If an embedded engineer resolves every exception, document the effort and test who will take over. A workable fallback needs a person, a queue and a recovery procedure, including reconciliation of partially completed work.

Make a bounded decision#

Continue when evidence supports the agreed next scope, important failure conditions have been addressed, the economics remain plausible and an operational owner accepts the responsibility. State the boundaries of the next rollout and what will still be checked.

Change and retest when the problem remains worthwhile but a specific gap prevents acceptance. Name the gap, proposed change, budget and next review. If criteria change because the team misunderstood the work, explain why and identify which earlier results are no longer comparable.

Stop or defer when the value is too small, review effort consumes the benefit, required access is unavailable, or unacceptable behavior remains unresolved. Retain what was learned so the same uncertainty does not fund another indistinguishable pilot.

A pilot still leaves production questions. Thoughtworks' evaluation framework distinguishes controlled evaluation from user acceptance and live observability. Production introduces changing inputs, load, failures and ongoing support. Record the remaining uncertainty and who will monitor it.

The decision record can be short: what was tested, what the evidence supports, what remains unknown, what happens next and who owns it. If those terms are unclear before the build, an AI workflow assessment can help define the decision the pilot needs to support.

Sources checked on 21 October 2026. The invoice scenario, scorecard and expected outcomes are illustrative and have not been run; no pilot performance or client results are claimed.