Insights & Perspectives

Governance briefs & commentary

Short, opinionated notes on AI governance, data regulation, architecture blueprints, and enterprise AI — drawn from real rooms: ministerial summits, banking roundtables, and executive leadership.

PerspectiveOct 2026

Sovereign AI for Africa: What Should We Own, What Should We Build, and What Should We Rent?

Sovereign AI for Africa: What Should We Own, What Should We Build, and What Should We Rent?
Where to Run What: A Simple Guide for Africa — Tier 0 (Must stay local and inspectable), Tier 1 (Prefer regional / in-Africa), Tier 2 (Rent globally).

What Sovereign AI Means for Africa

Artificial intelligence is arriving in Africa at a fascinating moment. The continent has an enormous opportunity to use AI to leapfrog traditional models of service delivery, business and economic development. From agriculture and healthcare to banking, education, energy and government services, AI could fundamentally change how Africa solves problems.

As Africa adopts AI, how much control should it retain over the infrastructure, data and intelligence that AI depends on?

I don't believe the answer is to build everything ourselves. Africa does not need to create an African version of every global cloud platform, build a frontier model in every country, or reproduce every piece of AI infrastructure locally. That would be expensive, inefficient and unnecessary.

But I also don't believe Africa should simply become a massive consumer of AI services built, hosted and controlled elsewhere. There is a middle ground: Sovereign AI for Africa.

For me, sovereign AI is not about isolation or technological protectionism. It is about agency: having the ability to decide where data is stored, who can access it, which systems process it, which capabilities Africa needs to develop itself, when to use regional infrastructure, and when it is smarter to rent global technology.

Tier 0 — Keep it local and inspectable

Some information and systems are simply too important to treat like ordinary cloud workloads: national identity, payments core and financial settlement, health records, tax and revenue data, customs and trade systems, defence and national security, critical electricity grid infrastructure, encryption keys, and fine-tuned sovereign model weights.

The principle is straightforward: The more consequential the data or system, the greater the need for direct control, inspection, resilience and accountability.

This doesn't necessarily mean every server must physically sit inside a government building. It means the organization must have the technical, contractual and legal ability to control the environment and understand what is happening to its data. Tier 0 is about sovereignty and control.

Tier 1 — Build strategic capability in Africa

The objective is not simply to keep the workload 'inside Africa.' The objective is to build African capability around it. Whether hosted with African data centre providers (Cassava, iXAfrica, Kasi Cloud, Africa Data Centres, ST Digital, OADC, UniCloud) or in-country hyperscaler regions with contractual data residency, Tier 1 is about building capability and retaining strategic value.

  • Customer analytics: Understanding local consumer behaviour, micro-segments, and churn patterns.
  • Contact-centre speech: Voice analytics, transcription, and conversational interfaces across African languages.
  • Credit and financial inclusion models: Alternative lending and underwriting algorithms trained on localized cash-flow signals.
  • Agritech intelligence: Crop disease identification from mobile photos combined with regional soil and weather data.
  • Public-service copilots: Citizen support, healthcare triage, and internal administrative automation.

Tier 2 — Rent the world

Then there is a large category of AI that Africa should simply use: generic coding assistants, commodity image and video recognition, general-purpose productivity tools, non-sensitive experimentation, burst GPU training, and frontier-model APIs (GPT, Claude, Gemini).

If a global provider can offer a capability more efficiently, competitively and securely, why recreate it? Use it — but use it intelligently through an AI gateway.

The gateway sits between the organization and AI providers, determining what information can leave, what needs anonymization, what gets logged, and what stays completely inside. The principle becomes: Rent global intelligence without surrendering control of your data.

Why does this matter?

Because AI could become another source of dependency. Africa has experienced this pattern before: importing technology and platforms that created enormous value, while ownership, intellectual property and economic value remained elsewhere.

The goal shouldn't be to own everything. The goal should be to own enough of the value chain to have choices: African datasets, local AI companies, regional compute, data centres, connectivity, skills, and governance frameworks.

What this means for governments and businesses

For governments, Sovereign AI moves beyond 'Should government use AI?' to: 'Which AI should government use, with which data, under whose control, and for what purpose?' A government uses Tier 0 for identity and tax, Tier 1 for agriculture and local-language copilots, and Tier 2 for generic coding and research.

