Hans van Linschoten: Roaming for compute

When a Ugandan business traveller lands in Nairobi or Kigali, her phone can work without the roaming charges that once made cross-border calls prohibitively expensive. Since the East African Community introduced its One Network Area initiative in 2014, participating countries have reduced roaming charges and removed certain surcharges on cross-border traffic. Nobody asked Safaricom to own MTN Uganda’s network, or the other way round. Independent operators, each running their own infrastructure under their own national licence, agreed on common rules, settled with each other, and made crossing the border easier for the customer.

Last week I argued that Africa does not have to buy the AI bubble: open models are now close enough to the frontier for many practical applications, and previous-generation hardware is capable enough, that the continent can build AI capacity without betting national balance sheets on one hyperscale campus per country. This week’s question is the obvious follow-up. If not one large building per country, then what?

My answer is the same thing that worked for mobile: roaming — this time for compute.

Sovereignty is about rules, not buildings

Start with what the law actually requires. According to Code for Africa, 44 African countries — about four in five African Union member states — had enacted data protection laws by the end of 2025, and 38 had operational data protection authorities. A growing number also impose localisation requirements for specific categories of data. Kenya’s Cloud Policy promotes cloud adoption while requiring compliance with national data protection laws, including rules governing cross-border transfers. Morocco has introduced data classification and security requirements for sensitive information, while Ghana and Nigeria have frameworks governing data protection and international transfers.

Read those rules carefully and notice what they do not generally say. Where data must stay inside a jurisdiction, under defined controls and accessible to defined people, that does not mean it must sit in one building, owned by one entity, built for one country’s peak

demand. Sovereignty is a property of jurisdiction, control and operational capability. A single national campus is one way to achieve it. It can be an expensive way, and — because everything sits in one place — not necessarily the most resilient.

The alternative is a grid: many locations, independently owned, running the same platform and operating under common rules, so that capacity, backup and failover can be shared where permitted without anyone giving up ownership.

How the roaming model maps to compute

Telecoms solved this problem twice. Roaming let independent networks serve each other’s customers. The wholesale model — network enablers selling capacity to virtual operators — let hundreds of brands reach the market without building towers. Both rest on a simple division of labour: those who own infrastructure focus on running it well; those who own customer relationships focus on serving them; a common set of rules and a settlement system connect the two.

A federated cloud grid works the same way. Organisations that own hardware — telcos, data-centre operators, hosting companies, and potentially governments and large enterprises — run a location as a Cloud Enabler. Organisations that own customer relationships — managed service providers, integrators, local software houses — operate as Virtual Cloud Operators under their own brand, with their own pricing. A Virtual Cloud Operator contracts with, and is billed by, one Cloud Enabler only, but can deploy workloads in participating locations across the federation, because the Enablers resell capacity to each other. Usage is metered and settled behind the scenes; the customer receives one invoice.

Two properties matter most for Africa. First, every location remains independently owned: each member keeps control of its own infrastructure and its own customers. Second, capacity that sits idle in one place can be used from another, subject to availability, connectivity and applicable rules, which is how a grid of modest sites can achieve better utilisation than a half-filled national campus.

Three ways to join

Governments are the natural anchor tenants. A ministry, a national data agency or a state-owned operator can run a sovereign location for classified and citizen data, and use the federation for what the law allows to move: a second site with another member in the same country, burst capacity for non-sensitive workloads, or disaster recovery in a partner state under a bilateral agreement. Where a government wants to own the technology itself and not only the data, a Build-Operate-Transfer model fits: the platform is built and operated with government engineers embedded from the start, and over a five-year programme, operations and governance are transferred to the public institution, together with a copy of the source code for internal government use. The test of sovereignty is whether the state could keep running the cloud if the vendor disappeared.

Enterprises — a bank, a university, a hospital group, an insurer — can run a private location on their own hardware, including compatible servers and storage arrays they already own, and use the federation for backup, recovery and peak demand. Larger ones can go a step further and offer spare capacity to the grid, turning a cost centre into a modest revenue line.

