From Data Silos to AI Ready: What It Takes, and What It Returns

On the numbers in this document. Every case here is a worked model, not a customer. No engagement is described. Each model states its inputs so you can replace them with your own, and each is presented twice: a gross case that values all released time, and a conservative case that only counts what a finance team would actually book. The gap between those two is usually a factor of two or three, and pretending otherwise is how AI business cases lose credibility in the second meeting.

Part 1: What silos actually cost

Start with a specific afternoon rather than a statistic.

The relationship manager

Wanjiru manages a book at a Kenyan commercial bank. A customer calls, wants to discuss expansion, and asks what the bank can do for them. Wanjiru needs the full relationship before she can answer.

She checks core banking for balances. Five minutes. She emails the credit department for loan detail and waits, then reads what comes back. Twenty five minutes. She logs into a separate portal for the M-Pesa Paybill statements. Ten minutes. She searches her mailbox for the last conversation. Fifteen minutes. She checks the CRM for relationship notes. Five minutes. She assembles it into something she can talk from. Twenty minutes.

Eighty minutes, and none of it was analysis. All of it was retrieval.

She does this ten times a week.

The monthly close

The CFO of a manufacturer asks for the cash position including M-Pesa collections. The finance team exports bank statements, exports the Daraja Paybill statements, exports Sage, and then spends two to three days matching them in Excel. The discrepancies that surface are real and take another day to chase.

By the time the number reaches the board it describes a month that ended eleven days ago.

The product blind spot

A fintech’s product team wants to know what customers complain about most. Complaints are in Zendesk. Feature requests are in the Play Console. Pricing objections are in sales call recordings on individual phones. Churn reasons are in individual inboxes. Sentiment is on X and Facebook.

Nobody can answer the question, so the roadmap gets set by whoever argues most confidently in the room.

Modelling the cost without inventing it

The figure in circulation for this, including in earlier drafts of this material, is KES 18.5M to 85M per enterprise per year. That range is a model, not a measurement, and it is worth taking apart because two of its components are much softer than they look.

Build your case on the firm rows. A CFO who finds one soft number in your model will discount every number in it, including the correct ones. The firm rows alone are usually enough.

For most organisations in this market, retrieval time is the single largest recoverable line, and it is the one nobody measures because it is distributed across everyone’s day in fifteen minute pieces.

Part 2: RAG, and the mistake almost everyone makes with it

What it is

Retrieval augmented generation lets a model answer from your documents instead of from its training data. Before answering, the system searches your content for passages relevant to the question and puts them in front of the model. The answer comes back grounded in your material, with citations.

That is genuinely useful, and it is why RAG became the default architecture for enterprise AI.

What it is not for

Here is the mistake, and it is close to universal.

RAG is a technique for unstructured text. Most of the questions African enterprises want answered are structured queries against systems of record.

Consider the question that opened the last version of this article: “What is our M-Pesa collection pattern for the top 10 customers?”

That is not a document search. It is an aggregation over a transaction table, grouped by customer, ordered by volume, across a date range. If you answer it by embedding M-Pesa statements into a vector database and retrieving the ten passages that look most similar to the question, you will get an answer that is confidently, plausibly and unpredictably wrong. Vector similarity has no concept of completeness. It cannot know it missed a customer. It cannot sum.

The same applies to most of what finance and operations actually ask:

Roughly speaking: numbers come from connectors, narrative comes from RAG, and the interesting queries need a router that knows which is which and can combine the results.

Getting this wrong is the most common cause of a disappointing enterprise AI pilot. The team indexes everything into a vector database, demos beautifully on a question about a policy document, then watches it produce a wrong revenue figure in front of the CFO. Confidence never recovers.

What RAG is genuinely good at

Do not read the above as dismissive. On the right material RAG is transformative, and African enterprises have a great deal of the right material: contracts, board papers, credit assessment notes, correspondence, policy documents, support histories, meeting records, and years of accumulated institutional knowledge sitting in file shares that nobody can search.

That corpus has never been queryable. Making it queryable is the actual prize.

Part 3: The architecture

   ASSISTANT (Copilot, Claude, internal agent)
              │  natural language
              ▼
   MSHARTI CONTROL PLANE
   authenticate · authorise · scope · log
              │
              ▼
        QUERY ROUTER
      ┌───────┴────────┐
      ▼                ▼
  CONNECTORS        RAG INDEX
  (structured)      (unstructured)
      │                │
      │                ├── document processor
      │                ├── chunker
      │                ├── embedder
      │                └── vector store
      ▼                ▼
  M-Pesa Daraja     Contracts, email, tickets,
  KRA GavaConnect   assessment notes, board papers,
  Sage 300          policies, transcripts
  Core banking
  SACCO core
  Salesforce
      │                │
      └───────┬────────┘
              ▼
       RESPONSE ASSEMBLY
       redaction · citation · confidence

Msharti provides the pre-built connectors on the structured side of that diagram. The RAG side is where most of the implementation effort in a new deployment goes, because it is the part that depends on your specific documents.

The router is the component that decides whether this works

Route by intent, and be conservative about it. When the router is unsure, it should run both paths and label the sources, rather than guess.

