POPIA and AI in legal practice: what SA firms need to know in 2026

The real question partners ask us, once the boardroom conversation is over and the tea has gone cold: if I put client data into an AI system, am I still POPIA-compliant? The honest answer is “it depends” — but the dependencies are specific and knowable.

The short answer

Yes, a South African law firm can use AI in client-facing legal work and remain compliant with the Protection of Personal Information Act 4 of 2013 (POPIA) — but only if three things are in place: a written operator agreement with the vendor, appropriate security safeguards under section 19, and a clear understanding of where the data lives and whether it crosses borders under section 72. Without those, you’re almost certainly in breach before the first prompt is sent.

Most firms we speak to are either doing none of this, or doing it in a way that would not survive an Information Regulator audit. The problem is rarely bad intent. It’s that consumer AI tools were designed for individual consumers, and the obligations POPIA places on a responsible party were never part of the product design.

What POPIA actually requires of AI processing

POPIA does not mention artificial intelligence by name. It doesn’t need to. The Act is technology-neutral: wherever personal information is processed, the eight conditions in Chapter 3 apply. For AI, four sections do most of the work.

Section 19 — security safeguards

Section 19 requires “appropriate, reasonable technical and organisational measures” to protect personal information against loss, damage, unauthorised destruction, and unlawful access. When applied to AI, this means encryption in transit and at rest, access controls, audit logging, and — critically — the ability to know what happened to a piece of client data after it left your network. A tool that cannot tell you whether prompts are retained, logged, or used for model training fails this test.

Section 21 — operator agreements

If a vendor processes personal information on the firm’s behalf, they are an operator under POPIA. Section 21 requires the relationship to be governed by a written agreement that obliges the operator to process the information only on instruction, to treat it as confidential, and to apply section 19 safeguards. A consumer terms-of-service click-through does not satisfy this. The agreement has to be with the firm, not with an individual lawyer on a personal account.

Section 26 — special personal information

Legal work generates section 26 data at industrial volumes: health information in personal-injury matters, criminal-behaviour allegations in family and criminal matters, religious or philosophical beliefs in estate work, sexual life in divorces. Special personal information can only be processed under one of the narrow grounds in section 27, including with the data subject’s consent or where processing is “necessary for the establishment, exercise or defence of a right or obligation in law.” Most litigation work is covered by the latter — but the processing must still be proportionate and secure.

Section 72 — cross-border transfers

Most large language models run outside South Africa. If your prompt contains a client’s personal information and the model runs in Virginia or Dublin, you have made a cross-border transfer. Section 72 permits this only if one of five conditions is met, the most practical being that the recipient is bound by a law, binding corporate rules, or a binding agreement providing protection substantially similar to POPIA. Your operator agreement is what makes that work — or what makes its absence the problem.

The three mistakes firms are making

We have been in enough SA law firms over the past year to see the same patterns repeat.

1. Consumer ChatGPT accounts with client data

A candidate attorney in a Sandton commercial firm uses a personal ChatGPT Plus account to summarise a 40-page affidavit. The affidavit names a minor, two medical providers, and a third party who is not their client. The firm has no record that the data was processed externally, no control over whether it is retained, and no operator agreement with OpenAI covering this use. When the client asks under section 23 what happened to their information, the firm cannot answer honestly. This is the single most common pattern we see, and it is almost always invisible to the managing partner until someone asks the question.

2. No written operator agreement with the AI vendor

Firms sometimes upgrade to a business or enterprise AI subscription and assume that the “enterprise” label is a POPIA operator agreement. It is not. A Data Processing Addendum (DPA) that references GDPR Article 28 is closer, but POPIA has its own specific requirements, and a DPA drafted for EU controllers will usually need supplementation — particularly around the Information Regulator, Information Officer notification under section 22, and section 72 cross-border mechanics.

3. No disclosure to the client