For businesses, a bank protects identity and payment cores in Tier 0, uses regional AI for fraud detection and voice analytics in Tier 1, and rents global frontier models for product prototyping in Tier 2.

The vital principle: The tier belongs to the workload — not the organization. One entity can and should operate across all three tiers.

A Simple Rule for Sovereign AI

The ambition should not be to make everything local, nor to make everything global. The ambition should be to create an Africa that is secure enough to protect what matters, capable enough to build what matters, and open enough to use the best technology the world has to offer.

  • Tier 0 — Control it: Sensitive, sovereign and critical systems kept local and inspectable.
  • Tier 1 — Build it in Africa: Strategic capabilities where African data, context and talent create an advantage.
  • Tier 2 — Rent it globally: Generic, scalable and non-sensitive AI capabilities behind an AI gateway.
Key Takeaway

Own what is strategic. Build what creates African advantage. Rent what is global and commoditized. The ambition is an Africa secure enough to protect what matters, capable enough to build what matters, and open enough to use the best technology the world has to offer.

ArchitectureOct 2026

Large Language Model Observability Pipeline

Large Language Model Observability Pipeline
Large Language Model Observability Pipeline: Emit with OTel, govern in Collector, buffer in Kafka, serve in StarRocks & Lake, and act in Grafana & MCP.

What this model is

One vendor-neutral pipe for agent and LLM telemetry: emit with OpenTelemetry, govern (normalize + redact) in the Collector, buffer in Kafka, serve hot sessions in StarRocks and history in a Parquet lake, then act in Grafana, MCP tools, alerts, batch jobs, and evals.

The grain is the session (a user turn or agent run), not every token-stream event. Evals write back into the same pipe so production and benches share a schema.

How each stage is used

  • Emit: SDKs and gateways attach GenAI attributes (model, tokens, tools, prompt version). Bench runners emit the same shape so scores join later.
  • Govern: Collector is the compliance and schema gate: PII/prompt redaction, tenant tags, cost hints, session-complete sampling. Nothing raw should reach Kafka.
  • Buffer: Three topics keep jobs from blocking each other: session traces, metrics, evals.
  • Serve: StarRocks answers “show this failing session and its tool tree.” The lake holds months of Parquet. Streaming SQL watches Kafka for cost spikes and intent shifts in seconds.
  • Act: Dashboards, an MCP/CLI skill for on-call, SLO alerts, lake analytics, and prod↔bench joins.

Enterprise use cases

  • 1. Cost control across business units: Finance and platform teams query tokens × model × team from StarRocks or the lake, set budget alerts on the stream, and prove which agent is burning spend—without a vendor lock-in bill.
  • 2. Safety, legal, and residency: Redact in the Collector before the durable log. Keep prompts in-region on your object store. Audit “who saw this session” via MCP RBAC. Useful for banks, health, and public sector.
  • 3. Incident response for agents: On-call opens Grafana, jumps from a latency/cost alert to the session waterfall (planner → tools → model), then asks the troubleshooting skill: “sessions that failed after the new prompt.” Same path as classic APM, but session-shaped.
  • 4. Change management: Ship a prompt or model. Agent-bench re-emits scores as OTLP. Join prompt_version to production error rate and cost. Gate releases on that join, not a slide deck.
  • 5. Multi-provider and multi-team platform: One Collector contract for OpenAI, Anthropic, Bedrock, and internal models. Product teams keep their agents; the platform team owns routing, retention, and cost allocation.

If you just want to try it

Start small; the diagram is a target, not day-one infra.

  • Instrument one app with OpenLIT / OpenLLMetry → OTLP to a local Collector.
  • Redact prompts in the Collector; export to one Kafka topic (or even Collector → StarRocks/ClickHouse if you skip Kafka at first).
  • Put Grafana on StarRocks or any OTLP backend; add token/cost panels.
  • Run a tiny bench, emit scores as OTLP, join on session_id.
  • Add Kafka + lake + streaming SQL when volume or compliance demands it.

A laptop path: Collector + Grafana + one OLAP (StarRocks in Docker, or even DuckDB on exported Parquet) is enough to learn the model. Enterprises add Kafka, shared-data StarRocks, object storage, and IAM on the MCP layer when they go multi-team.