Three routing rules worth encoding from day one:

1. Anything asking for a number, total, count, or comparison goes to a connector. If no connector can answer it, say so rather than falling back to retrieval. “I cannot compute that from available systems” is a good answer. A wrong total is not.
2. Anything asking what was said, agreed, decided or reported goes to RAG.
3. Anything naming a specific entity goes to both, with the connector result establishing the facts and retrieval supplying context.

Part 4: Chunking financial documents

This section is here because the standard advice fails badly on the documents this market actually holds.

The usual recipe is 256 to 512 word chunks with 50 word overlap. That works for prose. It destroys tables.

An M-Pesa statement is a table. So is a Sage trial balance, a bank statement, a loan schedule and an aged debtor report. Split a table by word count and you get chunks containing rows with no header, amounts with no column, and dates with no context. Retrieval then returns a passage that looks relevant and means nothing. The model, given a chunk of orphaned numbers, will interpret them, because that is what models do.

What to do instead

First, ask whether it belongs in RAG at all. An M-Pesa statement should be parsed into structured records and queried through a connector, not embedded. If you find yourself embedding a statement, you have probably made the routing mistake from Part 2.

For documents that genuinely mix prose and tables (board papers, credit assessments, annual reports), use structure aware processing:

Scanned documents need OCR quality checks, not just OCR. A large share of Kenyan supporting documentation is a photograph of a printout. Run a confidence threshold, and route anything below it to human review rather than silently indexing garbage. An OCR error in a KRA PIN or an amount is worse than no data.

Language

Multilingual is not optional here. Customer correspondence, support tickets and call transcripts contain Swahili, English, and a great deal of code switching between them mid sentence, plus Sheng in consumer facing channels.

Test your embedding model on your own material before committing. A model that scores well on academic multilingual benchmarks may handle formal Swahili and fail on the actual register of a WhatsApp support conversation. Build a small evaluation set of real queries against real documents and measure it. Twenty queries is enough to tell you whether a model is viable.

Part 5: Embeddings, and the residency problem nobody mentions

Here is the contradiction sitting inside most African enterprise RAG proposals, including the earlier draft of this one.

The compliance argument says data stays in Africa. The pipeline sends every chunk of every document to an embedding API in the United States.

Embedding is not an exception to residency. To create the vector, the provider receives the text. If that text is a credit assessment note containing a member’s National ID and financial history, it left the country, and you told your regulator it did not.

This has to be a deliberate decision, made in the open.

The practical answer: split by classification

Do not choose one. Route by sensitivity label, which is exactly the taxonomy the companion article on Purview describes building.

• Public and Internal content goes to a managed embedding API. Marketing material, published policies, product documentation. Quality matters, residency does not.
• Confidential and Highly Confidential content goes to a self hosted model inside your environment. Credit notes, customer correspondence, board papers, anything with personal data.

You run two embedding paths and two vector collections. It is more infrastructure. It is also the only version of this that a bank’s security architect signs off, and it means your residency statement is true rather than nearly true.

Budget a GPU instance for the self hosted path. A modest instance in your own environment running a bge-m3 class model handles the embedding volume of a mid sized enterprise comfortably, and the cost is predictable rather than per token.

Part 6: Governance, briefly

The full treatment is in the companion article. Three points specific to RAG.

Permissions must survive indexing. This is the failure that ends projects. A document sitting in a restricted SharePoint folder gets indexed into a vector store that has no concept of that folder. Retrieval then serves a passage from it to someone who could never have opened the file. You have built a permission bypass and called it a productivity tool.

The fix is to carry source permissions into chunk metadata and filter at retrieval time, before the model sees anything. Filter at retrieval, not after generation. Once a restricted passage is in the context window it has already been disclosed.

Deletion has to reach the index. A data subject exercising erasure rights, or a document deleted at source, must propagate to the vector store and to any cached derivative. Design this on day one. Retrofitting deletion into a RAG index is genuinely difficult and it is a question you will be asked.

Every retrieval is an access event. Log which chunks were retrieved, from which sources, for whom. “The AI answered a question” is not an audit record. “This user retrieved passages from these four documents, two of which contain personal data” is.

Part 7: What it returns

Three models. Different organisations, different economics, each internally consistent. Inputs are stated so you can substitute your own.

Each is shown two ways. Gross values every released hour at fully loaded cost. Conservative assumes no headcount reduction and converts 40% of released time into something the business actually captures, whether that is deferred hiring, absorbed growth or redeployed effort. The remaining 60% is treated as slack, because in practice a large share of recovered time is.

Model A: Commercial bank, customer intelligence for relationship managers

Inputs

Capacity released

11.5 hours per RM per week × 46 weeks × 50 RMs = 26,450 hours per year, which is 14.7 full time equivalents.

What is recovered

What it takes. Discovery and data inventory, connector configuration including a read only adapter for core banking, a RAG pipeline over correspondence and credit files, integration and adversarial testing, and user training. Then an ongoing cost for the platform, hosting in region and the self hosted embedding path.

Implementation scope varies enough between institutions that a single published figure would mislead more than it helps. A bank with a modern core banking API and one with a twenty year old system have very different projects. What travels between them is the threshold.

