Applied AI insights
Sovereign AI and POPIA
POPIA, data residency and sovereign AI.
Written for Information Officers, legal advisers and the operators who sit between them: what hosting location actually changes, how POPIA treats cross-border AI processing, and a practical way to structure sensitive workloads.
Hosting an AI system in South Africa answers one question — where processing happens. It does not answer who may access the data, why it is processed, how long it is kept, or what happens when something goes wrong. This page sets out what residency genuinely changes under the Protection of Personal Information Act (POPIA), and the questions that remain either way.
Does using an offshore AI model automatically breach POPIA?
No. Using an offshore AI service does not automatically breach POPIA. If personal information is transferred to a recipient in a foreign country, at least one of the conditions in section 72 (PDF) must be satisfied. Which condition applies, and whether the surrounding processing is lawful, depends on the specific data, purpose, parties, contracts and safeguards.
Hosting location is one part of the assessment, not the assessment itself. Local hosting does not make processing compliant, and offshore hosting does not make it unlawful. The section 72 conditions include, among others, a recipient bound by law, binding corporate rules or a binding agreement providing substantially similar protection; the data subject’s consent; or necessity for the performance of a contract.
Section 72 is also not the only part of POPIA that matters to an AI workflow. The Act’s conditions for lawful processing apply throughout: purpose limitation, minimality and retention; security safeguards and operator arrangements (sections 19 to 22, PDF); incident response; and the data subject’s rights of access and correction.
AgentAligned designs, builds and evaluates these systems; we do not make the legal determination for any reader’s workflow. The responsible party’s Information Officer and legal advisers own that call, and workload-specific legal advice may be required.
Terms used on this page
These terms travel together in vendor decks and are often treated as interchangeable. They are not.
- Data residency
- Where data is physically stored or processed.
- Data localisation
- A requirement or policy that certain data remain within a territory.
- Data sovereignty
- The broader legal and governance context that applies to data: which laws reach it, who can compel access to it, and under whose authority it is processed.
- Sovereign AI
- An industry term for AI capability under local control — infrastructure, models, data or governance, depending on who is speaking. It is not, by itself, a POPIA compliance status.
- Responsible party
- The body that, alone or with others, determines the purpose and means of processing personal information. The accountable role under POPIA, comparable to a “controller” in other regimes.
- Operator
- A person who processes personal information for a responsible party in terms of a contract or mandate, without coming under its direct authority.
- Subprocessor / onward recipient
- A further provider that an operator or vendor relies on, or any other party to whom personal information flows downstream.
The responsible party and operator entries paraphrase the definitions in section 1 of POPIA (PDF); the Act’s wording governs.
What South African data residency does and does not solve
Can help with
- May reduce or avoid a section 72 transfer issue where the relevant personal information genuinely remains in South Africa
- Client or sector policies that require local processing
- Lower latency to the local systems the workflow reads and writes
- Clearer answers to residency questions in due-diligence questionnaires
Does not solve
- Purpose limitation, minimality or retention
- Access control, operator agreements and accountability
- Model quality, hallucination or evaluation
- Security incidents, logging or breach response
“Genuinely remains in South Africa” is itself a finding, not a setting. To support it, the assessment must cover:
- Primary storage and processing
- Backups and disaster recovery
- Failover regions
- Remote support access
- Logging and telemetry
- Content moderation or abuse monitoring
- Subprocessors and onward transfers
- Use of data for model training, evaluation or service improvement
- The contracting entity and the countries services are delivered from
A South African hosting region also does not by itself determine the provider’s governing law, contracting entity, remote-access paths or subprocessor locations. Those follow the contract and the provider’s operating model, and belong in due diligence rather than in assumptions.
Framework
Separate the data plane from the control plane.
A workable pattern for sensitive workloads: decide separately where the personal information lives and where the reasoning runs, then minimise what crosses between them. This is an architecture and risk-management framework, not a legal safe harbour.
DATA PLANE
Where personal information lives and is matched
Stored records, identifiers, source documents, matching operations and audit logs. Kept in the client’s systems or a South African environment where required. Fields are minimised, pseudonymised or masked before anything leaves.
CONTROL PLANE
Where instructions and reasoning run
Orchestration, prompts, instructions, routing and model inference — plus evaluation and monitoring. May use a frontier API, a locally hosted model or a private environment, chosen per task once the data-plane rules fix what it is allowed to see.
Separating the data plane from the control plane can reduce exposure, but the labels do not determine the legal outcome. Prompts, retrieved context, model outputs, logs and telemetry may themselves contain personal information.
- Personal information should cross between the planes only where the workflow requires it.
- Consider redaction, pseudonymisation and field-level minimisation before anything crosses.
- Data should not be described as anonymous unless it has genuinely been de-identified to the applicable standard.
- Each component, provider and transfer path — in both planes — still needs its own assessment.
The design question becomes narrow and answerable: which fields, if any, must cross the boundary for the workflow to function, and under which section 72 condition do they travel? Whether the resulting system is reliable enough to run is then tested against a golden evaluation set before launch.
Who is responsible for what
The responsible party remains accountable for lawful processing, including the processing it hands to providers. An AI vendor is not automatically just an “operator”: the role depends on who determines the purpose and means of the processing, and on what the provider does with the data. A provider that uses customer content for its own service improvement is not acting purely on the responsible party’s instructions for that use.
In practice that means identifying each provider’s role for each workflow, and putting written operator arrangements in place where the operator role applies. POPIA requires anyone processing for a responsible party to do so only with its knowledge or authorisation and to treat the information as confidential, and requires the responsible party to secure the operator’s security measures in a written contract — see sections 20 and 21 of the Act (PDF).
Incident obligations run through the same chain. An operator must notify the responsible party immediately where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person; the responsible party notifies the Information Regulator and, in most cases, the data subject — see section 22 and the Regulator’s fact sheet on handling security compromises. Subprocessors and onward transfers behind a provider need the same attention as the provider itself.
There is no universal role classification for AI vendors; the same provider can hold different roles in different workflows. This allocation of roles is one of the governance items we build into every engagement.
Provider due-diligence: the questions to ask
Twenty questions, grouped the way procurement, security and legal teams actually divide the work. Take them into vendor conversations; the useful answers are documents and contract clauses, not verbal assurances.
Location and access
- 01Where are prompts, files, outputs and metadata processed and stored?
- 02Which regions serve primary processing, backups, failover and disaster recovery?
- 03From which countries can support or engineering teams access customer data?
- 04Which legal entity is the contracting party, and where is it established?
Data use and retention
- 05Is customer data used for training, evaluation, safety testing or service improvement?
- 06Can that use be disabled in the contract, in writing?
- 07What retention applies to prompts, outputs, logs and backups?
- 08How is deletion carried out — including from backups — and on what timescale?
Contracts and transfers
- 09Will the provider sign an operator arrangement with documented security safeguards that reflects POPIA obligations?
- 10Which section 72 condition covers each cross-border leg, and what evidence supports it?
- 11What is the complete subprocessor list, and how are changes notified?
- 12How are data subject requests supported: access, correction, deletion and objection?
Security and incidents
- 13How is data encrypted in transit and at rest?
- 14Who holds the encryption keys, and are customer-managed keys available?
- 15What access controls, privileged-access management and audit logs are in place?
- 16How quickly are security compromises notified, and who is responsible for each step?
- 17Which independent security certifications exist — as supporting evidence, not as proof of POPIA compliance?
Exit arrangements
- 18How is data exported at the end of the contract, and in which formats?
- 19What is deleted at exit — including backups — and how is deletion evidenced?
- 20What portability support exists for moving the workload to another provider?
Higher-risk workloads: take tailored advice before you build
Some processing warrants legal, privacy and security review from the start rather than at sign-off:
- Special personal information (POPIA sections 26 to 33)
- Children’s information (sections 34 and 35)
- Health, financial, biometric or employment records
- Automated decisions with significant consequences for the data subject
- Large-scale or systematic monitoring
This page is a practice note on architecture and due diligence, not an exhaustive POPIA guide.
Primary sources
Read the primary material rather than summaries of it — including ours. On this page, the wording of the Act and the Regulator’s guidance are the authorities; the plane framework and the checklist are AgentAligned’s implementation guidance.
- The ActProtection of Personal Information Act 4 of 2013 (PDF, justice.gov.za) — see the definitions in section 1; sections 19 to 22 on security safeguards, operators and notification; sections 26 to 35 on special personal information and children’s information; and section 72 on transfers outside the Republic.
- Regulator guidanceInformation Regulator: Chapter 9, transborder information flows (inforegulator.org.za) — the Regulator’s knowledge-base category on cross-border transfers.
- Regulator guidanceInformation Regulator: fact sheet on the handling of security compromises (inforegulator.org.za) — notification expectations where personal information is compromised.
Bring one workflow, its data path and your provider shortlist. We will help identify the operational, evaluation and governance questions that need answering.
Enquiries through this site are handled as described in our privacy notice.