Sovereign AI in South Africa: what it actually means here

A foreign court order compelling your cloud provider does not land in your inbox. It lands on the provider. In many cases you are not told it arrived, and you are not told what left.

That is the part of sovereignty nobody presents to a board. The exposure is not that your data is somewhere foreign. It is that the decision about your data can be made by someone else, under a law you have never read, in a jurisdiction you have never operated in — and you may find out afterwards.

The sequence is short, and you are in almost none of it. A foreign court issues the order. Your provider receives it, and must comply. You are not necessarily told. The decision is made somewhere you are not.

We have been answering the wrong question

Most South African enterprises have been discussing sovereign AI for about eighteen months now. Very few can say which of those scenarios they have actually closed.

Part of the reason is that the framing was imported. In Europe, sovereign AI is a conversation about the AI Act — risk tiers, conformity assessments, obligations that attach to model providers. In the United States it is a conversation about chips, compute capacity and national capability. Both are serious conversations. Neither of them helps a bank in Sandton decide where to run a model next quarter.

The local question is narrower, and unlike the imported ones it is actually answerable. Can an enterprise under South African law account for what its AI does, where the data sits, and whose courts can reach it?

AI you keep legal control of

The definition fits in a sentence. Sovereign AI is AI where your data, your model, and the systems running them stay under your own country’s law, and out of reach of anyone else’s.

That definition does two useful things.

It separates sovereignty from patriotism, which is where most commentary goes wrong. Sovereignty is not a preference for local suppliers, and buying local does not automatically deliver it. A South African company reselling foreign infrastructure has not changed whose law governs that infrastructure.

And it makes the real point: this is a question about law, not geography. Residency is where. Sovereignty is whose. That distinction is the one the whole topic turns on, and it is the one most often collapsed. Residency asks which building the bytes are in. Sovereignty asks who can compel their release, and what they would get if they did.

The rules predate your AI

There is a persistent belief that South Africa is waiting for AI regulation, and that until it arrives there is nothing to comply with. That is not the position. There is no AI Act here, but there is a stack of law that already binds you, and it has been accumulating for over a decade.

• 2013 — the Protection of Personal Information Act is signed into law.
• 2018 — the Prudential Authority issues Directive 3 and Guidance Note 5, effective 1 October, governing cloud and offshoring for banks.
• 2021 — POPIA becomes fully enforceable on 1 July.
• 31 May 2024 — the National Data and Cloud Policy is published.
• April 2025 — amended POPIA regulations take effect.
• June 2025 — the Joint Standard on Cybersecurity and Cyber Resilience comes into force.

POPIA restricts cross-border transfers unless the recipient is under protections substantially similar to its own. Penalties reach R10 million, and in severe cases imprisonment — and those consequences attach to responsible individuals, not to the company as an abstraction. That is a materially different conversation from a budget line item, and it is worth having before an incident rather than during one.

On the other side of the same arrangement sits the mechanism that makes the opening scenario real. The United States’ Clarifying Lawful Overseas Use of Data Act, passed in 2018, allows US authorities to compel a US-headquartered provider to produce data it controls, regardless of which country that data is stored in. Storage location is not the operative fact. Corporate control is.

Three things, not one

Most sovereignty reviews check where the data sits and stop there. That is one layer of three, and it is the least protective of them.

Your data. Where it lives, and who can demand it. This is the layer everyone checks, and the only one most vendor questionnaires ask about. It is also the easiest to satisfy on paper, which is precisely why it gets checked first and treated as conclusive.

Your model. What it was trained on, and who holds the weights. A model you call over an API is a model somebody else controls. If they change it, retire it, reprice it, or are compelled to disclose what passed through it, none of that is your decision. You may have built a business process on top of an asset you cannot move, cannot inspect, and cannot guarantee will exist in its current form next year.

Your operations. Who runs the system, under whose law, and who holds the keys. This is the layer that determines what a lawful order can actually produce. A local data centre operated by a foreign entity is a local building under foreign control — the address is South African, the corporate obligation is not.

A review that clears the first layer and ignores the other two has not established sovereignty. It has established residency and filed it under a different name.

Four moves, in order of how much they change

01. Know which layer you have solved. Write down what you have actually verified for the model and operations layers, not just the data layer. The gap between what is verified and what is assumed is usually the finding.

02. Ask the jurisdiction question directly. Not where the data is stored. Which entity is the contracting party, and which law governs it. The answer is often a different company to the one on the invoice, incorporated somewhere you have not considered.

03. Separate what needs sovereignty from what does not. Not every workload carries the same exposure. Treating everything as sovereign is expensive, and it slows down the things that could have moved fast. This is the step that keeps a sovereignty programme affordable enough to survive its first budget review.

04. Decide it at design time. Sovereignty is cheap to build in and expensive to retrofit. It is an architecture decision, not a procurement one, and the moment to make it is before the first workload lands.

The question none of it answers

Here is the part that catches the organisations who do all of the above, and do it well.

Local data. Local model. Local operations. Contracts under South African law. Every box ticked, signed off, presented to the board.

Sovereignty tells a regulator where your systems run and whose law governs them. It says nothing about whether the thing you shipped is the thing your business asked for.

And Directive 3 does not only require you to know where your data is. It requires that your arrangements do not inhibit a regulator’s ability to do its job. If the regulator asks what a model decided, on what basis, and who approved the change that caused it — “the AI decided” does not meet that standard in any jurisdiction.

So there are two questions, and they get asked in the same meeting.

Where does it run, and under whose law?

What did it do, and who said so?

Most organisations have prepared for one of them. The second is a delivery evidence problem rather than an infrastructure one, and we have written about it separately — the four questions your board will ask about your last release.

What this is built on

• Protection of Personal Information Act 4 of 2013. Fully enforceable from 1 July 2021. Amended regulations effective April 2025.
• National Data and Cloud Policy. Published 31 May 2024, Department of Communications and Digital Technologies.
• Directive 3 of 2018 and Guidance Note 5 of 2018. Prudential Authority, SARB. Effective 1 October 2018.
• Joint Standard on Cybersecurity and Cyber Resilience. Prudential Authority and FSCA. In force from June 2025.
• Clarifying Lawful Overseas Use of Data Act. United States, 2018.
• National AI Policy Framework. Department of Communications and Digital Technologies, October 2024.

General commentary, not legal advice.

Deon Thomas · CEO, eBlocks Software