Most AI pilots in small business succeed and then quietly die. Not because the technology failed, but because nobody asked what happens after the pilot works.
The pattern is consistent enough to predict.
The shape of the failure
Someone motivated builds a proof of concept. It’s genuinely impressive. It gets demonstrated to the leadership team, who are pleased. A decision is made to roll it out.
Then it stalls, and six months later nobody mentions it. When you ask, you get a vague answer about priorities.
What actually happened is that the pilot proved the wrong thing. It proved the technology could produce a good output on a curated example. It did not prove the organisation could operate it.
The four questions pilots skip
1. Who owns it on an ordinary Tuesday?
Pilots are built by the enthusiast. In a small business that’s usually someone with a real job doing this on top of it.
Production means someone monitors quality, handles the cases where it goes wrong, updates it when the underlying process changes, and answers questions from confused colleagues. If that person is the enthusiast, you have created a dependency on one person’s goodwill. If it’s nobody, the thing degrades silently until people stop trusting it.
2. What does wrong look like, and who notices?
This is the question that separates serious deployments from theatre.
A system that summarises customer emails will occasionally produce a summary that misses the crucial sentence. A system that drafts quotes will occasionally get a number wrong. These are not edge cases; they are the expected behaviour of a probabilistic system.
The right question is not “how do we stop this happening”, because you can’t entirely. It’s “when it happens, does a human catch it before it reaches a customer, and how?” If the answer is that the reviewing human is under time pressure and rubber-stamps everything, your review step is decorative.
3. Where is the data going?
In a pilot, someone pastes a few real examples into a tool to see if it works. In production, that becomes a systematic flow of your business data through a third party.
For many small businesses this is fine, provided it’s a deliberate decision with an acceptable use position understood. For some — anyone handling health information, children’s data, or client-confidential material under a contractual obligation — it is not, and the obligation exists whether or not anyone thought about it during the pilot.
4. What is the actual saving?
Not the theoretical saving. The realised one.
Saving four minutes on a task performed twice a day saves eight minutes a day, which does not translate into any recoverable capacity. It might still be worth doing, because eliminating an annoying task has real value for morale. But it is not a business case, and presenting it as one leads to disappointment when the efficiency doesn’t show up anywhere.
The deployments that stick tend to attack either a genuinely high-volume task or a task that is a bottleneck because only one person can do it.
What a better pilot looks like
Run it on the worst inputs, not the best ones. Everyone demos with a clean example. Run it on the messy email from the difficult client, the badly scanned invoice, the request that contradicts itself. That’s the real workload.
Run it for longer than feels necessary, ideally across a full business cycle, so you see what happens at month end.
Have someone other than the builder operate it for a fortnight. This surfaces every undocumented assumption immediately.
And decide the kill criteria in advance: what level of error rate, or what category of mistake, means we stop. Deciding that beforehand is much easier than deciding it after something embarrassing has reached a customer.
The uncomfortable bit
A meaningful proportion of small business AI projects should be abandoned after the pilot, and that is a success, not a failure. You spent a small amount to learn the thing did not fit your operation.
The genuine waste is the project that neither dies nor lands: half-deployed, half-trusted, quietly consuming attention. Kill those faster.