The Protection of Personal Information Act has been enforceable since July 2021. By now, most South African organisations of any size have done something in response: appointed an information officer, drafted a privacy policy, maybe run a data mapping exercise. The compliance box is ticked.
What far fewer organisations have done is think carefully about what POPIA means for the AI systems they are now building, piloting, or purchasing. This gap matters more than it used to, because AI changes the nature of personal information risk in ways that standard compliance programmes were not designed to address.
The three ways AI changes your POPIA exposure
Training data and the lawful processing question. Every AI model learns from data. If your model — whether built in-house or fine-tuned from a foundation model — was trained on data that includes personal information, you need to be able to answer: was there a lawful basis for processing that data for training purposes? This is not always straightforward. Data that was collected with consent for one purpose (say, improving customer service) may not have been collected with consent for the purpose of training a model that will be used to make decisions about future customers.
POPIA's principle of purpose limitation is clear: personal information may only be processed for the purpose for which it was collected, or a compatible purpose. "Compatible" has to be assessed case by case, and the Information Regulator has not yet published extensive guidance specific to AI. The absence of clear guidance is not a defence — it is a planning risk.
Automated decision-making and the right to object. Section 71 of POPIA gives data subjects the right not to be subject to a decision that has a significant effect on them if that decision is made solely on the basis of automated processing. This provision is structurally similar to Article 22 of GDPR, and it is directly relevant to any organisation using AI to make or substantially inform decisions about credit, employment, insurance, benefits, or access to services.
The key word is "solely." If a human reviews the AI's output before a decision is made, the provision is less likely to apply. But "review" needs to mean genuine review — not rubber-stamping a recommendation that the reviewer has no practical ability to second-guess. The growing tendency to use AI recommendations in high-volume, time-pressured decision contexts creates real exposure here.
Data subject access requests and model explainability. Under POPIA, data subjects have the right to know what personal information you hold about them and how it is being processed. If an AI system is generating predictions, scores, or recommendations based on a person's data, that processing needs to be explainable — at least at a level of abstraction that a non-technical person can understand.
This creates an architectural requirement. Black-box models that produce outputs without explainable reasoning are harder to defend in response to a data subject access request. Organisations building AI into high-stakes workflows need to make explainability a design requirement, not an afterthought.
What good POPIA-aligned AI governance looks like
The organisations that are ahead of this issue have done four things that distinguish them from the ones that will have problems.
They mapped their AI inventory. Before you can govern AI for POPIA purposes, you need to know what AI systems you are running, what data they process, and what decisions they influence. This sounds obvious. In practice, AI proliferates faster than governance catches up — shadow AI, third-party tools with AI features, model APIs embedded in existing products — and most organisations do not have a complete picture.
They extended their data processing register to cover AI use cases. A standard ROPA (Record of Processing Activities) documents who holds what data and why. An AI-extended ROPA goes further: it documents what models are in use, what data was used to train or fine-tune them, what outputs are generated, and how those outputs affect data subjects. This is the foundation for everything else.
They treated purpose limitation as a design constraint. Rather than collecting data broadly and figuring out the AI use case later, the better approach is to define the AI use case first, identify the minimum data required, and design collection accordingly. This is good AI practice and good POPIA practice simultaneously — and it produces better models, because narrowly scoped data tends to be higher quality.
They built human review into high-stakes AI decisions. Not as a compliance fig leaf, but as a genuine check. The reviewer needs to understand what the model is doing, have access to the inputs, and have the authority and practical ability to override the recommendation. This requires training, process design, and tool design — not just a policy document.
The vendor due diligence angle
If you are using third-party AI tools — which, in 2026, almost certainly means you are — your POPIA obligations do not stop at your own systems. Section 21 of POPIA places obligations on responsible parties (you) with respect to operators (your vendors) who process personal information on your behalf. If your AI vendor processes personal information of South African data subjects, you need a data processing agreement in place that meets POPIA's requirements.
This includes: ensuring the vendor processes data only on your instructions, maintains appropriate security measures, notifies you of breaches, and does not subcontract processing without your knowledge. Many international AI vendors have GDPR-compliant data processing agreements that cover most of these requirements, but not all. Review them with POPIA's specific requirements in mind, not GDPR's.
Where to focus first
If you are working through this for the first time, the priority areas are: AI systems that make or influence decisions about individuals (lending, employment, insurance, service access); AI systems that process special categories of personal information (health data, financial data, biometric data); and AI systems where the underlying model training data is unclear or old.
These are the areas of highest risk and the areas where the Information Regulator is most likely to focus attention as enforcement matures. Getting ahead of them is significantly less expensive than responding to an investigation or complaint after the fact.
CloudNala advises South African organisations on data architecture and AI governance that is built for the local regulatory environment. Get in touch if you want a practical assessment of your current exposure.