NexBDM Blog
AI and POPIA: what the Act actually requires the moment a model touches personal data
By NexBDM Team · 2026-09-13
Key takeaways
- There is no AI law in South Africa; the draft policy was withdrawn in April 2026. POPIA applies the moment a model reads a record: the eight conditions, section 11 lawful basis, the operator contract, section 72 offshore, section 71 automated decisions.
There is no AI law in South Africa; the draft policy was withdrawn in April 2026. POPIA applies the moment a model reads a record: the eight conditions, section 11 lawful basis, the operator contract, section 72 offshore, section 71 automated decisions.
AI and POPIA meet the moment a model reads a name, an email or a record. There is no AI law in South Africa; the draft policy was withdrawn in April 2026. POPIA applies now: a lawful basis under section 11, a stated purpose, a written operator contract, section 72 for offshore processing, and section 71 for any automated decision.
Most of what is written about AI and POPIA is either a summary of the eight conditions with the word "AI" added, or a vendor page that says the tool is "POPIA compliant" as though compliance were a property of software. Neither helps an owner who has just pasted a customer's complaint into a chatbot, or connected an invoicing tool to a model, and wants to know what changed legally when they did.
This post reads the answer from the Act itself. Every section quoted below was read from the Government Gazette text of the Protection of Personal Information Act 4 of 2013 on 13 September 2026. The news about the national AI policy is from Reuters, TechCentral and Daily Maverick, read the same day. Where the Act is silent, the post says so rather than guessing.
Is there an AI law in South Africa?
No, and there will not be one for a while. The Department of Communications and Digital Technologies published a draft National AI Policy in the Government Gazette on 10 April 2026 for public comment. It was withdrawn within two weeks of its release, over the Freedom Day weekend in late April 2026, after News24 reported that references in its bibliography did not exist. TechCentral reported on 12 May 2026 that at least six of the 67 entries in the reference list came from journals that did not exist, or were attributed to journals that never published the work cited. The Minister described the failure as a "massive oversight" and appointed a seven-member panel to rebuild the draft. According to the department's acting deputy director-general, as reported by Reuters on 26 May 2026, the revised policy is expected to go to Cabinet by November 2026, with a target of January 2027 for republication for public comment.
A policy is not a law in any case. Even the withdrawn draft would have set direction rather than obligations. What binds a business today is the Act that already governs the processing of personal information, whatever does the processing. We covered the wider picture in AI regulation in South Africa; this post goes narrower and deeper, into what POPIA requires the moment a model touches personal data.
When does POPIA apply to an AI tool?
From the first record. POPIA regulates "processing", and the Act's definition is wide on purpose. Processing means any operation or activity or any set of operations, "whether or not by automatic means", concerning personal information, and the list includes collection, storage, "consultation or use", and "merging, linking". Sending a customer's email to a model to draft a reply is consultation and use. Feeding a year of invoices into a tool that summarises them is processing every name on every invoice. There is no AI exemption and no threshold of volume.
Personal information is equally wide. The definition covers information relating to an identifiable, living, natural person and, where applicable, an identifiable, existing juristic person. It expressly includes employment history, financial history, any identifying number, email address, telephone number, and "the personal opinions, views or preferences of the person". A spreadsheet of customers, a WhatsApp export, a folder of CVs: all of it qualifies, and the model does not need to be told a name for the Act to apply, because an email address or an account number is enough.
Who is responsible when a vendor's model does the work: you or the vendor?
You are. The Act splits the world into responsible parties and operators. The responsible party is the body which "determines the purpose of and means for processing personal information". An operator is a person who "processes personal information for a responsible party in terms of a contract or mandate, without coming under the direct authority of that party". When you send client records to a model provider, you decided the purpose and you chose the means. The provider is your operator. Section 8 places the duty of ensuring all eight conditions are met on the responsible party, not the operator.
Three sections turn that into work you must actually do:
- Section 20: an operator may process the information "only with the knowledge or authorisation of the responsible party" and must treat it as confidential. Your instruction to the vendor defines what they may do.
- Section 21(1): you must, "in terms of a written contract between the responsible party and the operator", ensure the operator establishes and maintains the section 19 security measures. Clicking accept on a consumer plan is a contract, but read what it says about retention and training before you rely on it.
- Section 21(2) and section 22: the operator must notify you "immediately" on reasonable grounds of a compromise, and you must then notify the Regulator and the data subjects. A breach on the vendor's side is your notification duty.
The eight conditions, read against a model
POPIA's eight conditions for lawful processing are written for any processing. Here is what each one demands when the processor is a model.
| Condition | Sections | What it means once a model is in the loop |
|---|---|---|
| 1. Accountability | 8 | You, as responsible party, must ensure all the conditions are met. The vendor's compliance page does not discharge this. |
| 2. Processing limitation | 9, 10, 11, 12 | Lawful and reasonable (9). Adequate, relevant and not excessive (10): do not send the whole file when the task needs three fields. A lawful basis under 11(1). Collected directly from the data subject unless an exception in 12(2) applies. |
| 3. Purpose specification | 13, 14 | A "specific, explicitly defined and lawful purpose" (13). Records kept no longer than necessary for that purpose (14). A vendor retaining prompts for its own purposes is a retention question you must answer. |
| 4. Further processing limitation | 15 | Using data collected to serve a client in order to train or improve a model is further processing. It must be "in accordance or compatible with the purpose for which it was collected". |
| 5. Information quality | 16 | Information must be "complete, accurate, not misleading and updated where necessary". A model's output written back into a customer record is now information about that person, and section 16 applies to it. |
| 6. Openness | 17, 18 | Maintain documentation of processing operations (17). Tell the data subject what is collected, why, and, under 18(1)(g), whether it will be transferred to a third country and the level of protection there. |
| 7. Security safeguards | 19, 20, 21, 22 | Identify foreseeable risks, maintain safeguards, verify them regularly, update them (19(2)). A written operator contract (21). Breach notification (22). |
| 8. Data subject participation | 23, 24, 25 | Access and correction rights extend to whatever the model produced and you stored about the person. |
Which lawful basis covers sending client data to a model?
Section 11(1) lists six, and only one has to apply. Personal information may only be processed if the data subject consents (a); processing is necessary for the conclusion or performance of a contract to which the data subject is party (b); it complies with an obligation imposed by law (c); it protects a legitimate interest of the data subject (d); it is necessary for a public law duty (e); or it is necessary for pursuing the legitimate interests of the responsible party or of a third party (f).
For most day-to-day use in a small business the honest answer is (b) or (f), not consent. Drafting a reply to a client's query using a model is part of performing the contract with that client. Summarising your own sales pipeline is a legitimate interest of the business. Consent is the weakest basis to build on for a routine operation, because section 11(2)(b) lets the data subject withdraw it at any time, and section 11(2)(a) puts the burden of proving it on you.
Where consent does become the right basis is when the purpose changes. Training a model on your customers' correspondence so that it writes better replies to other customers is not performing their contract, and section 15 asks whether it is compatible with the reason you collected it. If you cannot answer yes with a straight face, you need a different basis, and often that is consent or nothing.
What does section 72 mean for a model hosted overseas?
Nearly every large model API is hosted outside South Africa, so section 72 applies to most AI use, not to the exotic cases. Section 72(1) says a responsible party may not transfer personal information about a data subject to a third party in a foreign country unless one of five conditions holds. The first two matter most in practice:
- 72(1)(a): the recipient is subject to a law, binding corporate rules or a binding agreement that provides an adequate level of protection, upholding principles substantially similar to POPIA's conditions and including similar restrictions on onward transfer.
- 72(1)(b): the data subject consents to the transfer.
The practical reading is this. A vendor's data processing terms that commit to security, confidentiality, purpose limitation and restrictions on onward transfer are the "binding agreement" route. Read them for those words. If the terms allow the vendor to use your inputs to train its models, that is an onward use you did not choose, and the agreement route gets harder to argue. Section 18(1)(g) then requires that you tell the data subject the information is going to a third country and what protection it has there. A privacy notice that does not mention offshore processing is out of date the day a model is connected.
Section 71: the one clause written for exactly this
POPIA was passed in 2013, and it already contains a provision for automated decisions. Section 71(1) says a data subject may not be subject to a decision "which results in legal consequences for him, her or it, or which affects him, her or it to a substantial degree", where that decision is based "solely on the basis of the automated processing of personal information intended to provide a profile of such person". The profile examples the Act lists are performance at work, creditworthiness, reliability, location, health, personal preferences and conduct.
The exceptions in 71(2) are narrow: the decision is taken in connection with a contract and the data subject's request has been met, or "appropriate measures have been taken to protect the data subject's legitimate interests", or the decision is governed by a law or code of conduct that specifies such measures. Section 71(3) defines appropriate measures as two things: an opportunity for the data subject to make representations about the decision, and enough information "about the underlying logic of the automated processing" to make those representations.
Applied to a business: a model that drafts, sorts, flags, summarises or recommends is not making a decision under section 71, because a person still decides. A model that declines a credit application, rejects a job applicant, cancels a service or sets a price for one customer, with no human step, is. We read section 71 against hiring in AI recruitment: screening CVs without screening people out and against customer service in what to hand to a bot and what must stay human. The rule is the same in every case: keep the decision human, and be able to explain the logic to the person it affects.
How does this get done without a compliance project?
Everything above can be handled once, as structure, rather than every time, as judgement. Here is the mechanism we set up when a business connects a model to its records.
- One privacy notice, written once, reused everywhere. The section 18 notice lives as one template that already names the purpose, the fact of offshore processing and the protection there, and the retention period. Every form, registration page and onboarding email pulls the same text, so the notice is never rewritten and never drifts.
- The lawful basis is a field, not a memory. Each category of record carries its section 11 basis (contract, legitimate interest, consent) as a field on the record type. When someone asks why a model saw a client's email, the answer is on the record, not in someone's head.
- Minimality is enforced by the integration, not the user. The automation sends the model only the fields the task needs. A reply-drafting step gets the message body and the client's first name; it never gets the account balance, the ID number or the full history. Section 10 is met by design because the whole file is not available to send.
- Retention is a date on the record. The section 14 period is set per record type and the system deletes or archives when it passes. Prompt logs at the vendor are covered by the operator contract, which is stored against the vendor as a document with its own review date.
- Section 71 is a workflow step. Wherever a model's output could end in a decision that affects someone, the workflow routes to a person before anything sends. The model's reasoning is captured alongside the recommendation, so the "underlying logic" is already written down if the person asks for it.
- The vendor register replaces the annual scramble. Every operator is one record: contract, retention terms, training terms, section 72 route, breach contact. When a vendor changes its terms, one record is updated and the section 17 documentation is current.
None of this needs a lawyer in the room every week. It needs the questions answered once and stored where the work happens. Our AI vendor checklist has the questions to put to an operator, and the workplace AI policy template covers what staff may and may not paste into a model. For the Act's baseline duties, Information Officer registration and breach reporting, start with the POPIA compliance checklist.
Frequently Asked Questions
Does POPIA apply if I only use a free AI chatbot?
Yes. The Act regulates processing "whether or not by automatic means", and pasting a client's details into any tool is consultation and use. The free plan matters for a different reason: its terms usually allow the provider to retain and train on your inputs, which affects sections 14, 15 and 72.
Is the AI vendor the responsible party for my data?
No. You determine the purpose and means, so you are the responsible party and the vendor is your operator. Section 21 requires a written contract that binds the operator to section 19 security measures, and section 22 makes a breach on their side your duty to report.
Do I need consent to use AI on customer data?
Not usually. Section 11(1) offers six bases and consent is only one. Processing necessary to perform a contract with the customer, or a legitimate interest of the business, covers most routine use. Consent becomes necessary when the purpose changes, such as training a model on their data.
Is sending data to an overseas AI model a transborder transfer?
Yes, if the provider is in a foreign country. Section 72 permits it where the recipient is bound by a law or binding agreement giving adequate protection, or the data subject consents. Section 18(1)(g) requires that you tell the data subject the transfer is happening.
What is the AI policy withdrawal and does it change anything?
The draft National AI Policy gazetted on 10 April 2026 was withdrawn within two weeks, in late April 2026, after fabricated references were found in it. A panel is redrafting it with a January 2027 target for public comment. It was a policy, not a law, so nothing about your POPIA duties changed.
The short version
There is no AI Act to wait for. POPIA already covers every model that reads a record, and it asks six things of you: a lawful basis, a stated purpose, minimal data, a written operator contract, a section 72 route for offshore processing, and a human decision wherever the outcome affects a person. Answer each once, store the answer on the record, and the compliance work becomes structure instead of vigilance. If you want to see where personal data currently flows in your business, which tools it reaches, and which of those questions have no answer yet, that is what a Business Autopsy is for, and a discovery call is where it starts.
Sources, all read directly on 13 September 2026: Protection of Personal Information Act 4 of 2013, Government Gazette No. 37067, 26 November 2013: section 1 definitions of "processing", "personal information", "responsible party" and "operator", and sections 8 to 22, 71 and 72. Reuters as carried by Polity, "South Africa targets January 2027 for revised AI policy after earlier withdrawal", 26 May 2026. TechCentral, "Malatsi moves to rescue South Africa's botched AI policy", 12 May 2026. Daily Maverick, "Malatsi withdraws draft AI policy after hallucination revelations", 27 April 2026. No vendor marketing material is used, and no figure in this post is ours.