When public bodies talk about sovereign AI, the conversation usually collapses into one question: is the data stored in the country? Since the hyperscalers opened South African regions, and since AI providers began offering in-country processing in some markets, the answer is increasingly yes. The Abu Dhabi Machine-Readable Government initiative discussed in Part 1 is described as running on in-country inference in the UAE, and that was presented, reasonably, as part of a sovereign approach.
Data residency matters. But a state can have every byte stored locally and every prompt processed locally and still not control the service. It may not hold the keys. It may not be able to see or stop changes the provider makes. Its audit trail may sit in another jurisdiction. A foreign court may be able to compel the provider. And it may have no practical way to leave.
Sovereignty is a set of control questions, not a location. This part sets out eight of them and how a public body can assess where it stands.
Why the question has become urgent
Three things have changed. AI services now process the content of public work, not just store records: draft decisions, case evidence, internal deliberation. The services are more concentrated, with a small number of model providers behind most deployments. And the services change continuously, with model and platform updates that the customer does not schedule.
In South Africa, the policy context is also active. The National Data and Cloud Policy was published in May 2024. POPIA governs personal information, including its transfer abroad under section 72, which, as we have explained before, sets conditions for transfers rather than forbidding them. Sector rules, security classifications and departmental policies add their own requirements. None of these reduce sovereignty to a single question either.
Eight layers of control
1. Data at rest. Where are records, documents, embeddings and backups stored? This is the familiar question, and it includes the less obvious stores: vector indexes, caches, evaluation datasets and exported reports.
2. Inference. Where are prompts and the information in them processed, and is anything retained afterwards? An in-country region for storage does not guarantee in-country processing for every AI feature. As our earlier piece on where your AI is allowed to run showed, the answer can differ by model, feature and contract tier.
3. Control plane. Who can change the service: deploy a new model version, alter a safety filter, modify configuration, or suspend it? For most managed AI services, the provider controls this, and the customer sees changes after they happen. For a public body, the practical questions are what notice is given, what can be pinned, and whether changes can be tested first.
4. Identity. Whose identity system grants access to the service and its data? If the state's own directory governs every user and every service account, the state can revoke access. If access depends on accounts the provider manages, it cannot fully.
5. Keys. Who holds the encryption keys, and can the provider operate the service without them? Customer-managed keys, and in some services keys held in the customer's own hardware security module, change what a provider or a party compelling it can access.
6. Logs and evidence. Where does the audit trail live, who can read it, and how long is it kept? For administrative decisions, the evidence of what the AI did is part of the public record. If it sits only in the provider's telemetry, in another jurisdiction, under the provider's retention policy, the state may not be able to produce it when a court or auditor asks.
7. Legal reach. Which courts and authorities can compel the provider to disclose or act? A provider headquartered abroad may be subject to its home country's law regardless of where the data sits. The United States CLOUD Act is the best-known example. Contracts, key control and architecture can reduce the practical exposure; they cannot remove the provider's legal obligations.
8. Exit. Could the service move to another provider, or in-house, within a reasonable period, with its data, configuration, encoded rules, evaluation library and evidence intact? Exit is the layer most often promised and least often tested.
A worked assessment
The fictional Thukela Provincial Licensing Authority is choosing a platform for its AI-assisted licensing service. Its first assessment, illustrative and simplified, looks like this:
| Layer | Position | Action |
|---|---|---|
| Data at rest | South African region, including backups | Confirm embeddings and evaluation data too |
| Inference | In-country for the chosen model; one feature routes abroad | Disable the feature or obtain a POPIA section 72 basis and a policy decision |
| Control plane | Provider-managed; model version can be pinned for 12 months | Contract for advance notice and a test window |
| Identity | Provincial directory, single sign-on | Remove two provider-managed admin accounts |
| Keys | Provider-managed by default | Move to customer-managed keys for case data |
| Logs and evidence | Provider telemetry only | Export decision traces to the authority's own evidence store |
| Legal reach | Provider subject to foreign law | Accept, document, minimise what the provider can read |
| Exit | Not assessed | Require data, rules and library export in open formats; test once a year |
The useful outcome is not a score. It is a list of decisions, some of which the authority can make itself and some of which it can only make through procurement. Part 7 covers how to put the second group into contracts.
Sovereign inference is valuable, not sufficient
In-country inference addresses one important risk: that sensitive public information is processed under another jurisdiction during the AI step. That is worth paying for where the data warrants it, and earlier CloudNala analysis has shown that the constraint has a real price that belongs in the business case.
But a government that negotiates hard on inference location and ignores the control plane, keys, evidence and exit has bought the most visible layer and left the others with the provider. Equally, not every workload needs every layer. A public information chatbot answering questions from published material needs less sovereignty than a service that prepares decisions about individuals. The assessment should be proportionate to the data and the decision.
Concentration is a sovereignty risk too
A further question sits above the eight layers: how many of the state's critical services depend on the same provider, model family or platform? A single dependency creates negotiating weakness and a single point of failure, regardless of where each service is hosted.
The design response is not to avoid large providers, which would usually mean worse services at higher cost. It is to keep the parts that carry public authority portable: the encoded rules, the scenario library, the case records and the evidence store should belong to the state, in formats it can take elsewhere. Then the model becomes a replaceable component, which is how Part 1's operating stack treats it. The After the Hype series looks at the spending side of sovereignty, and when "sovereign" becomes a label for prestige infrastructure rather than control.
Start this week
- For one AI service in use or in procurement, fill in the eight layers, even with "unknown" in several rows.
- Find out whether any feature of that service processes data outside the country.
- List the admin and service accounts that the state's own identity system does not control.
- Confirm where decision evidence is stored and whether you could produce it for a specific case within a week.
- Ask the provider, in writing, what an exit would involve and how long it would take.
Next: Part 6, Digitising bureaucracy is not transformation. All parts are on the series page.
How CloudNala can help
CloudNala runs sovereignty assessments for public bodies adopting AI and cloud services. We work through the eight layers for a specific service, identify which gaps you can close through architecture and which need contract terms or policy decisions, and design the evidence store and export arrangements that keep public authority portable. Where personal information crosses borders, we work alongside your information officer and legal advisers rather than in place of them.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za