The fastest way to get a well-written letter, a tidy summary or a sharper paragraph is to paste the raw material into a public AI tool and ask. It takes seconds, it costs nothing, and it usually works. That is exactly why so much confidential information ends up in places nobody approved.
Convenience is not a processing justification. A customer's account history, an employee's disciplinary notes or a privileged legal opinion does not become less sensitive because the task feels small or experimental. The question that has to come first is not "which tool is best for this?" but "what information is this, and which services is it allowed to enter?"
This series is general information about governing AI in organisations, not legal advice. Where it describes court judgments or legislation, it summarises them for a non-legal audience; read the primary sources and take advice from a qualified legal practitioner before relying on any interpretation for your organisation.
Spekboom Finance is fictional, and its processes and figures are illustrative. Spekboom, the Durban consumer lender and collections business we follow through this series, already had an approved enterprise AI service. It still found a problem, and the way it found it is the subject of this part.
The spot check
When Spekboom's new AI use-case committee began building an inventory of every AI use in the business (Part 6 covers the inventory), the information officer ran a simple spot check of which AI services staff were actually reaching from company devices. Two findings stood out.
Collections agents had been pasting customer details (names, ID numbers, arrears balances and payment histories) into a free public chatbot to draft letters, because the approved service needed a separate sign-in and the public one was already open in a tab. And a manager had pasted an employee's disciplinary notes into the same kind of tool to "make them sound more professional".
Nobody had acted maliciously. Everyone had been trying to do their job faster. There was no sign the information had been misused. But Spekboom's information officer and legal team still had to assess whether what had happened amounted to a security compromise that needed to be notified under section 22 of POPIA, and to the people concerned. That assessment is theirs to make, and the outcome is not the point here. The point is that it had to be made at all, about information that never needed to leave Spekboom's control for the task to be done.
What counts as high-risk input
Some information carries more risk than the rest, either because the law treats it more strictly or because the harm from exposure is greater:
- identity and contact information;
- health, biometric and children's information;
- financial records and account details;
- privileged legal communication;
- witness statements and sealed or confidential court records;
- employee performance and disciplinary material;
- proprietary business information, such as pricing, strategy or unpublished results.
Two distinctions are worth getting right. Special personal information under section 26 of POPIA covers religious or philosophical beliefs, race or ethnic origin, trade union membership, political persuasion, health or sex life, biometric information, and criminal behaviour; processing it starts from a prohibition with defined exceptions. Children's personal information is dealt with separately, in sections 34 and 35, and is not part of the section 26 list. Both are stricter than the general rules, and both are easy to paste into a chat box without noticing.
Questions to settle before information enters a service
Before any AI service is approved for a class of information, someone with the authority to decide should have answers to these:
- Roles. Under POPIA, the responsible party decides the purpose and means of processing; an operator processes on the responsible party's behalf, under a contract or mandate. When Spekboom uses an enterprise AI service for its own work, Spekboom is the responsible party. The contract should make clear in which capacity the provider processes the information and for what purposes. If the terms allow the provider to use inputs for its own purposes, such as improving its models, that is a different relationship and a different risk.
- Purpose and lawful basis. Why is this information being processed, and on what basis? A new purpose needs its own answer, even if the information was collected lawfully for something else.
- Minimisation. Does the task need the identifiable information at all, or would a redacted or tokenised version do the same job?
- Security safeguards. Section 19 requires appropriate, reasonable technical and organisational measures. Sections 20 and 21 require that an operator processes only with the responsible party's authorisation, treats the information as confidential, works under a written contract that requires security measures, and notifies the responsible party immediately if it suspects a compromise.
- Retention. How long does the service keep prompts, outputs and files, and can that be configured?
- Model-training terms. Many consumer AI services' terms allow inputs to be used to improve the service unless a setting or a paid plan says otherwise. Read the specific terms for the specific plan.
- The provider's own subcontractors. Who else processes the information on the provider's behalf, and where?
- Cross-border transfer. If processing happens outside South Africa, section 72 sets the conditions under which that is permitted. It is not a blanket prohibition; our plain-language piece on why POPIA does not require your data to stay here explains the conditions.
POPIA's conditions apply to an experiment exactly as they apply to a production system. "We were only trying it out" is not a category the Act recognises.
Classify the information, then choose the tool
The most practical change Spekboom made was to reverse the order of the decision. Staff no longer start by opening a tool and wondering what they may put in it. They start with the information.
Spekboom uses three classes for AI purposes. Low: public or internal business content with no personal information, which may go into any approved AI service under the use policy. Confidential: customer, financial and employee records, which may go only into the enterprise service, whose contract has been checked for processing capacity, training use and retention. Special or privileged: health, biometric and children's information, privileged legal material and sealed records, which may not enter any AI service without a specific approval and sign-off from the legal team.
The classes are deliberately few. A scheme with nine classes will not be applied at the point of use by a collections agent with a customer on the line. Our traffic-light approach to which data AI can touch works the same way, and is a good starting point if you do not yet have one.
Nine controls that make the decision stick
A policy that says "do not paste customer data into public tools" is necessary and not sufficient. It has to be backed by controls that make the right thing easy and the wrong thing hard.
- An approved enterprise service and contract, with processing capacity, training use, retention and the provider's subcontractors checked.
- Classification at the point of use, so that the person about to paste knows which class they are holding.
- Prohibited-data rules enforced where practical. Spekboom's data-loss rules now flag South African ID numbers and account numbers being sent to unapproved AI services, and its web filter blocks the public chatbots staff had been using on company devices.
- Strong identity and least privilege, so that the enterprise service sees only what the user is entitled to see.
- Encryption and controlled network paths between Spekboom's systems and the service.
- Configured retention and deletion, set to the shortest period the business's own needs allow.
- Redaction or tokenisation where it preserves the task. Spekboom's letter drafting now works on placeholders: the AI writes the letter around fields such as the customer's name and arrears amount, and the collections system fills them in afterwards. The model never sees the real values, and the letter is just as good.
- Logging that avoids a second uncontrolled copy. Routine chat history in the enterprise service is kept briefly. Where an AI interaction shapes a consequential decision, the evidence is captured deliberately into a protected store, as Part 3 describes, rather than left scattered across chat logs.
- Incident response that covers prompts and model services, so that the next spot-check finding has an owner, a process and a clock.
Notice that the controls answered the reason staff gave. They used the public tool because the approved one was a separate sign-in away. Spekboom moved the enterprise service behind the same single sign-on as everything else, and put a link to it in the collections system. Blocking the shortcut works far better when the approved path is shorter.
Common mistakes
- Choosing the tool before classifying the information. By the time someone is in the chat box, the decision has already been made by habit.
- Treating a contract as the whole answer. A good contract is one of nine controls; it does not stop a person pasting into a different service.
- Assuming consumer and enterprise terms are the same. Training use, retention and subcontractors often differ by plan. Read the terms for the plan you actually use.
- Calling it an experiment. POPIA's conditions apply to pilots and proofs of concept in full.
- Confusing special personal information with children's information. They sit in different parts of the Act, and both are stricter than the general rules.
- Blocking without providing. If the approved service is harder to reach than the public one, people will find another shortcut.
- Keeping every chat forever "for evidence". Indiscriminate logs become a second uncontrolled copy; capture evidence deliberately where decisions are made.
Questions to ask this week
- Which AI services can staff reach from company devices today, and which of those are approved?
- For each approved service, do we know in which capacity the provider processes our information, whether inputs are used for training, and how long they are kept?
- Do we have a classification scheme that a front-line employee could apply in five seconds?
- Which tasks currently send identifiable information to AI that could be done with placeholders or redaction?
- Who decides whether an AI-related disclosure is a security compromise that must be notified, and have they been told this could happen?
- Is the approved AI service easier to reach than the unapproved ones?
What to take from this part
Convenience is not a justification. The task being quick does not make the information less sensitive.
Classify first, then choose. The class of information decides which services are allowed.
A contract is one control of nine. Identity, minimisation, retention, logging and incident response matter as much.
Make the approved path the short path. People route around controls that slow them down.
Next in the series: A person needs a route to challenge the outcome.
How CloudNala can help
We help organisations decide what information may enter which AI service: building a classification scheme people can actually apply, checking enterprise AI terms for processing capacity, training use and retention, designing redaction and placeholder patterns that keep identifiable data out of prompts, and putting the technical controls in place. We are not a law firm, and we work alongside your information officer and legal advisers, who make the legal calls.
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 an AI Readiness Workshop or write to us at consult@cloudnala.co.za