Many organisations have an AI principles document. It says the organisation will use AI fairly, transparently, safely and accountably. It was approved by the executive committee, published on the intranet and has not changed a single decision since.
A principles document cannot enforce itself. Governance becomes real only when it changes something concrete: which systems may be used, which information may enter them, who may approve a new use, what evidence a system needs before it reaches production, and what happens when it goes wrong. Those are operating controls, and they do not need to wait for a final rulebook.
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 we have followed through this series, set up an AI use-case committee after the near-miss described in Part 1. This final part follows what that committee put in place, and why it did not wait for regulation to tell it what to do.
Where the rulebook stands
At the time of writing (October 2026), South Africa has no AI-specific legislation and no final national AI policy. Cabinet approved a draft National AI Policy for public comment earlier in 2026, and it was published in April. On 26 April 2026 the Minister of Communications and Digital Technologies withdrew it, after its reference list was found to include fictitious, AI-generated citations. In announcing the withdrawal, the Minister said the lapse showed why vigilant human oversight over the use of AI is critical.
It is hard to think of a clearer illustration of this series' argument. The failure that has led courts to refer matters to the Legal Practice Council, unverified authorities presented as real, reached the national policy meant to govern AI itself. The lesson is not that AI should not be used in policy work. It is that oversight is a practice with evidence, not an assumption.
In the courts, the Office of the Chief Justice released a draft AI policy for the judiciary for comment in 2026. As reported, it treats AI as an assistive tool rather than a substitute for judicial reasoning and expects its use to be disclosed. It is not yet final.
None of this leaves organisations without obligations. POPIA applies to any AI use that processes personal information. Professional duties apply to lawyers, doctors, auditors and engineers whatever tools they use. Consumer protection, employment, credit and sector rules apply to the decisions AI helps make. Our earlier piece on preparing for South Africa's AI policy reset argued that organisations should not wait for final regulation; the withdrawal has only lengthened the wait.
Ten controls that make governance real
The controls below are the minimum that turns principles into practice. Each produces a record, and the record is what an auditor, a regulator, a court or a customer can actually examine.
| Control | Practical output | At Spekboom |
|---|---|---|
| AI inventory | Named owner, purpose, users, models, data and risk tier for every use | 14 uses found, 5 more than IT knew about |
| Use-case approval | A recorded decision, with conditions, before production | The committee approves; low-risk uses by a lighter path |
| Authority policy | What the system may recommend, draft, calculate or execute, and where a person must decide | The authority matrix from Part 2 |
| Data policy | Permitted information classes, services and transfer conditions | The three classes from Part 4 |
| Evaluation | Task-specific quality, safety and failure tests | Hardship model tested on past cases before each change |
| Change control | Re-evaluation after any model, prompt, data or tool change | Vendor model updates treated as a change, not a patch |
| Monitoring | Quality, drift, overrides, incidents, cost and complaints | Override rates and review times per use, reviewed quarterly by the Head of Risk |
| Incident response | Containment, notification, correction, evidence preservation | AI incidents routed through the existing incident process |
| Appeals | Human review and remedy | The challenge route from Part 5 |
| Retirement | Data disposal, access removal, retained decision evidence | Evidence packs kept for the retention period after a use ends |
Two of these deserve a comment.
The inventory comes first because everything else depends on it. Spekboom's IT team believed the business had nine AI uses. The inventory found fourteen: the five extra were features switched on inside existing software, a browser extension a team had installed, and the public chatbot use described in Part 4. You cannot govern a use you do not know exists, and the uses nobody approved are, almost by definition, the ones with the fewest controls.
Change control is where most AI governance quietly fails. A model that passed its evaluation in March is not the same system after its provider updates it in June, its prompt is edited in July and a new data field is added in August. Each of those is a change that can alter the outcome for a person. Our piece on operating an AI product after deployment covers evaluation as part of release management in more depth.
Risk-tier the use, not only the model
It is tempting to approve models: this one is allowed, that one is not. Model approval matters, because it settles contract terms, data handling and security once. But it does not settle risk, because the same model can do very different jobs.
The same general-purpose model can draft a social-media caption and help inform a medical prior-authorisation decision. The second needs far more: stronger evidence that it works, people with the expertise to check it, tighter security, more testing, and a route for the affected person to challenge the outcome. The model did not change. The consequence did.
Spekboom tiers each use by four questions: what happens to a person if the output is wrong, how much the output influences the final decision in practice, how sensitive the information is, and how hard the outcome is to reverse. Call summarisation, where an agent edits a draft summary, sits low. The payment reconciliation assistant, whose output can reach an affidavit in a repossession matter, sits high, and carries the independent re-performance described in Part 2. The hardship model sits high as well, because its output shapes an arrangement a customer has to live with.
A structure that already exists
Organisations do not need to invent a governance framework from scratch. The NIST AI Risk Management Framework, published in January 2023 and now being revised, organises the work into four functions that map neatly onto the controls above: Govern (the committee, policies and accountability), Map (the inventory and the context of each use), Measure (evaluation and monitoring) and Manage (approval, change control, incidents, appeals and retirement). NIST's Generative AI Profile, published in July 2024, adds risks specific to generative systems. It is a voluntary framework, not South African law, but it is a sound structure to borrow while local policy settles.
How Spekboom put it in place
Spekboom did not start with a framework. It started with a near-miss and a committee.
The AI use-case committee is chaired by the Head of Risk and includes the Head of Legal, the Information Officer, the Head of Collections and the Head of IT. It meets monthly, and its decisions are recorded with conditions and review dates. In its first quarter it did four things in order: built the inventory; tiered every use; put the high-tier uses (reconciliation and hardship) through the full set of controls; and wrote a lighter approval path for low-tier uses, so that the committee did not become the bottleneck that drives people back to the public chatbot.
The committee's most useful rule is a short one: no AI use reaches a customer or a court without a named owner, a recorded tier and an evidence pack. Everything else in this series follows from it.
Common mistakes
- Publishing principles and stopping. Principles that change no decision are a statement, not governance.
- Waiting for final regulation. Existing law already applies, and the draft national policy has been withdrawn.
- Approving models instead of uses. The same model carries different risk in different jobs.
- Skipping the inventory. The uses nobody approved are the ones with the fewest controls.
- Treating vendor model updates as patches. They can change outcomes for people; re-evaluate them.
- Making every use go through the full committee. A process that cannot handle low-risk uses quickly pushes people to unapproved tools.
Questions to ask this week
- Do we have an inventory of every AI use, including features switched on inside existing software?
- Who can approve a new AI use, and is that decision recorded with conditions and a review date?
- Have we tiered our AI uses by their consequence for people, not only by which model they use?
- What happens when a vendor updates a model we rely on?
- Is there a lighter path for low-risk uses, so that governance does not become the reason people bypass it?
- If a regulator asked tomorrow for evidence of how we govern AI, what records could we show?
What to take from this part
Principles do not enforce themselves. Controls that produce records do.
Do not wait for the rulebook. POPIA, professional duties and sector rules already apply, and the draft national policy has been withdrawn.
Inventory first. You cannot govern what you have not found.
Tier the use, not only the model. Consequence decides the controls.
That completes the series. The durable principle is simpler than any regulation is likely to be: when AI affects a person, the organisation must bound its authority, protect the information, preserve the evidence and provide accountable human review. Start again from Part 1, or see every part on the series page. For a broader introduction, see our piece on responsible AI in South Africa.
How CloudNala can help
We help organisations turn AI principles into operating controls: building the AI inventory, designing a risk-tiering method based on consequence, setting up approval, change control, monitoring and evidence processes that people will actually use, and creating a lighter path for low-risk uses. We are not a law firm; we design and run the governance machinery alongside your legal, risk and compliance teams, who decide what the law requires.
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