Most large AI models run on servers outside South Africa, so when your app sends a customer's email, complaint or CV to an AI API, you are probably transferring personal information to a third party in a foreign country. Section 72 of the Protection of Personal Information Act 4 of 2013 (POPIA) allows that only on specific grounds. This article explains those grounds, how they apply to AI APIs, and the engineering habits that reduce your risk: send less, strip identifiers, and document every provider.
Is an AI prompt really a cross-border transfer?
Ask three questions:
- Does the prompt contain personal information? POPIA defines personal information broadly: names, contact details, ID numbers, opinions about a person, correspondence, and more. It covers identifiable juristic persons (companies) as well as natural persons. A support ticket pasted into a prompt almost always contains personal information.
- Does it go to a third party? An external AI provider is a third party, even if it acts as your operator.
- Is that third party in a foreign country? If the model is hosted abroad, yes.
If all three are true, section 72 applies. Note that POPIA has no general rule that data must stay in South Africa; section 72 is about the conditions for sending it out. Our article on data residency in South Africa covers that distinction.
The five grounds in section 72
A responsible party may transfer personal information to a third party in a foreign country only if:
| Ground | Section | How it applies to AI APIs |
|---|---|---|
| Adequate protection | 72(1)(a) | The provider is bound by a law, binding corporate rules or a binding agreement giving protection substantially similar to POPIA, including for onward transfers. This usually means reviewing the provider's data processing terms. |
| Consent | 72(1)(b) | The data subject consents. Workable for opt-in features ("Summarise my document with AI"), awkward for background processing. |
| Contract with the data subject | 72(1)(c) | The transfer is necessary to perform a contract with the person. "Necessary" is a real test - convenience is not the same as necessity. |
| Contract in their interest | 72(1)(d) | Necessary for a contract between you and a third party that is in the data subject's interest. |
| Their benefit | 72(1)(e) | For their benefit, consent not reasonably practicable, and they would likely consent. A narrow fallback. |
For special personal information (health, religion, biometrics, criminal behaviour and so on) and children's information, section 57 may require prior authorisation from the Information Regulator before a transfer to a country without adequate protection. As a rule of thumb, keep special personal information out of AI prompts unless you have taken advice.
What to check in an AI provider's terms
When relying on adequate protection, read the provider's commercial or API terms and data processing addendum for:
- Training use - whether API inputs are used to train models, and whether you can opt out.
- Retention - how long prompts and outputs are kept, for example for abuse monitoring.
- Sub-processors and regions - where processing happens and who else is involved.
- Security commitments - encryption, access controls, breach notification to you.
- Onward transfers - protections when the provider passes data to its own sub-processors.
Terms change, so record the version and date you reviewed. The other POPIA conditions still apply too: section 19 security safeguards, and section 21 written contracts with operators.
Engineering habits that reduce risk
The best transfer is the one you never make. Before an AI call, ask whether the model actually needs the personal details.
1. Minimise and pseudonymise
Replace identifiers with placeholders before sending, then restore them in the response if needed:
const PATTERNS = [
{ re: /[\w.+-]+@[\w-]+\.[\w.-]+/g, label: 'EMAIL' },
{ re: /\b\d{13}\b/g, label: 'ID_NUMBER' },
{ re: /(?:\+27|\b0)\d{9}\b/g, label: 'PHONE' },
];
function pseudonymise(text) {
const map = new Map();
let i = 0;
let out = text;
for (const { re, label } of PATTERNS) {
out = out.replace(re, (match) => {
const key = `[${label}_${++i}]`;
map.set(key, match);
return key;
});
}
return { text: out, map };
}
function restore(text, map) {
let out = text;
for (const [key, value] of map) out = out.replaceAll(key, value);
return out;
}
const { text, map } = pseudonymise('Call Thandi on 0821234567 or [email protected]');
console.log(text); // Call Thandi on [PHONE_2] or [EMAIL_1]
Regex redaction is not perfect - names and addresses slip through - so treat it as a risk reducer, not a guarantee.
2. Keep prompts and outputs out of your logs
Logging full prompts creates another store of personal information with its own retention and security obligations. Log the model, token counts and a request ID instead.
3. Make AI features explicit
A visible "Use AI to draft a reply" button with a short notice is easier to justify under openness (sections 17-18) and, where needed, consent, than silent background processing.
4. Keep a provider register
For each AI provider: data sent, region, legal ground under section 72, terms reviewed and date, retention and training settings.
Using an AI gateway
NewHost offers an OpenAI-compatible AI gateway at https://api.newhost.co.za/ai/v1, with models named provider/model (for example anthropic/claude-opus-5) across providers such as Anthropic, OpenAI, Google Gemini and Mistral. The gateway records usage - model, tokens and cost - but does not store your prompts or responses.
Be clear about what that does and doesn't mean: the request is still forwarded to the model provider you choose, which may process it outside South Africa. The gateway simplifies billing in rand and gives you one integration point, but the section 72 assessment for each underlying provider remains your responsibility.
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.newhost.co.za/ai/v1',
apiKey: process.env.NEWHOST_AI_KEY,
});
// pseudonymise() is the helper from the previous example
const ticketBody = 'Hi, this is Thandi ([email protected]). My invoice is wrong.';
const { text: safeText } = pseudonymise(ticketBody);
const completion = await client.chat.completions.create({
model: 'anthropic/claude-opus-5',
messages: [
{ role: 'system', content: 'Summarise this support ticket in two sentences.' },
{ role: 'user', content: safeText },
],
});
console.log(completion.choices[0].message.content);
See the developer docs for authentication and available models.
Frequently asked questions
Is it illegal under POPIA to use ChatGPT or Claude with customer data?
Not automatically. It is lawful if a section 72 ground applies and you meet POPIA's other conditions, such as security safeguards and purpose limitation. Minimising the personal information you send reduces the risk considerably.
Does pseudonymising the prompt take it outside POPIA?
Pseudonymised data can still be personal information if it can be re-identified, and you hold the mapping. It does reduce what the provider receives, which strengthens your position. Properly de-identified information, which cannot reasonably be re-identified, falls outside POPIA.
Do I need customer consent to use an AI API?
Consent is one ground, not the only one. Many businesses rely on the provider's binding data protection terms (adequate protection) or on the transfer being necessary for a contract. The right ground depends on your use case, so take professional advice for your specific situation.
What about internal staff using AI chat tools?
The same analysis applies when staff paste customer information into public AI tools. A written policy on what may and may not be shared is a practical organisational safeguard under section 19.
For more on the rest of POPIA's developer obligations, read POPIA for developers. To try the rand-billed AI gateway alongside your hosted apps, see our automation and API services.