All writing

No AI Act yet, but POPIA, PCI DSS and the Joint Standards already govern your GenAI

South Africa's AI policy stalled, the rules did not. Five controls from POPIA, the Joint Standards and PCI DSS that already apply to GenAI in a regulated firm.

On this page

  1. POPIA treats your AI vendor as an operator
  2. The Joint Standards put inventory, logs and MFA on your AI tools
  3. PCI DSS scopes in anything that touches card data
  4. Five controls that satisfy all three
  5. Where this stops being clear
  6. What to do on Monday

0 of 6 sections read

In April 2026 the Department of Communications and Digital Technologies gazetted a draft national AI policy, then withdrew it within weeks after reporters found that some of its references did not exist. The minister’s own explanation was that AI-generated citations went in without verification. It’s a fair joke on the department, and a fair warning about GenAI in general.

It also tempts a risky conclusion: with no AI Act on the horizon, there’s nothing to comply with yet. If you run a regulated business in South Africa, that’s wrong. The rules that matter were already in force before anyone pasted a client file into a chatbot. This post walks through three of them, POPIA, the Joint Standards and PCI DSS, and the controls in each that bite hardest on GenAI.

POPIA treats your AI vendor as an operator

POPIA doesn’t mention AI, and it doesn’t need to. When staff paste personal information into a prompt, you’re processing it, and the vendor behind the prompt is your operator.

  • Section 21 requires a written contract with an operator that makes it keep the information confidential and secure. A consumer chatbot account with default terms is not that contract.
  • Section 19 requires reasonable technical and organisational safeguards. Deciding which tools may see which data is a safeguard; leaving it to each employee’s judgement isn’t.
  • Section 72 restricts sending personal information outside South Africa unless the recipient is bound by adequate protection. Most AI vendors process abroad, so this applies from the first prompt.
  • Section 22 requires notification when personal information is accessed by an unauthorised person. A prompt history that leaks is a breach like any other.
  • Section 71 limits decisions with legal or similarly substantial effect on a person that rest solely on automated processing. A model that scores, ranks or rejects people, with a human clicking through, is the case it was written for.

A person who approves whatever the model says without understanding why is a rubber stamp, not oversight. If a decision affects a customer or an employee, someone with authority has to be able to disagree with the model, and to have the logic in front of them when they do.

The Joint Standards put inventory, logs and MFA on your AI tools

If you’re a financial institution under the FSCA and the Prudential Authority, Joint Standard 1 and Joint Standard 2 already sit on top of POPIA. They don’t name AI either.

  • JS1 clause 10.2(e) says all personal information must be processed in line with applicable legislation, POPIA by name. The regulator has tied the two together for you.
  • JS1 clause 10.1 requires measures that protect sensitive information (a) and protect information assets “in accordance with its sensitivity classification” (b). If nobody has classified what goes into a prompt, you can’t show you did that.
  • JS2 clause 7.1.1 requires you to identify information assets, “including those managed by third-party service providers” (7.1.1(a)), and to keep an inventory with location and ownership (7.1.1(d)), reviewed at least biennially (7.1.2). Every AI tool your staff use is an asset you must be able to list. The unofficial ones count too.
  • JS2 clause 7.3.2(a) asks for logs collected, reviewed and retained, and protected from editing and deletion. Prompts and agent actions are events.
  • JS2 clause 8.3.1(c) requires MFA on every account used to reach an application containing sensitive information over the internet. An AI assistant connected to your mailbox or CRM is exactly that.
  • JS2 clause 9.1 requires you to notify the authority of a material cyber incident or information security compromise. A data leak through an AI tool qualifies.

PCI DSS scopes in anything that touches card data

PCI DSS is the least forgiving of the three because it’s a contract, not a statute, and assessors check it against evidence. Under version 4.0.1, GenAI creates trouble in four places.

  • Requirement 3.5.1 says the primary account number must be unreadable wherever it’s stored. A chat history, a log or a vector database is storage. A card number pasted into a prompt is now stored somewhere you may not control, and that system is in scope.
  • Requirement 12.8 governs third-party service providers: keep a list (12.8.1), hold written agreements in which they acknowledge responsibility for the data they touch (12.8.2), and monitor their compliance status at least yearly (12.8.4). An AI vendor that can see cardholder data belongs on that list.
  • Requirement 7.2 demands least privilege, and 7.2.5 extends it to application and system accounts. An agent that runs under a service account is one. Give it read access to the one table it needs, not the database.
  • Requirement 6.2.3 requires bespoke code to be reviewed before release. Code a model wrote is still bespoke code, and “the AI wrote it” is not a review.

Requirement 12.5.2 asks you to confirm your scope every year. Add a question to that exercise: where can card data reach a model?

Five controls that satisfy all three

The clauses differ, but the same few controls answer them.

Control POPIA Joint Standards PCI DSS 4.0.1
A live inventory of AI tools and what data they may see s21 JS2 7.1.1, 7.1.2 12.5.2, 12.8.1
Vendor terms that cover confidentiality, retention and no training on your data s21, s72 JS2 4.2.3, 7.2.3(a) 12.8.2
Sensitive data kept out of prompts by default s19 JS1 10.1 3.5.1
Logs of AI activity you can search and can’t edit s19, s22 JS2 7.3.2(a) 10.2
Least privilege and MFA for every AI account, agent accounts included s19 JS2 8.3.1 7.2.5, 8.4.2

Proportionality matters. A five-person FSP won’t run a security operations centre to watch its AI tools. It can, however, keep a one-page inventory, pick vendors on paid business terms and switch on the audit log its tools already offer.

None of these is new, and that’s the point. I ran POPIA and PCI DSS compliance for a national retail group, and the controls I’d have asked for there are the same ones. The tool changed; the control objective didn’t.

Where this stops being clear

Two limits on what I’ve said.

I haven’t tested any of this against an assessor or the Information Regulator, and no regulator has yet published guidance that ties these clauses to GenAI specifically. The mapping above is my reading, not theirs.

Whether a given AI vendor counts as a “third-party service provider” under the Joint Standards is a judgement call, and I’d read it broadly. If the tool sees your client data, treat it as one.

What to do on Monday

Ask every team which AI tools they use, including the free ones on personal accounts, and write the answers in a table with three columns: tool, data it sees, who owns it. Then mark every row that touches personal information or card data. Those rows are where POPIA, the Joint Standards and PCI DSS all apply, whatever happens to the AI policy.

Topic
Type