A practical, IIBA-aligned checklist for South African compliance officers and IT leaders rolling out AI: how the POPI Act applies to machine learning, what the Information Regulator expects, and the controls to build in before you ship.
The Protection of Personal Information Act (POPIA) is South Africa's primary data-protection law, and it applies to every AI project that ingests, infers from, or generates personal information about a data subject. If you are training a model on customer records, scoring loan applicants, summarising clinician notes, routing service tickets, or running a chatbot on top of your CRM, you are processing personal information under the POPI Act — and the Information Regulator expects you to demonstrate it. This guide is a practical POPIA compliance checklist written specifically for AI and data teams operating in South Africa. Start with lawful basis. Section 11 of the POPI Act limits processing to a defined set of grounds: consent, contract, legal obligation, protection of a legitimate interest, public-law duty, or a documented legitimate interest of the responsible party. For AI use cases, identify the lawful basis per processing activity, not per system. Model training, inference, human review, and re-training on production data are separate activities and often need separate justifications. Document the basis in your Record of Processing Activities (ROPA) and reference it in your privacy notice. Run a Personal Information Impact Assessment (PIIA) before the build, not after. Section 38A and the Regulator's guidance treat the PIIA as the AI equivalent of a DPIA: scope of personal information, categories of data subjects, special personal information (health, race, biometrics, children), automated decision-making impact, cross-border flow, retention period, and the safeguards that bring residual risk to acceptable levels. Re-run the PIIA whenever the model's purpose, training data, or decision impact changes materially. Treat training data as personal information. The eight POPIA conditions — accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards, and data subject participation — all attach to your training set. Minimise the fields you ingest, mask or tokenise direct identifiers where the model does not need them, segregate special personal information, and keep a lineage record so you can answer a deletion request without retraining from scratch. If you cannot honour a Section 24 correction or Section 25 deletion request against the model, you have a compliance gap, not a technical curiosity. Govern automated decision-making explicitly. Section 71 of the POPI Act restricts decisions made solely by automated means that have legal or similarly significant effects on a data subject — credit, insurance, employment, access to services. The mitigations are familiar: a meaningful human-in-the-loop review, the right for the data subject to make representations, and a clear explanation of the logic. Build these as product requirements from day one; retrofitting them after launch is expensive and visible to the Regulator. Be precise with third-party AI providers. When you send a prompt that contains personal information to a foundation-model API, you are engaging an operator under Section 20 and, almost always, transferring personal information outside the Republic under Section 72. You need a written operator agreement, confirmation that the provider does not retain or train on your data unless you have authorised it, and a documented Section 72 ground for the cross-border flow — usually a binding agreement that imposes substantially similar protection to POPIA, or explicit data-subject consent. "We use a model hosted offshore" is not, on its own, a compliant answer. Get the security baseline right. Section 19 requires appropriate, reasonable technical and organisational measures. For AI workloads that means encryption in transit and at rest, role-based access to prompts and outputs (prompts are personal information), audit logging on inference endpoints, secrets management for API keys, rate limiting and abuse monitoring on public-facing assistants, and a tested incident-response runbook. Section 22 obliges you to notify the Information Regulator and affected data subjects of a security compromise as soon as reasonably possible — define what triggers that for an AI breach (leaked prompts, model extraction, training-data exposure) before it happens. Update the privacy notice and consent flows. Data subjects must be told that AI is involved, what categories of personal information feed it, the purpose, the recipients (including offshore model providers), the retention period, and their rights under Sections 23 to 25. If you rely on consent, the consent must be specific to AI processing — a generic "we may use your data to improve our services" is not specific enough for training a model. Operationalise data-subject rights. Build a single intake channel for access, correction, deletion, and objection requests; map each request type to the underlying datasets, vector stores, fine-tuned weights, and prompt logs; and commit to a response SLA inside the 30-day window the Regulator considers reasonable. For RAG systems, remember that your vector index is a copy of personal information — deletion requests have to reach it. Appoint and register your Information Officer. Every responsible party has an Information Officer by operation of law (the CEO or head of the entity), and registration with the Information Regulator is mandatory. For AI initiatives, give the Information Officer a named deputy with technical depth — usually the head of data or engineering — and a standing seat in the AI governance forum that signs off new use cases. Karisani delivers POPIA-aligned AI engagements end-to-end: PIIAs, ROPA build-out, operator agreements with model providers, Section 71 controls, and Information Officer enablement. Our methodology is grounded in the IIBA BABOK Guide and aligned to the Information Regulator's published guidance, so the artefacts you produce stand up to scrutiny. If you are scoping an AI initiative and want a compliance partner who speaks both Section 11 and PyTorch, get in touch.
This is a representative article. The full piece will be published once the editorial team has signed it off.