Before it wrote its ownership statement and its decision-rights matrix, Kwena Life Assurance, a fictional South African life insurer, had an AI steering committee. Everything about the committee is illustrative, but the pattern will be familiar. The committee met monthly, had fourteen members and approved every AI use case. Within a year it had a queue of proposals, a backlog of "conditional approvals" whose conditions nobody tracked, and a reputation as the place where ideas went to wait.
The real problem surfaced after a minor incident, when a document-summary tool in the underwriting team quoted the wrong policy schedule to a broker. Asked who was accountable, each executive answered, sincerely, that the committee had approved it. The committee had approved it. Nobody on the committee had owned it.
Part 1 of this series split ownership into seven named kinds. Part 2 gave each lifecycle stage six decision rights, with one named approver per decision. This final part deals with the body that is supposed to hold it together. A governance council is valuable. Its job is to coordinate, and the moment it starts to own, accountability disappears into the minutes.
Why committees drift into ownership
The drift is understandable. AI is new, risks are uncertain and executives want reassurance. A committee that "approves AI" feels safe because many senior people looked at each proposal. But collective approval has three effects that work against good governance.
- Diluted accountability. When fourteen people approve, nobody can be held to account for the decision in the way a single approver can.
- Shallow review. A monthly agenda with eight proposals gives each one minutes, not hours. The committee reviews the slide, not the evidence.
- A single path. Every AI use, from a meeting-notes summariser to a claims agent, goes through the same queue at the same depth. Low-risk work waits; high-risk work gets the same twenty minutes as everything else.
NIST's AI Risk Management Framework, in its Govern function, asks for accountability structures in which "the appropriate teams and individuals are empowered" and in which roles are "documented and are clear to individuals and teams throughout the organization". A committee that approves everything does not meet that intent. It blurs it.
What the council is for
Kwena rebuilt its committee as a governance council with five jobs, and only five.
- Keep the shared AI risk register. One register of every AI system, its owners, its risk tier, its material risks and controls, the date of its last evidence, open challenges and live exceptions.
- Set common standards. Minimum requirements that every system must meet for its tier: the material-change list from Part 2, logging and retention rules, evaluation minimums, the human-authority rule for adverse decisions.
- Resolve cross-cutting conflicts. When two owners disagree and the matrix does not settle it (the data owner and the outcome owner on a new data source, say), the council decides which right applies, records the reason and hands the decision back to the named person.
- Track exceptions. Every approved departure from a standard has an owner, a compensating control and an expiry date. The council tracks them and chases expiry. Each exception still has one named approver: at Kwena, the council chair, acting as the owner of the common standards after hearing the affected owners.
- Report upwards. A regular, honest report to the executive committee and the board's risk committee on the portfolio, its risks and the exceptions outstanding.
These jobs are the operational core of the broader framework described in AI governance: the framework your organisation needs before scaling AI. Notice what is missing: approving individual systems. Under Kwena's matrix, the business outcome owner approves release, with security and model risk able to challenge and stop. The council sees the decision in the register and can raise a concern. It does not approve in the approver's place.
What the council must not do
- Approve on behalf of a named owner. If the council's minutes say "approved", the decision log must still show the name of the person who approved under the matrix.
- Hold accountability. The council is accountable for running the register and the standards well. It is not accountable for any AI system's outcomes.
- Be the only path. Low-tier systems should never need the council's time. A register entry and adherence to the standard are enough.
- Own the platform. The AI platform has an owner (the CIO in Kwena's case). A council that starts choosing products has become a design authority, which is a different body with a different job.
- Hide risk behind value. A portfolio report that shows benefits in detail and risk as a colour is not oversight. What an AI value dashboard should show the board sets out a one-page view in which risk appears as a boundary, not a traffic light.
Tier first, then govern
The council's first practical act at Kwena was to tier the portfolio. Three tiers were enough.
| Tier | Example at Kwena | What the council does |
|---|---|---|
| Low | Meeting-notes summariser for internal use | Register entry; standard applies; no council time |
| Elevated | Underwriting document summaries for staff | Register entry; evidence reviewed at least twice a year; exceptions tracked |
| High | Claims-assistance agent that touches claimants | Full decision-rights matrix; evidence reviewed at every material change; reported to the board risk committee |
Tiering is the single change that most reduces the queue. It matters even more where business teams build their own tools, the pattern described in Citizens build: a council that insists on reviewing every business-built automation will either stall the programme or be bypassed by it. It also makes the council's attention proportional: the claims agent gets real scrutiny because the meeting-notes tool no longer competes for it. The low-tier boundary must still be honest. Sandbox is a risk label explains how "experimental" systems become permanent without anyone deciding they should.
The shared register
Kwena's register has one row per AI system and these fields:
- system name and purpose;
- the seven owners from Part 1, by name;
- risk tier and the reason for it;
- material risks and the controls that address them;
- date and reference of the most recent evaluation evidence;
- open challenges, with who raised them and when an answer is due;
- live exceptions, with owner, compensating control and expiry;
- next scheduled review.
The register is not the AI claims register, a record of claims made about AI, such as accuracy figures and time savings, and the evidence behind them. The two complement each other: one tracks whether systems are safe to run, the other whether what is said about them is true. Both should be visible to internal audit.
Exceptions and escalation
Exceptions are where governance either earns trust or loses it. Kwena's rule is simple: an exception without an expiry date is a new standard nobody agreed to.
When something cannot be resolved where it arises, it moves up a defined path:
- The named owner decides, within the rights the matrix gives them. Most issues end here.
- The council takes it when it crosses owners (a conflict between two rights), when a challenge has not been answered within the agreed time, or when an exception needs approval or extension, which the council chair approves as the named approver.
- The executive committee takes it when the council cannot resolve it, or when the decision changes the organisation's risk appetite.
- The board's risk committee sees it when it is material to the organisation, through the regular report or by exception.
Escalation must work in both directions. When the council resolves a conflict, the decision goes back to a named owner to execute, with the reason recorded. The council never becomes the place where a decision permanently lives.
Kwena's council, redesigned
The new council is smaller and faster than the old committee.
- Membership. One seat per function rather than per enthusiast: business-line representatives, the CIO, engineering, the CISO, data, claims operations, and legal, compliance and model risk, with internal audit as a standing observer. Roughly half the old committee's size.
- Cadence. Forty-five minutes every two weeks, plus an extraordinary session when a stop right is used on a high-tier system.
- Agenda. Generated from the register: expiring exceptions, overdue challenges, material changes since the last meeting, cross-owner conflicts. If the register is quiet, the meeting is short.
- Decision log. Every council decision records the named owner who will execute it and the right under which they act.
- Board report. Quarterly: the high-tier portfolio, evidence currency, exceptions outstanding and their age, incidents and stops, and the value evidence behind each high-tier system.
Within two quarters of the redesign the queue had gone, because most proposals no longer needed the council at all. The council's time went to the handful of decisions that genuinely crossed owners.
Signs your council has become the owner
- Minutes say "the council approved" with no individual named.
- Low-risk tools wait for a meeting.
- Exceptions have no expiry dates, or expiry dates nobody chases.
- After an incident, executives cite the council's approval rather than their own decision.
- The council chooses products and models.
- The board report shows value in detail and risk as a colour.
Any one of these is worth fixing. Three or more means the council is carrying accountability that belongs to named people.
This is general information about governance design, not legal or regulatory advice. Regulated organisations should confirm with their advisers how their governance arrangements meet the obligations that apply to them.
Key points
- A governance council coordinates: it keeps the shared register, sets common standards, resolves cross-owner conflicts, tracks exceptions and reports upwards.
- It must not approve in place of a named owner, hold accountability for outcomes, choose products or be the only path for every AI use.
- Tier the portfolio first, so that council attention is proportional to risk.
- Give every exception an owner, a compensating control and an expiry date, and escalate in a defined path that always returns decisions to a named person.
- Report value and risk together, with risk shown as a boundary rather than a colour.
This is the final part of AI Governance Is a Team Sport.
How CloudNala can help
CloudNala runs AI governance reviews for organisations whose AI committee has become a queue or an accidental owner. We tier your AI portfolio, build the shared register from your existing records, redesign the council's mandate, membership, agenda and decision log, and set up the exception and escalation rules, so that the council coordinates and named people remain accountable.
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 Governance Review or write to us at consult@cloudnala.co.za