Decision Rights in an AI-Native Operating Model

In a traditional operating model, decision rights are mostly implicit. The person who does the work owns the outcome. The manager approves exceptions. The committee handles material decisions. Authority is delegated by org chart, by policy, and by tradition. The system works because everyone understands their place in it without having to write it down.

In an AI-native operating model, this stops working.

When a system generates the default output for most decisions and a human is asked to review, override, or accept — who actually owns the outcome? The model? The team that built it? The vendor? The operator who could have intervened? The compliance function that signed off the design? Most enterprises do not have a clear answer, which means the de facto answer is "nobody, really." That is the most dangerous answer in regulated industries, and it is the one supervisors are starting to push back on hard.

This post is about how to redraw decision rights for an AI-native world: the three categories of human intervention, the override mechanics that matter, the accountability problem and how to solve it, and what regulators are converging on. It is written for COOs, CROs, and Chief Transformation Officers in financial services and other regulated environments who have realised that the role design for AI is harder than the technology.

The three reasons humans stay in the loop

Start by being precise about why a human is in the loop in any given AI workflow. In our engagements, we use a three-category framework. If a human touchpoint cannot be put 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 the call in a novel situation. Judgment touchpoints are valuable and rare. They should be designed for: more time, more context, fewer interruptions, and the system should actively prepare the human for the decision rather than dumping it on them.

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 the decision, but they need the human to be capable of overriding it, with the information required to do so meaningfully.

3. Exception handling. The system has hit a case it cannot or should not handle alone — low confidence, novel pattern, regulatory threshold, customer escalation. The human's job is to deal with the case the system passed up. This is the operational core of an AI-native workflow and the role most operations teams are about to spend most of their time in.

Notice what is not on this list. "Quality check on every output" is not on the list — that is augmentation thinking dressed up as governance. "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 a fine transitional design, but it should have a stop condition: when do we stop reviewing every output?

Every human touchpoint in your workflow should map to one of these three. If a touchpoint exists for any other reason — habit, comfort, performative governance — it is friction without value.

The decision rights matrix

For every redesigned workflow, build a decision rights matrix. It is the most useful single artefact for AI governance in regulated industries, and the one most enterprises don't have. The matrix lists each material decision in the workflow 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 route to a human?)
3. Who is accountable for the outcome? (Named role, not "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 a KYC workflow:

This is what decision rights look like in practice. Three things to notice. First, the system handles most of the routine work by default. Second, escalation criteria are explicit and machine-checkable rather than left to ad-hoc judgment. Third, every decision has a named human owner, even when the system is the default actor — and that name is a role title, not "the team."

The matrix is also the artefact you put in front of a regulator. It shows that you have thought explicitly about who decides what, how the system and human interact, and where accountability sits. That is a substantially more credible posture than "we have a human in the loop."

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 (under 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 challenge the system. Either way, something needs to change — automate the step away or invest in making the review meaningful.
• Override rate too high (over 20%). The model isn't ready for the role you've put it in. Pull it back, retrain, narrow the scope. It is making decisions the humans don't agree with.
• Override rate in a healthy band (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." It shows that the human review is being measured for effectiveness, not just for existence.

The accountability problem

In a traditional workflow, accountability is implicit in the work itself. 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. Auditors don't accept this. Don't say this.
• "The vendor owns it." Vendors take none of this risk in their contracts. Read your contract. 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. They built the model. They didn't deploy it into the business context that makes it consequential.
• "Nobody, really." This is the de facto answer in most enterprises, and it is the most dangerous. It surfaces during incidents, when the search for an accountable owner produces a series of finger-points and a quiet realisation that the org chart never assigned the responsibility.

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 operations director role. 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 — and it has to be backed by the training, the time allocation, and the authority to act on what the monitoring reveals.

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. A few principles we use:

The default action should require effort. If "approve" is one click and "override" is a four-step process, you have built a rubber stamp. Make override the easier path when the system is uncertain. Make approval the easier path when the system is confident. The interface should reflect the model's confidence in real time.

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, the relevant policy. Without this, the human is guessing rather than reviewing.

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. The aggregated override patterns are some of the most valuable signal in the entire workflow.

Track the time-to-decide. If reviewers are spending less than a few seconds on each case, it is a rubber stamp regardless of what the interface looks like. Time-to-decide is a leading indicator of review quality.

Audit the audit. Periodically sample overrides to check whether the human's reasoning was sound. This is the only way to catch systematic rubber-stamping before a regulator does — and it should be done by second line, not by the first-line team that owns the decision.

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. Your governance has to be able to point at a specific role and say "this person owns it."

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, with the information and authority to do so. Rubber-stamp loops have started to attract supervisory criticism, particularly in credit decisioning and customer-facing AI under FCA Consumer Duty.

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 (decision logs with full lineage) and into the operating model (named owners who can be asked to explain a specific case).

If your decision rights matrix can answer all three of these for every material decision in your workflows, you are in a defensible position. If it can't, you have governance debt that will be expensive to retire under pressure.

Where to start

Decision rights is one of those topics that sounds abstract until you actually try to operationalise it inside a real workflow, at which point it becomes the most concrete and politically demanding part of AI enablement. Three concrete starting points:

1. Pick one priority workflow and build the decision rights matrix. Don't try to do the whole portfolio. Pick the one that matters most and that is closest to deployment. Building the matrix forces the conversation about who actually decides what, which will surface the gaps faster than any abstract policy work.

2. Score your existing initiatives against the diagnostic. The AI Enablement Maturity Diagnostic has a dedicated pillar for operating model and decision rights — five questions that give you a structural read on where you stand across the function.

3. If you are leading the work, take the AI Enablement for Operations Leaders course. Module 4 of the course goes deep on decision rights, with worked examples in financial services, and Module 6 covers the role design implications.

For a fuller picture of how decision rights fit into the broader AI enablement work — alongside workflow redesign, the data layer, governance, and the operating model — see the pillar essay What AI Enablement Actually Means and our AI Enablement service, where decision rights is one of the five core pillars we redesign in every engagement.

The institutions that figure out decision rights early will deploy AI faster, more confidently, and into use cases their competitors are afraid to touch. The ones that don't will spend the next five years explaining to supervisors why nobody owned the decision when it went wrong. The work is harder than the technology, but it is the work that determines whether AI compounds for you or not.