This is the practical close. Five articles of understanding are worth nothing if the next supplier meeting goes the way the last one did.
You do not need technical vocabulary to hold a supplier to account here. You need six questions and the confidence to keep asking until you get specifics.
The six questions, and why each one works
"What exactly will this tool see?" Insist on a list of fields, not a category. "Your customer data" is not an answer; "name, email, order number and order history" is. This one question resolves most residency uncertainty, because you frequently discover the tool does not need half of what it was going to be given.
"Which country will it be processed in?" Note the word processed, which after article one you now know to distinguish from available and stored. Acceptable answers name a country or a specific list of countries. "Our global infrastructure" is not one.
"Is that in writing, in our contract?" The single highest-value question in the set. A verbal assurance from a salesperson is not a section 72 route. A clause is. Ask which document and which section.
"What is kept afterwards, and for how long?" Retention, in days, for the prompt, the output, any cache and the logs. Remember from article four that logs of an AI conversation contain the conversation.
"Who at the supplier can read it?" Every serious provider has a documented support-access process with approvals and logging. Ask to see it. The failure mode is not that such access exists — it is that nobody on your side has ever read the process.
"What happens if the service fails over?" The normal-running answer is often in-country and the failover answer often is not. This is documented, and it is almost never asked.
A supplier who answers all six in writing has done the work. A supplier who answers in adjectives — secure, compliant, enterprise-grade, world-class — has probably not been asked before. That is not necessarily disqualifying, but it tells you where you are.
Two phrases deserve specific scepticism. "It's POPIA compliant" is not a meaningful claim about a product: compliance is a property of your processing, not of a tool you bought. And "your data is encrypted" answers a different question entirely — encryption protects data from third parties, and says nothing about which country the decrypted text is read in.
The risk that never appears in a procurement process
Everything above assumes a considered decision about a system. The most common way personal information reaches an overseas AI service in a South African organisation is not that.
It is a member of staff, on a deadline, pasting a customer complaint into a free chat assistant to get help drafting a reply. Or a manager uploading a spreadsheet of employee performance data to get it summarised. Or someone dropping a scanned document into a translation tool.
Nobody experiences those as sending confidential information to a third party in another country. Every one of them is.
You will not fix this with a policy nobody reads, and you will not fix it by banning things — the deadline does not go away, and prohibition just moves the behaviour onto personal devices where you cannot see it at all.
What works is closer to three things.
Give people a sanctioned option. Most of this behaviour is well-intentioned people trying to do their jobs. If there is an approved tool that handles the green use cases, the improvised route loses most of its appeal.
Teach one rule, not a policy. The rule that travels is: if it names a person, it does not go in the box. People remember that. They do not remember a nine-page acceptable-use standard.
Make it easy to ask. A named person who will answer "can I use this for that?" within a day, without making the asker feel stupid, prevents more incidents than any amount of monitoring.
The one page worth keeping
For each AI use case, keep a single page. Not a compliance programme — a page.
Seven lines. A privacy officer, an auditor or a nervous executive can read it in two minutes and know where they stand.
Two of the lines matter more than the rest.
"Which route applies, and where is it written" — this is the section 72 question from article two, and it is the one that turns a vague comfort into an actual position.
"When to re-check" — a date, not "periodically". Provider regions, deployment types and model availability change without your requirements changing. An architecture that was correct in March can be wrong in September with nobody having touched it. A date in the diary is the only thing that catches that.
Written once, this page survives the staff change that would otherwise reset the entire discussion. That is a bigger benefit than it sounds: a great deal of institutional knowledge about why a decision was made evaporates when one person moves on, and the organisation ends up relitigating a settled question from scratch.
Where this series leaves you
Six articles, and the argument is short enough to repeat in a meeting.
AI is a computer in a building, and the building is in a country. "Local" means three different things and you should always ask which. POPIA sets conditions on sending personal information abroad rather than forbidding it — five routes, and almost everyone is using the contract route. Not all data is the same, and a large share of everyday AI use touches no personal information at all. Tracing one real interaction end to end will teach you more than any policy document. And a single page per use case, with a date on it, is most of what governance actually requires.
None of that needs you to be technical. All of it needs someone to ask the questions out loud.
The organisations that will do well with AI here are not the ones with the strongest opinions about it. They are the ones that can say, for each use, what data is involved, where it goes, under which route, and who decided.
This series is a plain-language explainer, not legal advice, and I am not a lawyer. POPIA, the National Data and Cloud Policy and sector regulations have real detail behind them. Your legal and privacy people make the determination for your organisation — what this series is for is helping you brief them with facts instead of anxiety.
For the technical companion — how to verify a provider's regional claims, what deployment types do to processing location, and how to read the provider matrices — see AI models available in South Africa: what "available" really means.
How CloudNala can help
We help organisations get from "we're worried about AI and POPIA" to a short, written, defensible position per use case — the classification, the trace, the supplier questions and the one-pager. It is deliberately lightweight. The goal is not a governance programme; it is that the next time someone asks whether you can use AI for something, a specific person can give a specific answer, and point at where it is written down.
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.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za