Why this shape fits both audiences

NeedHow the model answers
No lock-inOTLP + Kafka + Parquet + open OLAP
ComplianceRedact before the log; lake stays in your cloud
Cost at scaleSession sampling + cheap cold storage
Fast debugHot OLAP + Grafana + MCP skill
QualityEvals in the same stream as prod
Try-before-commitEach box can be a Docker service first
Key Takeaway

Bottom line: corporates use it as a governed AI data plane (cost, risk, release gates). Individuals use the same contracts with fewer boxes. You do not change the model when you grow—you turn stages on.

PerspectiveOct 2026

AI vs. SI: Why Changing the Name Doesn't Change the Tech

AI vs. SI: Why Changing the Name Doesn't Change the Tech
AI vs. SI: What we have today (Artificial Intelligence) vs. A hypothetical future (Super Intelligence)

The U.S. government recently made a highly publicized move to rebrand "Artificial Intelligence" (AI) to "Super Intelligence" (SI) across all federal communications. The argument is that the word "artificial" makes the technology sound fake, and that we have entered a new era of computing that deserves a grander title.

But as someone who relies heavily on these platforms every single day—constantly jumping between ChatGPT, Claude, Perplexity, and Napkin AI to get real work done—this rebranding feels completely out of touch with where the technology actually stands today.

Don't get me wrong: the tools we have right now are incredibly capable. They can synthesize massive amounts of data, generate ideas, and streamline workflows in ways that seemed like science fiction just a few years ago. But calling them "Super Intelligent" is a massive stretch.

In the tech industry, "Superintelligence" already has a specific meaning. It refers to a hypothetical future system that vastly outperforms the best human minds in practically every field, from scientific creativity to social skills. The models we are using today are brilliant at predicting the next word in a sentence and identifying patterns, but they still hallucinate facts, struggle with complex logic, and require heavy human oversight. They are sophisticated tools, not autonomous super-beings.

Renaming AI to SI right now blurs the line between current utility and future possibility. It creates a false expectation for the general public about what these models can actually do.

The word "artificial" isn't an insult to the technology; it's an accurate description of its origin. It is machine-generated intelligence, engineered by humans, to assist humans. Until a platform can genuinely out-think us across the board without our constant prompting and correction, I’ll be sticking with "AI."

We don't need a fancier name for these tools. We just need to keep focusing on how to build them better, use them responsibly, and integrate them effectively into our work.

Key Takeaway

A new name creates a false expectation. We don't need a fancier name for these tools. We just need to keep focusing on how to build them better, use them responsibly, and integrate them effectively into our work.

PolicyNov 2025

Why fragmented data policy is Africa's biggest AI bottleneck

At Africa Tech Festival, one theme kept surfacing: the continent does not lack talent or ambition — it lacks harmonised data regulation. When every border changes the rules for data flows, a regional AI system becomes fifty-four legal problems instead of one engineering problem. The fix is not more policy; it is aligned policy. Three shared definitions would unlock most of the value: what counts as personal data, when data may cross a border, and who answers for a model's decisions. Countries that agree on those three can trade data the way they trade goods — and the AI built on top finally becomes buildable.

Related: Africa24 TV interview →
GovernanceNov 2025

What banks taught me about saying yes to AI

In a roundtable with a dozen banking technology leaders on cloud email security, the pattern was clear: institutions that move fastest on AI are not the ones with the loosest controls — they are the ones whose risk frameworks are explicit enough to approve things. Governance written down is governance that accelerates. Governance held in people's heads is governance that stalls.

DataDec 2024

A data backbone is a governance project, not an infrastructure project

Speaking on building Africa's data backbone, the argument I keep making: pipelines and cloud regions are the easy part. The hard part is deciding who owns the data, who may use it, and how its use is audited. Treat the backbone as an engineering program and it will be rebuilt in three years. Treat it as a governance program with engineering attached, and it compounds.

Practice2025

From pilot to production: the MLOps gap nobody budgets for

Most generative AI pilots die between the demo and the audit. The missing line item is rarely the model — it is evaluation harnesses, data lineage, and rollback paths. Teams that budget for MLOps up front ship; teams that treat it as a later concern end up with a impressive proof of concept and a compliance team that cannot sign off.

Home