Where your AI actually runs, and why African buyers ask first
Every major cloud now has infrastructure in South Africa. That is not the same as your AI running here, and the difference is the first thing a serious buyer in this region asks about.
Helen MillsChief Operating Officer9 July 20265 min read
In short
A cloud region in your country does not mean the AI service you are calling runs in it.
AWS's own documentation states that Bedrock requests from Cape Town are routed to other regions for inference, and tells customers to evaluate that against POPIA themselves.
POPIA section 72 permits cross-border transfer on five specific bases. None of them is "the vendor has a data centre here".
Across the continent the rules diverge sharply, from Kenya's in-country requirement for state-strategic data to licensing regimes in Egypt.
There is a sentence that appears in a lot of proposals in this region, including some of ours in the past, and it does less work than it appears to. It is some version of: the platform runs in a South African region, so your data stays in South Africa.
Buyers here have started taking that sentence apart.
Infrastructure is not the same as service
All three major clouds have physical presence in South Africa. Microsoft's Johannesburg and Cape Town regions became generally available in March 2019. AWS opened its Cape Town region in April 2020. Google's Johannesburg region opened to customers in January 2024.
The AI services are a separate question, and the answers differ.
Microsoft's own region-support documentation lists Azure AI Foundry, which covers the OpenAI-class models, as supported in South Africa North but not South Africa West. Microsoft also notes that a region appearing in that list does not guarantee every individual model is available there, so the check has to be made model by model rather than region by region.
AWS made Amazon Bedrock available to customers in the Cape Town region in November 2025. In January 2026 AWS published a description of how that works, and it is the most useful paragraph any vendor has written on this subject. Requests originate in Cape Town, but the inference itself runs under global cross-region routing, which means the model computation happens in other AWS regions. Logs, configuration and stored knowledge-base content remain local. AWS states plainly that customers should evaluate whether the approach fits their regulatory obligations, and names POPIA when it does so.
That is a vendor telling you, in its own documentation, that the marketing shorthand does not hold.
Google's Johannesburg launch coverage referred to generative AI capability reaching customers in the region. We have not been able to confirm from Google's own region-support documentation which generative models are served from Johannesburg itself, so we would put that in the verify-before-you-rely-on-it column.
Where the work happens when a Cape Town request reaches a hosted model. The inference is the step that leaves the country.
What POPIA actually says
Section 72 does not prohibit sending personal information out of South Africa. It permits it on five bases: the recipient is bound by a law, binding corporate rules or an agreement giving substantially similar protection with onward-transfer restrictions; the data subject consents; the transfer is necessary to perform a contract with the data subject; it is necessary for a contract concluded in the data subject's interest; or it is for the data subject's benefit where consent is impractical.
Read that list again against a cross-region inference architecture. A data centre in Johannesburg is not one of the five bases. What the five bases require is a documented answer about the receiving party and the contractual protection in place, which is a different piece of work from choosing a region in a dropdown.
The Information Regulator has not published its long-expected guidance note on transborder flows, so there is no shortcut to point at. In the meantime the Regulator has been active in other respects: mandatory breach reporting through its own channel since April 2025, amended regulations in the same month, and a joint report from the financial regulators in November 2025 on AI risks and opportunities, which is guidance rather than binding law.
Kenya, Nigeria, Egypt, Mauritius
For anyone operating across borders, and for the francophone and East African markets in particular, the divergence matters more than the South African position.
Kenya's Data Protection Act is broadly a transfer-with-safeguards regime, but section 50 requires personal data of strategic interest to the state, including civil registration, elections, public finances, basic education and primary healthcare, to be processed on a server in Kenya or to keep at least one serving copy in the country. That is a hard requirement and it lands squarely on public-sector work.
Nigeria's Data Protection Act does not impose blanket localisation. Its Commission's implementation directive of March 2025 ties consent requirements to the absence of an adequacy decision and requires processing agreements to state where processing happens, which is a quiet but significant drafting obligation.
Egypt operates a licensing model, requiring a cross-border transfer licence and a locally appointed data protection officer. Critics have argued the fee levels make it localisation by another route.
Mauritius, where we also operate, tracks the European model more closely than South Africa does. Transfers rest on evidence of appropriate safeguards provided to the Commissioner, on explicit consent, or on necessity grounds. There is no whitelist of approved countries, so each arrangement is assessed on its own terms.
At continental level the Malabo Convention came into force in June 2023 once Mauritania became the fifteenth state to ratify, and had at least sixteen ratifications by mid-2024. Neither South Africa nor Kenya is among them. The African Union's continental AI strategy was endorsed by ministers in June 2024. Both signal direction of travel. A compliance officer cannot yet rely on either.
What we write down before the architecture is agreed
None of what follows is exotic.
We establish where inference physically happens before the architecture is agreed, and we write the answer down. Vendor documentation, not sales material, is the source.
We keep the option of processing that does not leave the estate at all for the categories where the legal answer is unattractive or unclear. Not everything needs a frontier model, and a smaller model reading well-governed local knowledge is often the better answer anyway.
We name the transfer basis in the design document. If the answer is consent, somebody has to collect it. If the answer is contractual protection, somebody has to produce the contract. Deciding that during design costs an afternoon. Deciding it during a client's security review costs a quarter.
On our own engagements this is becoming a fixed section of the design document for any Azure or AI workload, completed before the architecture is signed, and our delivery pipeline already names the data-protection regime and sizes the work for it from the first breakdown. Sensitive client content stays on our tenant under our Responsible AI policy, and the controls we run are summarised under trust and security. For clients moving workloads, the same residency question is the first step of a cloud migration and modernisation engagement.
Having settled where things run, the next piece is about how they get built, and why we would rather extend something that already works than start from an empty repository.
SARS has put a digital VAT model out for consultation. It is not a mandate and there is no confirmed date, but the direction is clear enough that finance and IT should read it now rather than in 2029.
Second of three. We compared what we had produced against what anyone had actually asked for. A large share of it could not be matched to a question, and that changed how we choose what to work on.