The message arrived on Amanzi Credit's WhatsApp channel on a Tuesday morning: "What information do you have about me? Your agent said the system made notes about my call. I want to see them."
It took Amanzi 23 days to reply. The response included the customer's account details, transaction history and contact information from the core loan system. It did not include the AI-generated call summaries the customer had specifically asked about, the propensity scores in the data warehouse, the chunks of call notes in the AI search index, or the copies held by the collections agency. Nobody had left them out on purpose. Nobody had known where to look.
An access request is often handled as an administrative task: a form arrives, someone in the compliance team collects documents, a letter goes out. In a modern estate it is something else. An access request is an end-to-end test of whether your organisation knows where personal information about one person lives, including the information your systems generated about them. CloudNala's view is that it should be designed as a system capability, tested before a customer tests it for you.
This series is general information about running privacy controls in production systems, not legal advice. It summarises the Protection of Personal Information Act for a technical and business audience; read the primary text and take advice from your information officer and a qualified legal practitioner before relying on any interpretation.
This is Part 4 of POPIA in Production. Part 3 built a pipeline that finds every copy of a record in order to delete it. This part reuses most of that machinery to find every copy in order to disclose or correct it.
Amanzi Credit is fictional, and its systems and figures are illustrative. It is a Gqeberha lender with about 180,000 customers, a WhatsApp service channel, a call centre, an AI call-note summariser, a data warehouse, an AI search tool over call notes and three outsourced operators.
What the Act gives the data subject
Section 23(1) gives a data subject who has provided adequate proof of identity the right to ask a responsible party to confirm, free of charge, whether it holds personal information about them, and to request the record or a description of it, "including information about the identity of all third parties, or categories of third parties, who have, or have had, access to the information". That must be provided within a reasonable time, at a prescribed fee if any, in a reasonable manner and format, and "in a form that is generally understandable".
Section 23(2) requires the responsible party to tell the person about their right to request correction. Section 23(3) requires a written fee estimate before any fee-bearing work. Section 23(4) applies the grounds for refusing access in the Promotion of Access to Information Act, and section 25 applies that Act's sections 18 and 53 to the manner of making requests.
Section 24 then gives the data subject the right to request correction or deletion of information that is "inaccurate, irrelevant, excessive, out of date, incomplete, misleading or obtained unlawfully", and deletion of records the responsible party is no longer authorised to keep. Where a correction affects decisions that have been or will be taken about the person, section 24(3) requires the responsible party, where reasonably practicable, to inform each person or body to whom the information was disclosed.
The channels have also widened. The amendments to the POPIA Regulations published as Government Notice 6126 in Government Gazette 52523 of 17 April 2025 substituted regulations 2 and 3. In the amended text the Information Regulator publishes (checked on 31 October 2026), objections and requests for correction or deletion are free of charge and may be submitted "by hand, fax, post, email, SMS, WhatsApp message or in any manner expedient to a data subject", telephonic requests must be recorded, and regulation 3.6 requires the responsible party to notify the data subject in writing of the action taken within 30 days "of receipt of the outcome of the request". Commentators read that start point differently, so ask your information officer and legal advisers how your organisation counts it. These channel rules cover objections and corrections; access requests themselves follow section 25 and the Promotion of Access to Information Act. The engineering consequence is the same either way: requests arrive wherever customers already talk to you, and your process has to start there.
Six steps across the whole estate
Amanzi rebuilt its handling as six steps, each owned and logged.
1. Receive on any channel, and log it. A request on WhatsApp, in a call, by email or at a branch creates the same case record with a received date. Call-centre and chat agents have one action, "this is a privacy request", that opens the case. Recognising the request is the step most likely to fail silently.
2. Verify identity in proportion. The Act requires adequate proof of identity. Amanzi matches the requester against details it already holds and uses the channel's existing authentication, stepping up only for higher-risk disclosures. It does not collect new copies of identity documents when existing verification is sufficient, and it never sends personal information to a number or address it cannot link to the customer.
3. Find the person in every system. This is where the original request failed, and it needs its own capability.
4. Compile, including derived data. Everything found, in a generally understandable form.
5. Apply refusal grounds, if any. Usually this means redacting information about other people, not refusing.
6. Respond and offer correction. With the section 24 right explained and a route to use it.
The person index
Step 3 failed because each system knows a customer by a different key.
Amanzi built a small lookup service: given a verified identity, it returns the identifiers that person has in each system and the operators that hold their information. It is not a new central copy of customer data. It holds only the mapping, it is access-controlled and logged, and it is itself personal information, so it has its own row in the control register and its own retention rule.
The index is fed by the same events that drive the deletion pipeline in Part 3. That is deliberate. If retention and access use the same map of where information lives, a gap in one shows up as a gap in the other, and both get fixed.
Generated data counts
The customer's question was about AI notes, and that is the category organisations most often miss. Amanzi now treats four kinds of generated data as in scope for every request:
- AI-generated text about the person, such as call summaries and case notes;
- scores and classifications, such as propensity scores, risk bands and segment memberships;
- embeddings and index entries linked to the person, described rather than dumped, because raw vectors are not "generally understandable";
- records of automated or assisted decisions, including which inputs were used.
"Generally understandable" is a real constraint. A propensity score of 0.71 means nothing to a customer. Amanzi's response explains what each score is used for and, in plain terms, what kinds of information it is based on. Where an output feeds a decision about the person, the explanation connects to the duties in section 71 that Part 2 described.
Third parties matter too. Section 23(1)(b) covers the identity or categories of third parties who have had access, so the response lists Amanzi's operators by category and any other recipients the information was disclosed to.
Redaction, not refusal
Call summaries often mention other people: a spouse who co-signed, a relative who called on the customer's behalf, an employer. Section 23(4) applies the refusal grounds in the Promotion of Access to Information Act, which include protection of third parties' privacy, and Amanzi's legal advisers decide how they apply. Section 23(5) then requires that where part of the information may or must be refused, every other part must be disclosed. Amanzi therefore redacts those passages rather than withholding whole records.
Opinions about the customer are a harder case for some teams. An AI summary that says "customer sounded evasive about income" is personal information about the customer, and Amanzi discloses it. If the organisation would be uncomfortable showing it to the customer, that is a signal about the summariser's instructions, not a reason to hide the output.
Correction closes the loop
When the customer saw their summaries, they disputed one: it recorded a promise to pay that they said they had never made. Section 24 sets the options. Amanzi could correct the record, provide credible evidence supporting it, or, if no agreement was reached and the customer asked, attach a note that a correction was requested but not made, in a way that ensures it is always read with the information.
Amanzi checked the call recording, found the summariser had misheard, and corrected the note. Because the note had fed a collections action, section 24(3) applied: the collections agency was told, and the warehouse record that had flagged the customer as a broken promise was corrected. The case closed with notice to the customer of the action taken, which section 24(4) requires and Amanzi gives in writing.
The correction also became input to the summariser's evaluation set. A correction request about AI output is free, high-quality feedback about where the model fails.
Test it before a customer does
Amanzi runs a drill each quarter. A staff member volunteers as a test customer, submits a request through a randomly chosen channel, and the team measures three things: days to complete, whether every system in the person index returned a result, and whether generated data was included. The first drill took 19 days and missed two systems. The fourth took six days and missed nothing.
The AI and POPIA series shows how to trace one question through an AI service. An access drill is the same exercise run backwards: start from one person and find everything the estate holds about them.
Start this week
- Ask your call-centre and chat teams how they would recognise and route a privacy request arriving on their channel. If the answer is unclear, that is your first fix.
- For one test customer, list every system and operator that holds their information, including AI outputs, scores and index entries. That list is the first version of your person index.
- Read your last three access responses and check whether any generated data about the person was included.
Next: Part 5, Classify the incident before you argue about it. All parts are on the series page.
How CloudNala can help
CloudNala helps organisations make access and correction requests answerable. We map where one person's information lives across your systems, operators and AI features, design the person index and case flow that connect them, and run a drill with your team to measure the result. We work with your information officer on the process and leave the legal determinations, such as refusal grounds, to your legal advisers.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a POPIA Controls Review or write to us at consult@cloudnala.co.za