Decision rights across the AI lifecycle

A few months after Kwena Life Assurance, a fictional South African life insurer, approved its claims-assistance agent for funeral claims, its model provider announced that the model version the agent used would be retired. Kwena had a one-page ownership statement for the agent, written as Part 1 described. It named seven owners. It did not say which of them could approve the switch to a new model version, who could object, or who could stop the switch if the evaluation results were poor. Engineering assumed it could proceed because the change was "technical". Model risk assumed it would be consulted because the change was "material". The claims business did not know the change was happening.

Ownership tells you who is accountable for a part of the system. It does not tell you who decides what at each moment of the system's life. That needs decision rights, defined per lifecycle stage. This part sets them out.

Why a RACI is not enough

Most organisations reach for a RACI chart: responsible, accountable, consulted, informed. It is a reasonable start, and for AI systems it leaves out the two rights that matter most when something is uncertain.

• Challenge. "Consulted" means someone was asked. It does not mean they could object, that the objection had to be answered, or that the answer was recorded. Independent challenge is how risk, compliance and security functions do their job, and a RACI flattens it into a courtesy.
• Stop. A RACI has no column for the person who can halt a release or switch off a live system. In practice, the right to stop is often unclear until the moment it is needed, and then it is argued about.

There is also a structural problem. "Accountable" in a RACI is usually one person per activity, which is right. But AI systems change after release in ways conventional systems do not (a new model version, a revised prompt, a new data source), so the accountable person for "build" is not necessarily the right person to approve a change that alters behaviour in production.

Six rights

CloudNala uses six rights instead. They are deliberately verbs.

1. Recommend. Propose a decision with the evidence for it. Several people may hold this right.
2. Approve. Make the decision. One named person per decision, never a committee.
3. Execute. Carry out the approved decision.
4. Challenge. Object, on stated grounds, with the right to a written answer before the decision takes effect. Held by functions that are independent of the approver.
5. Monitor. See the evidence on an ongoing basis, with access to the data needed to do so.
6. Stop. Halt a release or suspend a live system, immediately, without needing consensus.

Two asymmetries are intentional. The stop right is wider than the approve right: more people can stop a system than can start it, because stopping a misbehaving claims agent is cheap and recoverable, and leaving it running may not be. And a stop is easy to invoke and harder to reverse: restarting after a stop needs the approver, with the reason for the stop answered.

The lifecycle matrix

The most useful single asset is a decision-rights matrix across the lifecycle. Here is Kwena's. The roles are those from Part 1. Your titles will differ.

Abbreviations: BO business outcome owner (head of claims), PO process owner (claims operations manager), CIO platform owner, ENG engineering owner, CISO security owner, DO claims data owner, LCR legal, compliance and model risk, GC governance council.

A few rows need explanation.

Evaluation. Engineering runs the evaluation and the process owner helps define what an acceptable result looks like, but the business outcome owner approves the threshold. A threshold is a statement about acceptable harm ("no more than this proportion of complete claims wrongly flagged as incomplete"), and only the person accountable for the outcome can accept it. Model risk holds challenge and stop, because a failing evaluation is the clearest reason to halt. Evals that gate real work covers the evaluation mechanics.

Release. One approver, the business outcome owner, and only after the CISO and LCR have either not objected or had their objections answered in writing. Three parties can stop a release, two of them independent of the approver. That is not bureaucracy. It is the minimum number of independent views that a regulated insurer should want before an AI system touches claimants.

Live operation. The process owner approves how the system is used day to day, including which cases go to the agent and which go straight to an assessor. The process owner, the CIO and the CISO can each suspend it. LCR and the CISO keep their challenge rights, and internal audit provides periodic independent assurance on top of them.

Material change. This is the row Kwena did not have. It is covered in detail below.

What counts as a material change

A conventional system changes when code changes. An AI system can change behaviour when any of these change:

• the model or model version;
• the system instructions or prompts;
• the tools the agent may call, or their descriptions;
• the data sources it reads or retrieves from;
• the population of cases it handles (for example, extending from funeral claims to another claim type);
• the thresholds that route cases to people.

Kwena now treats each of these as a material change by default. The engineering owner may downgrade a change to non-material, with a written reason, only when the full evaluation set shows no meaningful difference, and model risk can challenge that downgrade. Upgrade evidence belongs in the architecture record describes how to keep that evidence where the next reviewer will find it.

The model retirement, replayed

With the matrix in place, Kwena's model retirement ran differently.

1. Recommend. Engineering proposed two candidate model versions and ran both through the full evaluation set, including the cases where the correct answer is "documents incomplete, ask the claimant".
2. Challenge. Model risk challenged one candidate: it scored well overall but flagged complete claims as incomplete more often for claims with handwritten affidavits. Engineering answered in writing and withdrew that candidate.
3. Challenge. The CISO confirmed that the remaining candidate ran under the same data-handling terms and logging configuration. No objection.
4. Approve. The head of claims approved the switch, against the threshold she had set, with the evaluation report attached.
5. Execute. Engineering released it behind a gradual rollout, with the claims operations manager watching assessors' override rates.
6. Monitor. The governance council recorded the change in the shared register.

Nobody needed a meeting of seven people. Each right was exercised by the person who held it, in order, with a record.

Designing your own matrix

• Start from one real system. A matrix designed in the abstract becomes a policy nobody reads. Design it for the AI system closest to production, then generalise.
• One approver per row. If two people insist on approving, one of them probably needs the challenge right instead.
• Make challenge answerable. Set a time limit for the answer, and record both.
• Publish the stop list. Everyone who holds a stop right should know it, and the operations team should know how to execute a stop at 2 a.m. A stop that depends on a redeployment is not a stop; Containment is an architecture feature covers the switches that make it real, and Governance after an AI failure covers what happens after one is used.
• Write the material-change list first. It is the row most organisations are missing, and it is the one that will be tested first, usually by a supplier's model retirement notice.
• Review the matrix when the system changes scope. A matrix for funeral claims is not automatically right for another claim type.

Remember the human authority line from Part 1 throughout. The matrix governs the system. It does not delegate case decisions to it. Adverse decisions about claimants remain with named officials, which Agent capability is not agent authority explains at the level of individual actions.

This is general information about governance design, not legal or regulatory advice.

Key points

• A RACI leaves out the two rights that matter most for AI systems: independent challenge and the right to stop.
• Use six rights per lifecycle stage: recommend, approve, execute, challenge, monitor and stop, with one named approver per decision.
• Make stop rights wider than approve rights, and make restarting harder than stopping.
• Treat changes to the model, prompts, tools, data sources, population or thresholds as material by default.
• Build the matrix for one real system first, starting with the material-change row.

Next: Part 3, The AI governance council coordinates. It does not own. All parts are on the series page.

How CloudNala can help

CloudNala runs AI governance reviews that produce a working decision-rights matrix rather than a policy document. We take one of your AI systems through its ten lifecycle stages with the people who hold each right, define your material-change list, test the matrix against a realistic change such as a model retirement, and leave you with a matrix your teams can follow and your auditors can check.

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