Most organisations did not decide to adopt AI. It arrived, in browser extensions, in features their existing vendors switched on by default, and in the personal accounts of people trying to get work done faster.
That means the useful question is rarely whether to allow it. It is how to get visibility and guardrails around something already in use, without writing a policy that everyone quietly ignores. Here is a checklist that survives contact with a real organisation.
1. Find out what is already in use
Start with discovery, not policy. Check your identity provider for OAuth grants and single sign-on applications nobody registered. Check expense claims for AI subscriptions. Check your browser management console for extensions with broad page access. Ask teams directly, without a punitive framing, because the answer you get depends entirely on whether people expect consequences.
You are looking for two categories: tools people signed up for, and AI features your existing vendors enabled in products you already pay for. The second category is larger than most teams expect and is usually invisible until someone goes looking.
2. Decide what data may leave before you decide which tools are allowed
Tool-by-tool approval does not scale and goes stale within weeks. Data classification does.
Write a short, blunt list. Something like: public and internal material may go to approved tools; customer personal information, credentials, security findings, unreleased financials, and anything under NDA may not, regardless of which tool is asking. Then put that list where people are actually working rather than in a policy portal nobody opens.
Under POPIA, sending personal information to a model provider makes that provider an operator, which triggers Section 21: a written contract, an obligation to maintain Section 19 security measures, and an obligation to notify you of unauthorised access. If you have not done that paperwork for a given vendor, personal information should not be going to it.
3. Check retention and training terms per tier
The same vendor frequently applies different data handling to its free, personal, and enterprise tiers. Free tiers commonly train on input. Enterprise agreements commonly do not, and add retention controls. Approving the vendor is not the same as approving the tier your staff are actually using.
The questions worth answering in writing for each approved tool: is input used for training, how long is it retained, where is it stored geographically, who at the vendor can access it, and what happens to it on termination. Data residency matters for the cross-border transfer conditions in Chapter 9 of POPIA, and it is the question vendors answer least clearly.
4. Treat model output as untrusted input
This is the control that most changes engineering outcomes. Anything a model produces should be handled with the same suspicion as data submitted by an anonymous user.
If output flows into a shell, a database query, a browser, an email, or another system’s API, it needs validation and encoding at that boundary. The failure mode is not the model turning malicious. It is the model faithfully reproducing an instruction that was embedded in the content it was asked to process.
5. Constrain permissions, not just prompts
For anything agentic, meaning a system that can take actions rather than only produce text, prompt-level guardrails are a mitigation rather than a control. They can be talked around, and people will find the phrasing that does it.
The real boundary is the credential. Give the system its own identity, scoped to the minimum it needs, with the same joiner-mover-leaver discipline you apply to people. Require human confirmation for actions that are irreversible, that move money, that send external communication, or that change access. Assume the instruction layer will eventually be manipulated, and design so the consequences are bounded when it is.
6. Log the interaction
If you cannot reconstruct what was asked, what was returned, and what was done as a result, you cannot investigate an incident involving these tools, and you cannot answer a data subject request about them.
Log the prompt, the response, the identity, the timestamp, and any action taken. Then treat that log as sensitive in its own right, because it now contains everything anyone has pasted into the tool.
7. Put a human where the consequence is
Review is a targeted requirement, not a blanket one. Apply it where a wrong answer is expensive or hard to reverse: anything customer facing, anything that becomes a legal or contractual statement, anything that changes production, and anything used to make a decision about a person.
That last one is not discretionary. Section 71 of POPIA restricts decisions made solely on the basis of automated processing where they have legal consequences for a data subject or substantially affect them. Recruitment screening, credit decisions, and automated fraud blocking all sit inside that zone.
8. Train people on the failure mode, not the tool
Tool training goes stale in months. What lasts is the mental model: these systems produce fluent, confident text regardless of whether they know the answer, and fluency is not evidence.
The practical version is a short exercise. Give people a task, let them use the tool, then show them a case where it was confidently and specifically wrong. One demonstration does more than an hour of policy reading.
9. Set a review date
This space moves faster than your policy cycle. Whatever you write will be partially wrong within two quarters, most often because a vendor changed a default or shipped a feature nobody asked for.
Put a date on the document. Ninety days is reasonable. The specific interval matters less than the fact that somebody owns it and it is scheduled rather than aspirational.
The shape of a good answer
A workable AI policy is roughly one page: what data may leave, which tools are approved and for what, where human review is required, and who to ask when the answer is unclear. If yours is longer than that, it is being written for an auditor rather than for the people who have to follow it, and it will be followed accordingly.