Service providers are the backbone. Telcos, data-centre operators and ISPs bring sites, power, connectivity and billing systems: they are natural Cloud Enablers. Managed service providers, integrators and software companies become Virtual Cloud Operators. A Lagos MSP whose client needs a presence in Kampala no longer has to build there or hand the customer to a hyperscaler; it deploys in a federated Ugandan location through its existing contract.

Built from what members already own

A grid like this does not start with new steel. It starts with the edge rooms, points of presence and small server rooms that already exist close to users — not, as is sometimes

suggested, on mobile towers, many of which lack the space, cooling or backup power required to host suitable server infrastructure. It uses previous-generation servers and accelerators, where appropriate, divided into virtual GPU profiles so that several small models can share one card. It connects to an anchor data centre where one exists. And it can gain resilience from distribution rather than from building every site to the highest tier: when one location fails, workloads can recover at another member’s location, under the same rules, provided the necessary replication, connectivity and recovery arrangements are in place.

Most importantly, it grows with demand. A new location joins when a member has users to serve, not when a national plan says a building should exist.

This is not a blueprint on paper. A federation of this kind already operates across locations in Europe and Africa, including a live AfriQloud location in Uganda and a participating location in Mauritius. In Uganda, locally operated cloud infrastructure

provides capacity that service providers can sell under their own brands. That is the model in miniature: local owners running the infrastructure, local operators serving the customers, one platform underneath. It is early, and small next to the ambition. But the mechanism — independent owners, one platform, shared capacity, one contract — is running.

What could go wrong

A federation is only as strong as its weakest member and its least-trusted rule. Anyone proposing one — and I am one of the people proposing it, so the same scrutiny applies to us — should be asked five questions.

Who sets the rules? Roaming works because of a dense rulebook: technical standards, service levels, settlement terms, dispute procedures. A compute grid needs the same — admission criteria, minimum operating standards, transparent per-location service levels, and a neutral way to resolve disputes. Without them, one poorly run site damages everyone’s brand.

Is quality uneven? Power and connectivity vary enormously across the continent. Distribution can help compensate, but customers must be able to see what each location actually delivers, not a federation-wide average.

Does data really stay where the law says? Localisation rules limit what can cross a border. Residency has to be a policy the platform enforces on every workload, not a promise in a brochure. In practice, the rule is simple: move workloads only where permitted, and do not move restricted data across borders unless the law allows otherwise.

What does it cost to connect the sites? Cross-border transit in Africa can still be expensive, and some traffic still routes via Europe. Keeping data local and using cross-border links selectively for recovery and burst capacity can help manage that cost — but it is a real constraint, not a footnote.

Have you just swapped one dependency for another? A common platform is, by definition, a shared dependency. The honest answers are structural: source code transferred to governments under Build-Operate-Transfer, a self-operated software

edition when available, open standards, and engineering capacity on the continent — in our case, half of the team already works from Egypt, Uganda and Nigeria. Ask every provider, including us, what happens if they disappear tomorrow.

The grid is the strategy

Put the pieces together and the case is straightforward. A federation spreads capital across many owners instead of concentrating it in one balance sheet. It pools utilisation, so modest hardware can stay busy. It keeps ownership local, providing a foundation for sovereignty that is exercised rather than merely claimed. And it uses a commercial model that Africa already knows works, because African mobile connectivity has benefited from it.

There is one more reason to build it now rather than later. The next generation of mobile networks, 6G, is being designed with AI and computing increasingly integrated into the network itself. That means a distributed layer of compute close to users — exactly the grid described here. The specifications are being written now, with 3GPP Release 21 scheduled for a functional freeze in December 2028 and final protocol-related specifications in March 2029. Next week I will look at what that means for Africa, and why the countries and operators that build a federated grid in the next three years could negotiate 6G from a position of strength rather than dependency.

Hans van Linschoten is the CEO of whitesky.cloud, a European sovereign cloud platform, and Co-founder of AfriQloud, a pan-African sovereign cloud and edge AI infrastructure initiative.