TL;DR

  • POPIA Section 71 restricts decisions based solely on automated processing when they carry legal or substantially significant consequences for a policyholder or claimant.
  • Most insurance underwriting and claims decisions can still run through automation, but only when two specific safeguards are in place: a chance for the person to respond, and an explanation of the logic behind the decision.
  • Those two safeguards are what an AI audit trail exists to prove, for one specific decision, not for the model in general.
  • The Information Regulator enforces POPIA and can act on a complaint even without a data breach, if an insurer cannot produce that evidence for a specific decision.
  • This piece covers Section 71 and audit trail requirements. It does not cover FSCA or Prudential Authority governance expectations, a separate regulatory track covered elsewhere.

South African insurers running AI-driven underwriting or claims decisions carry more than a model risk question. They carry a specific legal restriction under the Protection of Personal Information Act, one that applies the moment a decision affecting a policyholder or claimant runs solely on automated processing. Meeting it does not mean avoiding automation. It means being able to prove, for any single decision, that two specific safeguards were in place when it was made, and that proof has to be ready before a regulator or a policyholder asks for it, not assembled afterward under pressure.

What Section 71 restricts

Section 71(1) states that a data subject may not be subject to a decision that results in legal consequences, or affects them to a substantial degree, based solely on automated processing of their personal information. For an insurer, that covers a claim denial, a premium loading, or a coverage decline generated by a model without a person reviewing it. The restriction reaches any decision meeting that bar, whether the model runs underwriting, claims triage, or fraud flagging, so it is worth checking each use case against this test individually rather than assuming a single blanket answer covers every model an insurer runs.

The restriction has real exceptions. Section 71(2) permits automated decisions connected to entering or performing a contract, which covers a large share of ordinary underwriting and claims work, provided the insurer has appropriate measures in place to protect the person’s legitimate interests. That exception is where most insurance automation legally sits, and it is a conditional exception rather than a blanket permission. The condition it carries is the subject of the next section.

The two safeguards the Act requires

POPIA Section 71 safeguards for automated decision-making, highlighting an individual’s right to make representations about a decision and receive sufficient information to understand the underlying logic.


Section 71(3) sets out what those appropriate measures have to include. Two requirements carry the weight, and both apply to the specific decision affecting one person, not to a general statement about how the insurer uses AI.

A chance to respond. The person affected must have an opportunity to make representations about the decision, to contest it or add context before it becomes final or shortly after.

The logic explained. The insurer must provide the person with sufficient information about the underlying logic of the automated processing, enough for them to understand and meaningfully respond to why the decision came out the way it did.

Both requirements are about one specific decision affecting one specific person, not a general disclosure about how the model works across the whole book of business. A privacy policy describing AI use in the abstract does not satisfy either safeguard on its own.

What an audit trail has to capture for one decision

Meeting Section 71(3) in practice means an insurer’s systems have to produce, for any single claim or underwriting decision, evidence of both safeguards on request.

For the representations safeguard, that means a record that the channel to respond existed and when it was offered, tied to that specific decision and that specific person, not a general complaints process buried in a policy document.

For the logic safeguard, that means an explanation generated close to the point of decision, in language the policyholder or claimant can understand, tied to the specific model version that produced it. A model retrained since the decision was made cannot reliably reconstruct what drove an earlier one.

An insurer that can produce both records on demand, for any decision, has met what Section 71(3) asks for. One that can only describe its process in general terms has not, regardless of how much technical documentation sits behind the scenes. The gap between the two is rarely a gap in intent. It is a gap in whether the system was built to generate and store this evidence automatically, at the moment of the decision, rather than reconstruct it later from logs that were never designed for the purpose.

Who enforces this, and what a missing audit trail exposes

POPIA is enforced by the Information Regulator, a body separate from FSCA and the Prudential Authority. A complaint does not require a data breach. A policyholder who believes an automated decision affected them without the safeguards Section 71(3) requires can complain directly, and the burden then falls on the insurer to produce the record proving those safeguards existed for that decision.

An insurer without a system that generates and stores this evidence automatically is left trying to reconstruct it after a complaint arrives, often for a decision made months earlier, against a model that may have since changed.

Where this sits next to FSCA and Prudential Authority expectations

POPIA and the FSCA/Prudential Authority governance expectations are separate instruments enforced by separate regulators, and one does not substitute for the other. The joint FSCA/Prudential Authority report on AI in the financial sector points toward board oversight, a model risk structure, and explainability methods such as SHAP and LIME. POPIA’s Section 71 is a specific, narrower legal restriction on automated decisions affecting an individual, sitting inside that broader governance picture rather than replacing it.

An insurer building toward the governance readiness described elsewhere has the natural infrastructure this audit trail depends on already in place: a model inventory, version tracking, and a documented explanation method. One built for POPIA alone, without that broader structure, will find the account-level record harder to produce consistently across every model in use.

What this looks like running in production

A leading NBFC in India built exactly this kind of per-decision record into its collections platform, generating a logged explanation alongside every automated contact decision, tied to the model version that produced it. The result was a 116% increase in its collections recovery rate, with 86% predictive accuracy, deployed in two weeks. The regulator in that case was the RBI rather than South Africa’s Information Regulator, but the underlying requirement, proof for one specific decision rather than a description of the model in general, is the same one Section 71 asks South African insurers to meet.

Book a working session with iTuring to see how account-level audit trails satisfy both Section 71 safeguards for every automated decision.

Sources

  1. Protection of Personal Information Act, 2013, Section 71 (Automated decision making), quoted directly. https://popia.co.za/section-71-automated-decision-making/
  2. FSCA and Prudential Authority, “Artificial Intelligence in the South African Financial Sector,” 24 November 2025, for the governance-expectations cross-reference.
  3. iTuring case study, “Improve Collections and Optimize Efforts” (Leading NBFC in India): 116% collections improvement, 86% predictive accuracy, two-week deployment.