Decision Rights in an AI-Native Operating Model

Why decision rights are the hardest part of AI enablement

Module 3 covered the workflow redesign framework. Module 5 will cover the data layer. This module — decision rights — is the bridge between them, and it is the part of AI enablement that organisations most consistently get wrong.

The reason it gets wrong is straightforward. When a system starts generating outputs by default, the question of who decides what changes shape. It is no longer a matter of "who does this task." It is a matter of "who owns the decision the system just made, and on what basis can they override it?" That is a different question, and most organisations have never had to answer it explicitly. They answered it implicitly by giving people jobs that bundled doing-the-work and owning-the-outcome together. AI separates those two things. Once they are separated, you have to redesign the ownership.

This module gives you a working framework for doing that.

The three reasons humans stay in the loop

In an AI-native workflow, every human touchpoint should fall into one of three categories. If you cannot put a touchpoint into one of these categories, it probably shouldn't exist.

1. Judgment. The human is being asked to exercise reasoning the system can't — interpreting ambiguity, weighing trade-offs the model wasn't trained on, applying institutional context, making a call in a novel situation. Judgment touchpoints are valuable and should be designed accordingly: more time, more context, fewer interruptions.

2. Accountability. The human is being asked to own the outcome. They may agree with the system's decision and not change anything — but their name is on it, and they are answerable for it. Accountability touchpoints don't necessarily need the human to change anything, but they do need the human to be capable of overriding, with the information required to do so.

3. Exception handling. The system has hit a case it cannot or should not handle alone — low confidence, novel pattern, regulatory threshold, customer request. The human's job is to deal with the case the system passed up. Exception touchpoints are the operational backbone of an AI-native workflow.

Notice what is not on this list. "Quality check on every output" is not on the list — that is augmentation thinking. "Human approval as a regulatory requirement" can sit under Accountability, but only if the human actually has the means to challenge the decision. "Human in the loop because we don't trust the model yet" is fine as a transitional design but should have a stop condition: when do we stop reviewing every output?

The decision rights matrix

For any redesigned workflow, build a decision rights matrix that lists each material decision and answers four questions:

1. Who decides by default? (System or human)
2. What confidence threshold triggers escalation? (If system: under what conditions does this decision get routed to a human?)
3. Who is accountable for the outcome? (Named role, not just "the team")
4. What is the override interface? (How does the accountable human change the system's decision, with what audit trail?)

A simplified example for KYC:

This is what decision rights look like in practice. Notice three things: first, the system handles most of the routine work by default; second, escalation criteria are explicit and machine-checkable; third, every decision has a named human owner, even when the system is the default actor.

The override rate is the metric that matters

Once a decision rights matrix is in place, the metric you should be watching most closely is the override rate — the percentage of system-generated decisions that the accountable human changes on review.

This metric is informative in both directions:

• Override rate too low (e.g., < 1%) = the human review is probably a rubber stamp. Either the model is performing well and the review is unnecessary friction, or the human doesn't have time/incentive to actually challenge the system. Either way, something needs to change — automate the step away or invest in the review.
• Override rate too high (e.g., > 20%) = the model isn't ready for the role you've put it in. Pull it back, retrain, narrow the scope. It's making decisions humans don't agree with.
• Override rate in a healthy band (e.g., 3–10%) = humans are meaningfully engaged, the model is mostly right, and the disagreements are flowing back into the training data.

The override rate is also one of the strongest signals you can give a regulator that your governance is real. "We monitor the override rate and we track it over time" is a much more credible posture than "we have a human in the loop."

The accountability problem

In a traditional workflow, accountability is implicit: the person who did the work owns the outcome. In an AI-native workflow, that link breaks. The system did the work. Who owns the outcome?

The wrong answers we hear most often:

• "The model owns it." Models cannot be accountable. Regulators don't accept this. Customers don't accept this. Don't say this.
• "The vendor owns it." Vendors take none of this risk in their contracts. Don't say this either.
• "The AI team owns it." The AI team is too far from the business decision to be the right owner.
• "Nobody, really." This is what most organisations actually have, and it's the most dangerous answer.

The right answer is that a named role in the business owns the decision, regardless of whether the system or a human made the call. That role's job description must explicitly include: monitoring the system's behaviour in their domain, owning the outcomes of decisions the system makes, intervening when the system is wrong, and having the authority to pause or roll back the system if needed.

This is a real change from the traditional org chart. Most operations directors have never been told that "monitor the model in your domain" is part of their job. In an AI-native operating model, it is.

Designing the override interface

The mechanics of how a human overrides the system matter more than people realise. A bad override interface will quietly turn even the best-designed accountability model into a rubber stamp.

Some principles we use:

• The default action should require effort. If "approve" is one click and "override" is a 4-step process, you have built a rubber stamp. Make override the easier path when the system is uncertain.
• Surface the system's reasoning. The reviewer should be able to see why the system made the call — the inputs, the confidence, the comparable cases. Without this, the human is just guessing.
• Capture the override reason in structured form. Free-text alone is not enough — the reasons must be aggregable so the model can learn from them. Pre-defined override categories with optional free text are usually the right pattern.
• Track the time-to-decide. If reviewers are spending less than a few seconds on each case, it's a rubber stamp regardless of what the interface looks like.
• Audit the audit. Periodically review overrides to check whether the human's reasoning was sound. This is the only way to catch systematic rubber-stamping before a regulator does.

What regulators expect

In financial services, the regulatory landscape on AI decision rights is converging on three broad expectations.

Named accountability. EU AI Act, PRA SS1/23 (model risk management), FCA SYSC, and DORA all assume that material AI decisions have a named human owner. Anonymous "the system did it" is not a defensible posture.

Effective override capability. It is not enough to have a human in the loop. The human must have the means to actually challenge and override the system. Rubber-stamp loops have started to attract supervisory criticism.

Auditability of decisions and overrides. Every material AI decision and every human override of one must be reconstructable after the fact. This pushes back into the data layer (Module 5) and into governance design (Module 6).

If your decision rights matrix can answer all three of these for every material decision in your workflow, you are in a defensible position. If it can't, you have governance work to do before you scale.

What's next

In Module 5 we'll go deep on the data layer — why it is the constraint that determines everything in enterprise AI, and what an action-data architecture looks like in practice.