Human Decision Rights in AI-Native Workflows

The textbook way to open an AI design workshop is with a capability question: what can the model do, how accurate is it, which of these steps can it take off our hands. It is a reasonable question and the wrong one to start with, because it produces designs that demo beautifully and then stall in a control review nobody scheduled.

The question that decides whether an AI-native workflow can actually run is much older than the technology, and every enterprise already answers it a hundred times a day for its human staff: who is allowed to decide what?

Eighteen years of enterprise systems work — approval matrices, bank mandates, the documents that decide who may release a payment — taught me that the hard part of a design is almost never the processing. It is the authority: who may raise it, who may approve it, who may release it, and what happens when those turn out to be the same person. AI does not retire that question. It changes who is standing where the answer used to be.

Break the workflow into verbs

Decision rights cannot be granted to a process. "Supplier onboarding" is not something anyone can hold authority over; it is a container. Rights attach to actions, so the first move is to take the workflow apart into its verbs.

Most enterprise work reduces to a short and surprisingly stable list:

• Read — retrieve, open, look at.
• Extract — pull a value out of an unstructured source.
• Classify — assign a category, a counterparty, a cost centre, a risk band.
• Recommend — propose an action, with reasoning attached.
• Approve — accept a proposal so that it may proceed.
• Execute — do the thing: post, send, release, pay.
• Override a control — proceed despite a rule that said stop.
• Change policy — move the rule itself.

Written out like that, most of the answers stop being controversial. Nobody seriously argues that a model should raise a limit. The arguments happen because the verbs were never separated: "the agent handles onboarding" bundles read, extract, classify, recommend, approve and execute into one sentence, and the approval hides comfortably inside it. Separating them is the same discipline as taking the workflow apart in the first place, run down a different axis.

The rights matrix

This is the default I would start a design from. Every row is negotiable. None of them should be left implicit.

Two rows carry the whole design. Recommend is where nearly all of the value sits — an afternoon of assembly done before anyone sits down. Approve is where the risk sits, and it is the row that quietly moves when a programme is behind schedule.

"

An AI system may be allowed to prepare any decision in the enterprise. What it is allowed to decide is a much shorter list, and someone's name is on every line of it.

The condition column is the actual work

The first two columns are easy to agree in a room. The fourth is where a design becomes real, and it holds four different questions.

Materiality. The obvious one, and the one people reduce to a currency amount. Value is a decent proxy and an incomplete one: a small credit note to the wrong customer is cheap, the same action against a regulator is not. Set thresholds on consequence, then express them in money where money is a fair stand-in.

Reversibility. Not "can it be undone" but how far it has travelled and what undoing costs. A draft is free to reverse, a classification is cheap, an email to a counterparty is out of the building the moment it is sent, and a released payment is a phone call to a bank at best.

Repetition. The condition that genuinely differs between a human decision right and a machine one, and the one most often left out. A human approver making the same misjudgement four hundred times before anyone notices is not a realistic scenario; an automated step doing exactly that before lunch is an ordinary Tuesday. So rights need bounding twice: per case and per period. Value per item, value per day, count per hour, and a stopping condition that does not depend on someone watching a dashboard.

Accountability, and to whom. Every consequential decision runs to a person, and that person answers to someone else — a committee, a board, an auditor, a regulator. "The system decided" is not an answer any of those accept. If you cannot name who is answerable for a row, that row is not ready.

You are not starting from a blank page

Here is the part most writing on AI governance skips, and it decides whether a design survives its first control review.

Decision rights already exist in your organisation, written down and signed, and more carefully reasoned than anything a workshop will produce in an afternoon. The delegation of authority. The approval matrix. Segregation of duties. Four-eyes release. Bank mandates and signature limits. Spending authority by grade. System roles and entitlements. Most of it exists because something went wrong once and someone made sure it could not happen the same way twice.

So this is mostly a mapping exercise. For each verb, find the document that already governs it. If the machine is going to recommend, whose preparation work is it doing, and does that person's scope cover the data it reads? If it is going to execute, under whose authority, and does that authority exist in something a person signed? This is where the design meets the plumbing of identity and permissions in the existing landscape, and the two have to give the same answer.

