South African businesses are adopting AI tools fast, often faster than their POPIA compliance has caught up. If you're uploading client documents, contracts, medical records, or financial files into any AI tool, a few real legal questions apply, whether or not the tool markets itself as "private."

Who's actually responsible

Under POPIA, there are three roles at play:

DATA SUBJECT The person the information is about: your client, patient, or customer.
RESPONSIBLE PARTY Your business. Equivalent to a "controller" under GDPR. Decides why and how data is processed.
OPERATOR A vendor processing data on your behalf. Equivalent to a "processor" under GDPR. This is where an AI tool typically sits.

Here's the part that surprises people: using an AI vendor doesn't transfer your accountability to that vendor. Your business remains the responsible party under POPIA even when a foreign AI tool is doing the actual processing. If something goes wrong, the Information Regulator's inquiry starts with you, not your software.

The cross-border transfer question

Most AI tools, including Private which runs on Google Cloud infrastructure, process data outside South Africa. Under Section 72 of POPIA, a responsible party may not transfer personal information to a third party in a foreign country unless one of a few specific grounds applies: adequate legal protection at the destination, the data subject's consent, or necessity for performing a contract.

Worth knowing

Unlike the EU's GDPR, South Africa has no published list of "adequate" countries. There's no shortcut here. The burden falls on your business to document that a vendor's protections are substantially similar to POPIA's, typically through a written agreement.

What this means practically, for any AI vendor you use

Whether or not a tool calls itself "private," using it lawfully under POPIA generally requires:

  1. A written operator agreement. Section 21 requires a contract obliging the vendor to maintain security safeguards and notify you of any breach.
  2. A documented basis for the cross-border transfer, since there's no automatic "adequate country" shortcut.
  3. Data minimisation. Only process what's actually necessary, not everything you happen to have.
  4. Special attention to sensitive categories. Health records, ID numbers, and similarly sensitive data carry stricter requirements. Some practical guidance for South African employers recommends avoiding public AI tools for this category entirely, regardless of vendor.

Where a vendor's own practices matter, and where they don't

Some things are squarely the vendor's responsibility to get right: whether they use your data to train models (a real POPIA concern, since training on personal information can conflict with purpose limitation), how they secure it, and whether they notify you of breaches.

Other things stay yours to handle regardless of which vendor you choose: appointing an Information Officer, having a lawful basis for processing in the first place, and putting a proper operator agreement in place.

Private is built with the first category in mind. Documents are never used to train any model, and access can be revoked or deleted at any time. But that's one input to POPIA compliance, not the whole answer. A responsible party using any vendor, including Private, still needs its own compliance groundwork in place.

The practical takeaway

Don't ask "is this tool POPIA compliant" as if that's a single yes/no switch a vendor flips for you. Ask instead: does this vendor's data handling make it possible for my business to be compliant, or does it create a problem I can't solve no matter what agreement I sign? A vendor that trains on your uploads, or gives you no way to document where data goes, makes compliance harder regardless of what else it does well.

Again, this is general information and not legal advice specific to your situation. For an actual compliance determination, speak to a professional familiar with POPIA and your industry.