Break even thresholds, conservative case

That is an unusually wide margin, and it comes from one thing: fifty people each losing eleven and a half hours a week to retrieval. This is comfortably the strongest case in this document.

What is deliberately not counted. Cross sell uplift from better prepared conversations is real, and it is probably larger than the time recovery. It is also a counterfactual, so it stays out of the arithmetic and belongs in the narrative instead.

Model B: SACCO, loan assessment

Inputs

On the capacity figure. Earlier material claimed a fivefold increase. Threefold is more defensible. AI removes the evidence gathering, which is most of the officer’s time, but committee scheduling, disbursement operations and member communication do not scale with it. Claiming 5x invites a challenge you will lose in the room.

What is recovered

Processing saving: 5,000 loans × KES 1,550 = KES 7,750,000.

Default reduction from better underwriting evidence, as a sensitivity on the KES 750M book:

Break even thresholds, conservative case

Read this honestly. The margin here is narrower than the bank’s, and a SACCO board should approach it with a two year horizon rather than expecting a first year win.

The real lever is the default rate, and it is the least certain input in the model. If the case depends on a default improvement you have not yet demonstrated, run a shadow assessment before committing to anything: score six months of historical decisions against the model, compare against what actually happened, and see whether the evidence holds. That costs very little, it can be done before any platform decision, and it changes the conversation entirely. We would rather you did that first.

Model C: Mid sized enterprise, finance operations

Inputs

Note the day rate. Earlier material used KES 2,500 per person day, which implies a fully loaded finance salary of about KES 650,000 a year. That is not a real number for this role in Nairobi, and it made the mid market case look far weaker than it is.

What is recovered, reconciliation alone

Time: (216 − 18) person days × KES 8,000 = KES 1,584,000. Working capital: penalties avoided and early settlement discounts captured, KES 300,000 gross, KES 120,000 conservative.

This is the most important finding in the document, so it gets stated plainly. For a mid sized enterprise, one workflow does not carry a platform.

Under KES 800,000 a year on conservative assumptions is a thin number to support an integration project, a governance model and ongoing infrastructure. It can be done, but it is a two year decision rather than an obvious one, and anyone selling a mid market AI platform on the strength of a single workflow is either not doing the arithmetic or hoping you will not.

What changes on expansion

The economics improve sharply with each additional use case, because the connectors, the governance model, the hosting and the audit pipeline are already in place. A second and third use case on the same connector set cost configuration effort and almost nothing else.

Conservative recovery rises by roughly 60% while the infrastructure underneath does not change at all.

Break even thresholds, conservative case, three use cases

The implication for how you should buy. Do not run a mid market pilot on one workflow and judge the platform on the result. Scope three use cases across the same connector set from the beginning. The second and third are close to free and they are what carry the case.

Comparing the three

The pattern is straightforward and worth understanding before you commit to anything. This architecture rewards scale in repeated human effort. Where fifty people each lose eleven hours a week to retrieval, the return is overwhelming and the investment question is almost academic. Where three people lose four days a month, it is a considered two year decision.

Anyone quoting you a single ROI figure for enterprise AI has not asked how many people are doing the work.

On what it costs. We have deliberately not published implementation figures, because the honest answer depends on things we cannot know from here: how many connectors, whether your core banking system has a usable API, how much of your document estate needs processing, and what your compliance function requires before go live. The thresholds above are the useful half of that conversation. Bring us your own inputs for the benefit side, and we will scope the other half properly rather than quote you a number that turns out to be wrong.

Part 8: Eight weeks

Two things teams consistently underestimate.

The evaluation set. Fifty real questions with known correct answers, built with the people who will use the system. Without it you cannot tell whether a change improved retrieval or broke it, and you will be making changes for years. Teams skip this because it is unglamorous, then spend the following six months arguing about whether the system is any good.

Teaching the limits. Users need to know the system will not aggregate across documents, is weak on recency unless the index is fresh, and can misread a negation. A user who knows the boundary trusts what is inside it. A user who discovers the boundary by being embarrassed in a meeting stops using the system entirely.

Part 9: Where this fails

Aggregation across documents. “How many contracts include a termination for convenience clause?” requires reading all of them. Retrieval reads ten. It will answer anyway. This is the most dangerous failure because the answer looks authoritative.

Recency. The index is as current as the last run. A model answering from a superseded policy is confidently wrong. Show index freshness in the interface.

Negation. “Customers who did not complete onboarding” retrieves passages about completed onboarding, because those are the semantically similar ones.

Absence. Retrieval cannot report that something is not there. It returns the closest match to a question about a document that does not exist, and the model builds an answer around it.

Documents that were always wrong. Digitising a bad process gives you a fast bad process. The contract nobody updated since 2019 is now instantly retrievable and still wrong.

Organisational, not technical. The department that will not share its data will not share it because the system is better. Silos are usually a governance and incentive problem wearing a technical costume, and if you have not addressed why finance does not give operations access, the architecture will not change their mind.

Every figure in this article is a worked model with stated inputs, not a customer result. Bring us your own numbers and we will build the same model with them.