Does Section 72 ban using OpenAI or other US-hosted models?

No. Section 72 does not ban cross-border transfers; it conditions them. You may transfer personal information abroad if one of the listed grounds applies — for example the data subject consents, the transfer is necessary to perform a contract, or the recipient is bound by binding rules or contract clauses providing an adequate level of protection. The practical path is a data processing agreement with adequate-protection clauses plus data minimisation.

Is anonymising the data before the API call enough to avoid POPIA?

If data is genuinely de-identified so that no one can be re-identified, it falls outside POPIA. The bar is high: pseudonymisation (replacing names with tokens you can reverse) is not de-identification. True anonymisation that survives Section 72 review usually requires removing or generalising enough fields that re-identification is not reasonably possible.

Does hosting the model in af-south-1 remove the Section 72 question entirely?

For the inference step, yes — if the model runs in AWS af-south-1 and the data never leaves South Africa, there is no cross-border transfer to justify. That is the core reason our architecture defaults to in-region hosting. See our data residency explainer for what "hosted in South Africa" actually means.

Insights / Compliance / POPIA Section 72 and Cross-Border AI: Can You Legally Use OpenAI in South Africa?

Compliance24 May 2026 · 9 min read

POPIA Section 72 and Cross-Border AI: Can You Legally Use OpenAI in South Africa?

Section 72 of POPIA governs sending personal information outside South Africa. Here is what it actually requires of an AI architecture that calls a US-hosted model — and the patterns that keep you compliant.

Tumiso Graig Ramaboya

Founder, CEO & POPIA Information Officer

sonofgraig Insights cover on POPIA Section 72 and cross-border AI transfers, over a blue node-lattice motif.

The most common compliance question we get from South African enterprises is some version of "are we allowed to send our data to OpenAI?" The answer is more nuanced than yes or no, and it lives in Section 72 of the Protection of Personal Information Act. This piece explains what Section 72 requires, the grounds that make a cross-border transfer lawful, and the architectural patterns that keep an AI system on the right side of it. It is general guidance, not legal advice.

What Section 72 actually requires

Section 72 prohibits transferring personal information about a data subject to a third party in a foreign country unless one of several grounds applies: the recipient is subject to a law, binding corporate rules, or a binding agreement that provides an adequate level of protection; the data subject consents; the transfer is necessary to perform or conclude a contract in the data subject's interest; or the transfer benefits the data subject and consent is not reasonably practicable. The operative idea is adequacy of protection at the destination, not a prohibition on movement.

For an AI system, the "transfer" is the moment a prompt containing personal information leaves South Africa for a model endpoint hosted elsewhere. That is the event Section 72 cares about. Everything in the architecture flows from deciding whether — and how — that event happens.

Three architectural patterns, three risk profiles

There are essentially three ways to design around Section 72, in descending order of cleanliness.

Pattern A — keep inference in-region. Run the model in AWS af-south-1 (or another South African facility) so the prompt never crosses a border. There is no cross-border transfer to justify, so Section 72 simply does not engage for the inference step. This is the pattern we default to; the reasoning is in the data residency explainer.

Pattern B — transfer under an adequate-protection agreement. If a workload genuinely needs a model only available abroad, the transfer can be made lawful with a data processing agreement that binds the recipient to adequate protection, combined with strict data minimisation so only the fields the task requires ever leave. This is viable but adds contractual and audit overhead.

Pattern C — de-identify before transfer. If the data sent abroad is genuinely anonymised so re-identification is not reasonably possible, it is no longer personal information and Section 72 does not apply. The bar is high and easy to get wrong — tokenising names is not anonymisation.

Data minimisation is the cheapest control you are not using

Whatever pattern you choose, sending less data is the highest-leverage control available. Most prompts carry far more personal information than the task needs — a whole customer record when the model only needs an account status, a full document when a single clause is in question. Minimising the payload reduces both the Section 72 surface and the blast radius of any leak. It is also free.

What the audit trail has to show

Whatever you decide, you must be able to prove it after the fact. A defensible AI system logs, per inference: who initiated it, what data was included, which model and region served it, and the lawful basis for any cross-border element. If you cannot answer those four in one query, you have a logging system, not a compliance posture. This is exactly what a Governance Hub is for, as we argue in the governance piece.

How we help

Our default architecture keeps inference in af-south-1, so Section 72 does not engage for the model call at all. Where a workload needs more, our AI Governance & Ethics Audit maps every transfer against Sections 11, 19, and 72 and produces a board-ready remediation roadmap signed by a registered Information Officer. The full statutory walkthrough is in the POPIA sections deep-dive, and our standing compliance posture is on the POPIA page.

Frequently asked

Does Section 72 ban using OpenAI or other US-hosted models?: No. Section 72 does not ban cross-border transfers; it conditions them. You may transfer personal information abroad if one of the listed grounds applies — for example the data subject consents, the transfer is necessary to perform a contract, or the recipient is bound by binding rules or contract clauses providing an adequate level of protection. The practical path is a data processing agreement with adequate-protection clauses plus data minimisation.
Is anonymising the data before the API call enough to avoid POPIA?: If data is genuinely de-identified so that no one can be re-identified, it falls outside POPIA. The bar is high: pseudonymisation (replacing names with tokens you can reverse) is not de-identification. True anonymisation that survives Section 72 review usually requires removing or generalising enough fields that re-identification is not reasonably possible.
Does hosting the model in af-south-1 remove the Section 72 question entirely?: For the inference step, yes — if the model runs in AWS af-south-1 and the data never leaves South Africa, there is no cross-border transfer to justify. That is the core reason our architecture defaults to in-region hosting. See our data residency explainer for what "hosted in South Africa" actually means.