Every major bank in East Africa has a generative AI initiative. Most of them consist of a pilot, a steering committee, and a very impressive demo. Almost none of them are in production, handling real customer transactions, with real accountability for the output.
This is not a criticism — it is a description of a normal technology adoption curve, and generative AI is genuinely difficult to deploy responsibly in a regulated financial institution. But the gap between the demo and the deployment is widening, and the banks that close it first will have a meaningful advantage in both cost and customer experience.
Where the demos live
The gen-AI pilots we see most frequently in East African banking fall into three categories. Customer service chatbots — typically bolted onto existing digital channels, handling FAQs, often with a hard handoff to a human agent for anything complex. Internal knowledge assistants — staff tools that search policy documents, compliance manuals, and product catalogues. Document processing — credit application summarisation, contract review, and KYC document extraction.
All three categories have real value. The chatbot pilots we've reviewed typically resolve 35–50% of enquiries without human intervention. The internal knowledge tools measurably reduce the time new relationship managers spend looking things up. The document processing tools, where they run, cut credit analyst time on routine applications by 40–60%.
The problem is not the pilots. The problem is what happens after the pilot ends.
Why pilots stall
Three patterns account for the majority of stalled gen-AI pilots in banking we've reviewed.
Data quality is worse than expected. Gen-AI models are only as good as the data they're grounded in. In most banks, the product and policy documentation is inconsistent, partially outdated, and spread across SharePoint, email threads, and PDF folders with no version control. The pilot runs on a curated subset. The production deployment would need to run on everything — and everything is a mess.
Regulatory uncertainty paralyses the governance conversation. The CBK and other regional regulators have issued guidance on AI in financial services, but it is principles-based rather than prescriptive. Nobody is sure exactly what explainability, fairness testing, and human oversight requirements mean in practice for a deployed gen-AI customer service tool. Rather than work through the uncertainty, most banks freeze.
The pilot team disbands. The three engineers who understood the deployment architecture go on to other work. The business sponsor gets a new brief. The institutional knowledge of what was built and why evaporates. When the bank returns to the initiative six months later, it starts over.
We tell banking clients this consistently: before you deploy a gen-AI customer-facing application, you need to be able to answer "what is the authoritative source of truth for [product X] terms and [policy Y]?" If the answer involves a committee, a SharePoint search, or "depends," you have a data governance problem that will corrupt any gen-AI deployment on top of it.
What the 20% do differently
The institutions that move from pilot to production share four characteristics.
They scope narrowly and go deep. Rather than building a general-purpose AI assistant, they pick one use case — typically internal staff support or a specific document-processing workflow — and take it fully to production before expanding. Shallow breadth across ten use cases is much harder to govern than depth in one.
They treat data governance as a pre-requisite, not a parallel track. The documentation rationalisation work happens before the AI deployment, not alongside it. This adds two to four months to the project. It also means the deployment actually works.
They appoint an accountable product owner. The gen-AI application is treated as a product, with a named owner who is accountable for accuracy, user satisfaction, and regulatory compliance. This person survives the pilot. They own the iteration roadmap. The institutional memory stays.
They build an explicit human-in-the-loop model before deploying. For any customer-facing application, they define exactly which decisions the AI makes alone, which decisions it recommends and a human approves, and which decisions it explicitly excludes. This document exists before launch, is reviewed by compliance, and is updated when the model changes.
Where the real value is
The highest-value gen-AI use case in East African banking today is not customer-facing — it's credit. Specifically, the summarisation and structuring of SME loan applications: financial statement extraction, business description normalisation, sector benchmarking, and risk narrative drafting. A credit analyst who spent three hours on a routine SME application can process it in under an hour with a well-designed AI assistant. At scale, across a book of thousands of SME applications per month, the economics are compelling.
This use case also happens to be lower-risk from a regulatory standpoint: the AI assists the analyst, it does not make the credit decision. The human remains accountable. That combination — high operational value, clear human accountability — is the sweet spot for gen-AI deployment in a regulated institution today.
Drawn from advisory work on AI strategy and deployment across six East African banking institutions, 2025–2026.