Why most AI pilots die at the deployment site.

The demo works. The pilot gets praised. A funder is pleased. Then the tool reaches a real site — where the power flickers, the signal drops, and the phones are five years old — and within a few weeks, quietly, nobody is using it anymore.

We've watched this happen for the better part of a decade, across six countries. It's rarely because the AI was bad. It's because the pilot was tested in the wrong place: a room with good wifi, new laptops, and the people who built it sitting right there. None of those things exist at the site where the work actually happens.

The demo is not the test

A demo answers one question: can this work at all? That's worth knowing, but it's the easy question. The hard question — the one that decides whether anyone still uses the tool in three months — is whether it works on a slow phone, in a building where the electricity comes and goes, in the third language your programme runs in, operated by someone who has never met the people who built it.

If that question isn't asked until the end, it gets answered by the field, and the field is unforgiving. By then the budget is spent and the pilot is “done.”

What actually kills them

The causes are boringly consistent. In rough order of how often we see them:

• Connectivity. The tool assumes the internet is there. At the site, it isn't — not reliably, not all day. Anything that stalls without a signal stops being used.
• Power. It assumes mains electricity. The site runs on solar or a generator, with gaps. A tool that needs to be plugged in and charged for hours doesn't fit the day.
• Devices. It was built and tested on a new phone. The staff have old, shared, low-storage ones. It's slow, or it won't install.
• Language. It works beautifully in English. Half the users don't work in English.
• Ownership. No one on the ground can fix a small problem or answer a small question, so the first snag becomes the last time it's opened.
• Trust. When an AI tool is confidently wrong once, in front of a colleague, people stop trusting it — and quietly go back to what they did before.

Notice that only the last two are really about “AI.” The rest are about the conditions the tool was dropped into. That's the whole point.

How to build so it survives

None of this is exotic. It just has to be decided at the start, not bolted on at the end.

• Make the site the spec. Before writing anything, get honest about the worst site it has to work at — the power, the signal, the devices, the languages — and design for that, not for the office.
• Offline-first, not offline-someday. Assume no connection and make it sync when one appears. A dropped signal should be a non-event, not a dead end.
• Fit the power that's there. Design around solar and generators, with the gaps they come with — not an assumption of steady mains.
• Test on the real phones. The old, shared, nearly-full ones. If it's painful there, it's dead there.
• Give it a local owner. Someone on the ground who's trained to run it, fix the small things, and knows when to call. If your team can't operate it without you, it isn't finished.
• Earn trust, don't assume it. Be honest about what the AI can and can't do, keep a human in the loop where it matters, and make it easy to check.

If it works in the office but not at the site, it isn't done. The field is the test — everything before it is rehearsal.

The organizations that get real value from AI aren't the ones with the cleverest models. They're the ones who treated the deployment site as the actual specification from day one, and built inward from there. It's less glamorous than a good demo. It's the difference between a pilot that gets a nice write-up and a tool that's still being used a year later.

This is the thinking behind how we run an AI Pilot Build and a Field Deployment — designing for the hardest site from the first line, so the tool survives contact with the real world. If that's the part your last pilot got wrong, that's usually the part worth fixing first.