POPIA and AI: what to settle before you start

The Protection of Personal Information Act 4 of 2013 came into full force in July 2021. It predates ChatGPT by well over a year, and it contains no section headed “artificial intelligence”. This leads some businesses to assume it is silent on the subject.

It is not. POPIA regulates the processing of personal information, and it defines processing broadly enough that feeding records to a model is squarely covered. The obligations were already there. AI projects simply run into several of them at once.

First: is personal information involved at all?

Section 1 defines personal information as information relating to an identifiable living natural person and, notably, to an identifiable existing juristic person. That second part catches South African businesses out regularly: information about your corporate customers is personal information under POPIA, which is not the case under the GDPR.

So a system that scores supplier reliability, or drafts responses to business customers, is processing personal information even though no individual is the subject.

Section 26 defines a narrower category of special personal information: religious or philosophical beliefs, race or ethnic origin, trade union membership, political persuasion, health or sex life, biometric information, and criminal behaviour. Processing these is prohibited unless a specific exemption in section 27 applies. If your data contains health records or biometrics, the bar is considerably higher and you should take advice before proceeding rather than after.

Purpose limitation, and the trap it sets

Section 13 requires that personal information be collected for a specific, explicitly defined and lawful purpose. Section 15 then governs further processing: using information for a purpose other than the one it was collected for.

Section 15(1) allows further processing only where it is compatible with the original purpose. Section 15(3) lists circumstances where it is treated as compatible, including where the data subject has consented, or where it is necessary to prevent a serious threat, or where it is used for historical, statistical or research purposes with appropriate safeguards and without publishing identifiable results.

This is where most AI projects meet POPIA first. You collected customer contact details and order history to fulfil orders. You now want to use them to train or prompt a system that predicts churn or scores creditworthiness. That is a different purpose. It may well be compatible, but that is a determination somebody has to make and record, not an assumption to carry forward.

The question this becomes

For the specific dataset you intend to use: what purpose was it collected for, is that purpose written down anywhere, and has anyone assessed whether this new use is compatible with it? “We assume it is fine” is the answer we see most often, and it is the answer worth acting on.

Cross-border transfer

Section 72 restricts transferring personal information outside South Africa. It permits transfer where, among other grounds, the recipient is subject to a law, binding corporate rules or a binding agreement that provides an adequate level of protection and includes principles for lawful processing substantially similar to POPIA, or where the data subject consents, or where the transfer is necessary for the performance of a contract with the data subject.

Almost every commercially available AI model runs outside South Africa. OpenAI, OpenAI, Google and Microsoft all process in the United States or Europe by default. If you send personal information to any of them, you are making a section 72 transfer.

In practice this usually means relying on the contractual protections in the provider’s enterprise or commercial terms, and being able to show you considered the question. It is very unlikely to be a blocker. It is quite likely to be something nobody documented.

Automated decision-making

Section 71 is the section most directly about AI, and the one most often missed.

It provides that a data subject may not be subject to a decision which results in legal consequences for them, or which affects them to a substantial degree, where that decision is based solely on the automated processing of personal information intended to provide a profile of them, including their performance at work, creditworthiness, reliability, location, health, personal preferences or conduct.

There are exceptions in section 71(2), broadly where the decision is taken in connection with concluding or performing a contract and the data subject’s request has been met, or appropriate measures protect their legitimate interests, or where the decision is governed by a law or code of conduct with suitable safeguards. Section 71(3) requires that those appropriate measures include an opportunity to make representations and that the data subject be given sufficient information about the underlying logic.

What this means practically

The operative word is solely. A system that recommends and a person who decides is a materially different arrangement from a system that decides. This is the single strongest argument for designing your first AI project as an assistive tool with a human reviewer, quite apart from the fact that it is also how you find out whether the thing works.

If you are screening job applicants, scoring credit, or deciding claims, section 71 is directly in scope and the design of the human review step is not a detail.

Security safeguards and operators

Section 19 requires appropriate, reasonable technical and organisational measures to secure the integrity and confidentiality of personal information. Section 21 governs your relationship with an operator: a third party who processes on your behalf.

Any AI vendor processing your data is an operator. Section 21(1) requires that they process only with your knowledge or authorisation and treat the information as confidential. Section 21(2) requires a written contract obliging them to establish and maintain the security measures in section 19.

So: a written agreement with each AI vendor handling personal information, covering security and restricting use to your instruction. Most enterprise terms already contain this. The gap is usually that nobody has checked, or that someone is using a consumer subscription for work data.

Section 22 then requires notification to the Information Regulator and to affected data subjects where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person.

The Information Officer

Sections 55 and 56 provide that the head of a private body is the Information Officer by default, and may designate deputies. Registration with the Information Regulator is required.

In practice, in a smaller South African business this is the owner or a director wearing an additional hat. That is entirely acceptable. What is not acceptable is that nobody knows who it is, which is a common answer and a meaningful finding in its own right.

Before an AI project, confirm three things: who the Information Officer is, whether they are registered, and whether they know the project is happening.

A practical sequence

• Identify what personal information the project touches, including information about juristic persons, and whether any of it is special personal information under section 26.
• Establish the purpose it was collected for, and assess under section 15 whether this use is compatible. Write the assessment down.
• Identify where processing will physically happen and address section 72 if it leaves South Africa.
• Check the vendor agreement satisfies section 21, and that access controls satisfy section 19.
• Design the human review step deliberately, with section 71 in mind, if the output affects anyone materially.
• Tell your Information Officer, and record the decision so that in eighteen months somebody can reconstruct why you concluded it was lawful.

What nobody can tell you from a questionnaire

No self-assessment, including ours, can determine whether you comply with POPIA. Compliance depends on facts about your systems, your contracts and your practice that a questionnaire cannot verify. Any tool that issues you a compliance verdict from a set of answers is selling something it cannot deliver.

What an assessment can usefully do is surface the questions above as possible gaps requiring verification, so you arrive at a conversation with your attorney with a specific list rather than a general worry. That is a genuinely useful thing, and it is all it is.

Related: the readiness checklist and how we handle your data.