The uncomfortable question
Say the Information Regulator arrived at your business tomorrow. They ask you to demonstrate how personal information under your control has been handled in the last six months. Could you tell them whether any staff member had pasted a customer’s ID number, banking detail, medical history or contract terms into a public AI chatbot?
Could you tell them how you would know if it had happened?
If the honest answer to either question is “I don’t know,” you have a POPIA problem. You just have not been told about it yet.
Why this is a live risk right now
The observable pattern across SA small businesses in 2026: employees are using AI to speed up their work. Some of that use is sanctioned. Most of it is not. The typical shape is a customer email, a support ticket, or a contract paragraph pasted into a public chatbot with a “help me reply to this” prompt.
That paste event has three regulatory dimensions.
POPIA §19 requires “appropriate, reasonable technical and organisational measures” to keep personal information secure. Transmission of personal information to a third-party service without a lawful basis is a breach of POPIA’s core conditions on lawful processing and security, and potentially a §19 breach too if that AI vendor isn’t contractually bound as an operator. It is not a breach only if there is later evidence of leakage.
POPIA §22 requires notification to the Information Regulator when personal information “has been accessed or acquired by any unauthorised person.” Under many public AI vendor terms, prompts are retained and may be used for training. Whether that constitutes acquisition by an unauthorised party is a live legal question. What is not in question: the business must be able to demonstrate its position.
Sector rules stack on top. If the business is a Financial Services Provider, the General Code of Conduct adds requirements. If it handles health information, HPCSA guidance applies. If it processes payment card data, PCI DSS controls apply. None of these dissolve because the tool changed.
The shared-responsibility model that actually works
A well-run AI posture for a SA SME looks like a three-way responsibility split. Each party owns a piece. Gaps between them are where breaches live.
The AI vendor is responsible for the security of the platform, the data-handling terms of the tier the business is paying for, and honouring those terms. A free-tier chatbot and a paid enterprise tier are different products with different data postures. The vendor’s responsibility ends at what they contractually committed to.
The MSP (or internal IT function) is responsible for the technical guardrails. Which AI tools are approved. Which are blocked at the network. What logging is in place. What data-loss-prevention controls sit between the endpoint and the internet. What browser controls prevent copy-paste of flagged content into unapproved destinations. Every one of these is a technical control that either exists or does not. The MSP owns the “does it exist” question.
The business is responsible for the policy layer. What is allowed. What is not. Who reviews AI-drafted client-facing content. Who owns the audit trail. What the training programme looks like. What the sanction is when the policy is breached. Without the policy layer, technical controls are unpaced. Without the technical controls, the policy is a wish.
An SME that has any two of the three has a partial defence. An SME that has all three has a real one.
Where the three failure modes sit
Failure mode 1: staff pasting client data into public chatbots. MSP responsibility to prevent (technical control), business responsibility to prohibit and train (policy), employee responsibility to comply. When it happens without controls, it is a POPIA §19 breach. When it happens against controls, it is a disciplinary matter with reduced regulatory exposure.
Fix: an approved AI tool with a documented data-handling posture. A blocked list at the network for the unapproved ones. A written policy stating which categories of information may and may not be pasted into any AI tool. Training that references real examples from the business.
Failure mode 2: AI-drafted content making claims the business cannot substantiate. Business responsibility. Especially acute for regulated sectors: financial services, health, legal, property. An AI is drafting a marketing email or a client-facing document. Nobody notices the specific claims are now representations the business must defend.
Fix: a compliance screen between drafting and publishing for regulated topics. Structured checklist. Written verdict. Kept for the retention period.
Failure mode 3: no audit trail. Business responsibility. When a customer complaint, a regulator query, or an insurer question lands, the answer to “who wrote this and when” must arrive in minutes. “One of the team used a chatbot” is not that answer.
Fix: every AI-drafted piece traceable to a prompt, a draft, a reviewer, and a publish decision. This can be as simple as a shared spreadsheet, as long as the discipline holds.
What the MSP layer actually looks like
For clients we serve, the technical controls sit at three points.
At the identity layer. Approved AI services accessed via corporate SSO where possible. Personal accounts for corporate use flagged and blocked.
At the network layer. Unapproved AI destinations blocked or logged at the firewall. This is not perfect (personal devices, mobile networks) but it catches the majority.
At the endpoint. Browser-level controls where the risk profile warrants it. Data-loss-prevention rules that flag pasting of specific data patterns (ID numbers, card numbers, medical codes) into any web input.
None of this stops a determined bad actor. All of it stops the far more common problem: well-intentioned staff moving fast, unaware that a helpful shortcut just breached §19.
The one-page policy that starts you off
Before the technical controls, before the compliance screen, before any of it: a one-page policy.
Name the approved AI tools staff may use. Name the categories of information that may and may not be pasted into them. Name the review path for AI-drafted client-facing content. Name the person who owns the audit trail. Get it signed by the business owner. Circulate it. Refer to it when something goes wrong.
That page is not a compliance program. It is the start of one. It is also the difference between “we are managing this risk” and “we did not know this was happening.” The Information Regulator, insurers and courts all treat that difference as material.
Where cyber insurance comes in
The next twelve months of cyber insurance renewals will include AI-use questions. Whether the insurer prices better for evidence of documented AI policy, technical controls and training. Whether cover excludes claims arising from unmanaged AI use by employees. Whether the deductible increases when the incident traces to a shadow AI tool.
We’re already seeing insurers factor this in for clients who can show the three-layer posture, renewing on more favourable terms. The businesses without it are the ones renewing on worse terms, or getting declined for reasons they don’t immediately understand.
Where this ends
AI is not going away in your business. Neither is the Information Regulator, the FSCA if you are regulated, or the cyber insurer at renewal. The businesses that treat these facts as compatible will keep moving. The ones that treat them as a choice will pick badly.
Speed without guardrails is not speed. It is a bill you have not received yet.
This is general information based on how we see these rules applied in practice, not legal advice – get a POPIA-competent attorney to sign off on your specific policy before you rely on it.
Want the shared-responsibility model built into your IT posture?
Gknect Managed IT builds the technical layer of this model for SA SMEs. The approved-tool list, the network controls, the DLP rules, the incident procedure. Reach out via gknect.com.
Part 2 of a 4-part series on how Marcos Diez uses AI to run GKnect. Coming next: one person now runs what took five.
