Most AI products sold in Africa were designed somewhere else. They assume stable power, cheap and fast bandwidth, English as the default language, abundant cloud regions next door and a regulatory environment shaped in Brussels or California. When those assumptions hold, the products work well. When they do not, organisations discover the gap after the contract is signed, the pilot is live and the budget is spent.
This is not an argument against global technology. Frontier models, open-source tooling and hyperscale cloud are remarkable assets, and African organisations should use them. The argument is narrower: the architecture around those assets has to be designed for the conditions in which they will run. Copying a reference architecture from a different context imports its assumptions along with its components.
The assumptions hidden in a reference architecture
Every AI system carries a set of quiet design decisions. A few that matter most on the continent:
- Always-on connectivity. Many assistants call a remote model for every interaction. On a congested mobile network, or during an outage, the service simply stops.
- Uninterrupted power. Load-shedding and grid instability affect data centres, branch offices and users' devices alike. Systems that assume continuous uptime fail in ways their designers never tested.
- Desktop-first users. A large share of customers and citizens interact through a mobile phone, often through WhatsApp, USSD or SMS rather than a web application.
- A single dominant language. Users switch between English, French, Portuguese, Arabic and local languages, sometimes within one sentence. Models tuned mainly on English text handle this unevenly.
- Distant data is acceptable. Data protection laws such as South Africa's POPIA, Nigeria's NDPA and Kenya's Data Protection Act place conditions on where personal data goes and how it is processed. Sending every prompt to a model hosted on another continent is a legal and commercial decision, not just a technical one.
- Costs in dollars, budgets in rand, naira or shillings. Consumption-based pricing can move sharply with exchange rates, which makes per-token costs harder to forecast.
None of these points is exotic. They are the everyday operating environment for most organisations on the continent, which is precisely why they should be first-class design inputs.
What designing for context looks like
Designing for African conditions does not mean building everything from scratch. It means making deliberate choices at each layer of the system.
Choose the right model for the job
The largest model is rarely the right default. Smaller open-weight models, fine-tuned or paired with retrieval over your own documents, can run in-country or even on-premise at a predictable cost. Reserve calls to large hosted models for tasks that genuinely need them, and route requests accordingly.
Design for intermittent everything
Treat connectivity and power as variables. Cache frequent answers. Queue requests when the network drops and process them when it returns. Provide a graceful fallback, such as a simpler rules-based response or a human hand-off, when the model is unreachable. For field staff, consider edge inference on a laptop or local server that synchronises when it can.
Meet users on their channels
If your customers live on WhatsApp, the assistant should too. If a meaningful share of users rely on feature phones, design a USSD or SMS path. Keep responses short, structured and cheap in data terms.
Treat language as a requirement, not a feature
Test with the languages and code-switching patterns your users actually use. Build evaluation sets from real (appropriately anonymised) interactions rather than translated benchmarks. Where quality falls short, plan for human review or a narrower scope rather than hoping the model will cope.
Keep sensitive data close
Classify the data each use case touches. For personal and confidential information, prefer in-country or regional hosting, apply data minimisation before anything leaves your environment and make sure vendor contracts are explicit about retention and training. This is easier to design in from day one than to retrofit after an audit.
Questions to ask before you buy
Before committing to an AI platform or partner, it is worth asking a handful of direct questions:
- Where will our data be stored and processed, including logs and prompts?
- What happens to the user experience when connectivity drops or latency spikes?
- How has the system been tested in the languages our users speak?
- Can we run part or all of the workload in-country if regulation or cost requires it?
- How are costs calculated, and how sensitive are they to usage spikes and exchange rates?
- What does it take to switch models or providers in two years' time?
Clear, specific answers are a good sign. Vague reassurance is not.
The opportunity in getting this right
Designing for constraints tends to produce better systems everywhere. Services that work on a slow connection are faster for everyone. Architectures that keep data close are easier to govern. Models evaluated across many languages are more robust. African organisations that build this way are not settling for a lesser version of AI; they are building versions that are better suited to the people they serve and more resilient to the conditions they operate in.
The practical starting point is modest: take one priority use case, write down the assumptions its architecture makes, and test each one against your real environment. The gaps you find will tell you where to invest.
