How to choose a first AI pilot

There is a strong pull towards making the first AI project the most important one. The reasoning seems sound: if you are going to spend the effort, spend it where the money is.

It is the wrong instinct. The first pilot’s job is not to deliver the largest return. It is to teach you, quickly and cheaply, whether this class of tool works on your data, in your process, with your people. A project that delivers a large return but leaves you unable to say why has taught you nothing you can build on.

The four tests

1. Can you tell whether the output is right?

This is the test that matters most, and it eliminates more candidates than the other three combined.

Extracting the invoice number, date and total from a supplier document passes: the document is right there, and anyone can check in seconds. Routing an incoming email to the correct department passes: the person receiving it knows immediately whether it belongs to them.

“Summarise this month’s customer feedback and tell us what to prioritise” fails. The output will read plausibly whether or not it is any good, and nobody will be able to tell the difference. That is precisely the situation where an AI system quietly produces confident nonsense for six months.

2. Can you count the outcome?

Agree the number before you start, and agree what result would make you stop.

Good measures are boring and specific: the proportion of extracted fields a reviewer accepts unchanged, the share of items routed correctly first time, minutes from receipt to first response. Bad measures are things like “improved efficiency”, which nobody will contest and which therefore proves nothing.

Write down, in advance, the result at which you would stop. A pilot with no failing threshold cannot fail, and a pilot that cannot fail cannot succeed either.

3. Is there a person between the output and the consequence?

For a first pilot, a person should approve the output before it reaches anyone outside the team.

This bounds the damage while you are still learning what the system gets wrong. It also produces your quality measure for free: the rate at which the reviewer edits or rejects is exactly the number you need, and you get it without building any evaluation harness.

There is a legal dimension too. Section 71 of POPIA restricts decisions based solely on automated processing where they materially affect someone. A human reviewer is not only prudent, it is often what keeps the design inside the law. See POPIA and AI.

4. Does it happen often enough to matter?

The task should run at least weekly, ideally daily. Two reasons: the effort will not pay back on something that happens quarterly, and you will not accumulate enough cases to judge quality with any confidence.

Fifty cases a week gives you a usable signal within a month. Five cases a month gives you an anecdote.

Candidates that usually pass

Candidates that tempt and disappoint

A customer-facing chatbot

Highly visible, which is exactly the problem. It fails in public, in front of the people whose opinion of you is most expensive to repair, and quality is hard to measure because most dissatisfied users leave without telling you. It is a reasonable third project and a poor first one.

Anything described as a strategy assistant

No checkable output, no countable outcome. It will produce material that reads well and cannot be evaluated. You will not be able to tell whether it helped.

Replacing a role rather than a task

A role is a bundle of dozens of tasks, most of which are not automatable and some of which nobody has written down. Framing it this way also guarantees that the people whose cooperation you need will work against it, and they are usually right to.

Anything requiring data you have not seen

If the pilot depends on a dataset nobody has opened recently, the pilot is really a data project wearing a costume. Do the data work explicitly and honestly, then reconsider.

Running it

• Fix an end date, four to eight weeks out. Open-ended pilots do not end, they fade, and nobody ever decides anything.
• Assemble the sample first. Fifty to a hundred real cases covering the usual variation, including the awkward ones. Excluding the messy cases produces a pilot that succeeds and a rollout that fails.
• Have the reviewer record why they rejected something, not just that they did. The pattern in the rejections is the most valuable output of the whole exercise.
• Decide on the evidence at the end. Widen, adjust, or stop.

Stopping after a pilot that did not work is a good outcome and should be said out loud at the start, so that stopping does not feel like anyone failing. The alternative is discovering it after the rollout, which costs considerably more and tends to end the appetite for trying again.