Skipping it produces two failure modes. The parallel regime: a new AI governance policy with its own risk tiers, review board and thresholds, standing beside a delegation of authority it never references — six months in there are two answers to who may approve a payment, and the auditor finds both. And the quieter, commoner silent widening: no document changed, but a service account with broad access now does what a person with narrower access used to do, and the effective authority of the workflow rose without anyone deciding that it should.

A practical test: if the design cannot be described as a set of amendments to documents that already exist, it has not been mapped onto the control environment. It has been laid on top of it.

Segregation of duties deserves its own line, because it breaks in a new way. An agent that both prepares a payment and releases it is the four-eyes violation wearing a costume, and most people spot that one. The subtler version is the proposed fix: split the duty between two instances, one proposing and one checking. Segregation between two humans works because they are different people with different incentives and blind spots. Two instances of the same system are not two people. They share a model, a prompt and a failure mode. That is one opinion, asked twice.

When it is confident and wrong

An experienced person who is unsure usually signals it. They hedge, they ask a colleague, they escalate, they write "I think" in the email. That signal does an enormous amount of unacknowledged work in every control environment I have seen — it is how borderline items find their way to the person who should see them.

A model's output does not carry that signal reliably. It can be fluent, well-structured, internally consistent, complete, and wrong — and the qualities that make an output easy to approve can appear regardless of whether the content is correct. The presentation is not evidence about the answer.

So never grant a right on observed accuracy alone. Grant it on what a wrong answer costs and how quickly it is caught: two steps performing identically deserve different rights when one produces a label that can be reclassified and the other produces a payment.

And put the check where the error would be visible. For an extraction, the source document beside the extracted value. For a recommendation, the evidence and — the part people omit — the evidence pointing the other way. A check that consists of re-reading the model's own conclusion is not a check. It is a second opinion from the same source.

"Human in the loop" is a position, not a control

The phrase has become a reassurance, and it reassures far more than it should. Being in the loop describes where someone stands. A control has a trigger, an action, evidence that it happened, and an owner. A review step becomes a control only when three things are true at once.

The human has the evidence. Enough to disagree, not merely enough to agree. If the only artefact on the screen is the model's conclusion, the reviewer can approve it or delay it, but they cannot check it.

The human has the time. Review capacity is a finite budget. Take a step generating four hundred recommendations a day with a reviewer who has two hours to give it — purely as an illustration — and each item gets about eighteen seconds. That is a design input, not an unfortunate discovery after go-live. Either the output is checkable in eighteen seconds, or the volume is split by risk so most items are never individually reviewed and a few get genuine attention, or the review is fictional.

Saying no has to work. Rejecting should be as easy as accepting, the reason should have somewhere to go, and it should change what happens next rather than merely delaying it. Where accepting is one click and disagreeing means starting a conversation with another team, the design has already chosen its outcome.

Designing against the rubber stamp

Rubber-stamping is not a people problem, and training rarely fixes it. It is the predictable output of asking someone to approve more items than they can examine, with less evidence than they need, in a screen where agreeing is frictionless. So design against it on purpose.

Match the volume to the attention. Route by risk rather than uniformly: the material and the irreversible get a real decision, the rest get sampled. Uniform routing is fair and useless.

Show the reason to disagree. Every recommendation should carry what would make it wrong — the source that was missing, the assumption applied, the item that did not match the pattern. A recommendation that argues only its own case has been optimised for approval, not for a decision.

Instrument the approval itself. Approval rate, time spent per item, and how often the human changed anything. If nearly everything is approved in a couple of seconds, the workflow is no longer augmentation. It is autonomy that nobody signed for, running under a person's name — the worst of both designs, with neither real oversight nor a boundary with an owner. Then sample what was approved, the way a quality function samples anything else.

Most of these rights get exercised in one place: the queue where the items that did not go straight through are waiting. That is why the exception path is where a decision-rights design either works or is quietly abandoned.

Write it down, one row per verb

The artefact this produces is small: a table, one row per action, four columns, and a named human on every consequential row. It fits on a page, and it is worth arguing about before anything is built — after go-live, each of those rows is a change request with a control review attached.

The test I would apply to any AI-native design, at any stage: point at a consequential action and ask three questions. Who decided? On what evidence? Who answers for it? If the first answer is "the system" and the third is a pause, the design is not finished — whatever the model can do. There is more of this method in the AI workflow design notes.

See also the anatomy of an AI-native enterprise workflow and designing the exception path.