Walk into almost any large South African organisation and ask about their AI work. You will hear about a proof of concept. It ran well. Everyone was impressed. Then the conversation goes quiet.
The pilot is sitting on a laptop somewhere, or on a virtual machine nobody has switched off. It never reached production. The team has since moved on to a new pilot.
This pattern repeats across banking, mining, retail and security. The technology works. The deployment does not happen. Understanding why matters more than another vendor demo.
The demo solves the wrong problem
A pilot gets designed to impress a room. Production gets designed to survive a Tuesday.
Those are different jobs. The demo runs on curated data, on a quiet network, watched by people who want it to work. Production runs on whatever the operational systems produce, over links with real latency, watched by an operator on their fourth hour of a shift.
I have seen video analytics detect a person crossing a line with high accuracy in a pilot, then flood a control room with false alerts once it faced real weather, real lighting and cameras nobody had cleaned in eight months. Nothing was wrong with the algorithm. The pilot never tested the conditions the system had to live in.
If your pilot did not run for thirty days on production data with nobody babysitting it, you have not piloted anything.
Nobody costed the boring parts
The model is the cheap bit. The expensive bits are the parts nobody demos.
- Getting data out of the source systems on a schedule, reliably, with someone accountable when it stops.
- Storage and egress costs when the volume moves from a sample to the whole estate.
- Monitoring, so you know the model has drifted before your users tell you.
- Retraining, and the people who own it.
- Support in hours the business actually operates.
When those numbers arrive in the budget meeting for the first time, the project dies. Not because the numbers are unreasonable, but because they arrive as a surprise. Surprises lose budget fights.
Put the full running cost in the first business case, before the pilot starts. A project that survives an honest number at the beginning survives the year.
There is no owner after go-live
Ask who runs the model once it is in production. In most South African organisations the honest answer is nobody yet.
Data science sits under one executive. Operations sits under another. Neither has a mandate for a system that needs both. So the model goes live with no clear owner, degrades quietly, and gets switched off within a year.
The fix is unglamorous. Name the owner before you build. Give them budget, an on-call path and a performance measure tied to the outcome, not to model accuracy. Accuracy is an input. The business result is the measure.
The problem was chosen backwards
Too many programmes start with the technology and hunt for a use case. Someone buys a platform, then the team goes looking for something to point it at.
Start at the other end. Find the process that costs the most in time, error or risk, and check whether a model changes the economics. If the answer is no, walk away and say so publicly. A programme that kills its own weak ideas earns trust for the strong ones.
The best AI deployments I have seen in this country were narrow and unfashionable. Automated quality checks on a production line. Number plate recognition tied to an existing access control system. Document classification in a claims process. None made a conference keynote. All still run.
What to do differently
Five things separate the programmes that ship from the ones in the graveyard.
- Pick a process with a measurable cost, not a technology with a budget.
- Run the pilot in production conditions for at least a month, unattended.
- Cost the full running year up front, including people.
- Name the production owner before a single line of code gets written.
- Set the success measure in business terms and publish it internally.
None of this is difficult. It is only unpopular, because it slows the exciting part down and forces early honesty about cost.
South African teams are good at making things work under constraint. The constraint here is not talent or technology. It is the gap between a demo and an operating system, and that gap gets closed by planning, not by a better model.