A pilot that works is not proof the technology works
The OECD's 2025 survey of government AI use found that 43% of deployments remain stuck at pilot stage. That number is not a snapshot of technology still maturing. It is a measurement of institutions that built something, watched it work in a controlled environment, and then failed to carry it into production.
Pilot environments have curated data, dedicated vendor support, and forgiving timelines. Production has audit requirements, compliance obligations, connectivity gaps, and citizens who expect the system to be right the first time. A pilot proves a system can work when insulated from reality. It does not prove the institution can run it once that insulation is gone.
Across African public-sector digital initiatives, six failure modes account for most of the gap between pilot and production. None of them are primarily technical.
1. Technology-first thinking
Most digital initiatives start with a request for proposal that specifies server capacity and dashboard features. It rarely specifies who will use the output, for which decisions, or against what evidence standard. When the tool is the starting point instead of the institutional problem, the resulting system optimizes for demo day, not for the decision it was meant to support.
2. Ownership ambiguity
IT owns the servers. Operations owns the process. Policy owns the mandate. In most pilots, no single entity owns the evidence the system produces — and when funding expires, accountability evaporates along with it. A system with three departments' fingerprints on it and no named owner does not survive its first leadership transition.
3. Evidence gaps
A dashboard is not evidence. Evidence has lineage: it can be traced from the number on screen back to its source data, the method used to collect it, and every transformation applied along the way. Pilots frequently produce dashboards that look authoritative and cannot answer a basic audit question — where did this number come from, and can you show your work.
4. Pilot dependency
Treating the pilot as the proof, rather than as a test, is one of the most expensive mistakes in African public-sector technology. A pilot's forgiving conditions — clean data, vendor engineers on call, generous timelines — are exactly the conditions production will not offer. Confusing the two means budgeting for a rollout that assumes problems the pilot never had to face.
5. Governance after deployment
Access control, data classification, retention policy, and audit logging should be design constraints from the first architecture diagram. Instead, they are frequently bolted on after go-live, once auditors or regulators ask questions the system was never built to answer. Governance retrofitted onto a live system costs more, covers less, and arrives after the decisions it was meant to protect have already been made.
6. Success without succession
This is the most common failure mode in donor-funded environments, and the most expensive. The pilot team completes its contract and leaves. The dashboard stays live, but no one remaining in the institution can explain what the numbers mean, validate them, or trace an output back to its source. The institution is left holding a system it cannot operate — poorer, having spent budget and credibility on a capability it cannot sustain.
The pattern underneath all six
Every one of these failure modes is a governance failure, not a technology failure. The fix is not a better vendor or a bigger budget — an institution with a small budget and clear evidence rules will outperform one with a large budget and none. The fix is establishing ownership, evidence standards, and graduation criteria before the pilot starts, not after it succeeds.
That is the argument for governance before scale: build the institutional capability to trust, audit, and sustain a system before you decide whether to expand it.