POPIA’s condition of openness (sections 17 and 18) requires that a data subject be informed of the purpose of collection, the recipients of the information, and whether the supply is voluntary. If a family law firm in Johannesburg runs every incoming affidavit through an AI summariser, the client deserves to know. Almost no engagement letter we have reviewed mentions AI at all. This is fixable in one paragraph.

What good looks like

The firms we see getting this right have done work on two sides of the relationship — what they demand of vendors, and what they change internally.

On the vendor side, the non-negotiables are: a written operator agreement naming the firm; a clear statement that client data will not be used to train the vendor’s models; data-residency transparency — where the data is processed, where it is stored, and for how long; audit logs the firm can access; and a published incident-response process that meets section 22’s “as soon as reasonably possible” notification standard.

On the firm side, the work is mostly procedural. Three documents do most of it: an internal AI use policy that tells staff which tools are permitted and which are not; an updated engagement letter paragraph disclosing AI-assisted processing; and an intake form disclosure that brings the data subject’s knowledge into alignment with what will actually happen to their information. None of this is long. A good internal AI policy is two pages.

The Dis-Chem precedent — why this is not theoretical

In 2022 Dis-Chem suffered a breach that exposed roughly 3.6 million personal records through a third-party service provider. The Information Regulator issued an enforcement notice against Dis-Chem in 2023, finding it had failed to comply with sections 19 and 21 — specifically, that its operator agreement was inadequate and its security measures were not appropriate for the volume and sensitivity of the data. Dis-Chem was ordered to remediate.

No AI system was involved. The reason the case matters here is that the Regulator’s reasoning is directly transposable: a responsible party cannot outsource its POPIA obligations by selecting a service provider and hoping. The operator agreement has to exist, the safeguards have to be real, and the responsibility stays with the firm. An AI vendor is an operator. The analysis does not change.

A practical checklist

Ten items a managing partner can action this month. Most of them take a morning, not a quarter.

  1. Ban consumer-tier AI accounts (ChatGPT, Claude, Gemini on personal emails) for any work that touches client data. Put it in writing.
  2. Choose one AI vendor per use case and get a signed operator agreement. If the vendor cannot produce one, that answers the question.
  3. Confirm in the agreement that client data will not be used for model training, and that prompts are not retained beyond the minimum necessary for service delivery.
  4. Ask the vendor for a data-flow description: where the data is processed, in which jurisdictions, and for how long each component is retained.
  5. Update your engagement letter to disclose AI-assisted processing and identify the categories of tools you use.
  6. Update your intake form and client-facing privacy notice to reflect AI processing where applicable.
  7. Write a two-page internal AI use policy covering permitted tools, prohibited inputs (anonymisation requirements for sensitive matters), and the escalation path when staff are unsure.
  8. Identify your Information Officer under section 55 and make sure they have been told about the AI rollout. If the Information Officer has not been registered with the Information Regulator, register them.
  9. Create an incident-response playbook that assumes an AI-related breach is possible. It should fit on one page and name the people who act.
  10. Schedule an annual review of the above. POPIA compliance is not a project; it is a state.

A note on GDPR

For firms whose instincts default to GDPR — POPIA and GDPR are close cousins, but the Information Regulator is a South African body applying South African law. Reasoning that would be correct under GDPR is usually correct under POPIA, but the statute is not identical and the remedies are not identical. Work from the POPIA text.

Closing

We built Digiiworks Legal with these exact requirements in mind. Every firm on our platform gets a written operator agreement under section 21. Client data is processed inside a dedicated tenant, encrypted with AES-256 at rest, and never used to train any model. Cross-border transfers are disclosed and governed. You can read more in our POPIA statement and our trust and security documentation. If you’re working through the checklist above and would like to see what good looks like in practice, we’d be glad to walk you through how it’s wired.

Want to see a POPIA-aligned AI setup in practice?

We built Digiiworks Legal around the sections above — operator agreements, data residency, audit logs, no training on client data. A 20-minute walkthrough shows you the whole stack and answers the awkward questions.

POPIA and AI in legal practice: what SA firms need to know in 2026 | Digiiworks Legal — Digiiworks Legal