Designing Decision Authority for Business Workflows

A workflow system may be able to read a supplier’s terms, compare them with policy and prepare a response. That does not automatically give it authority to accept a new commercial commitment.

To define decision authority, start with one specific decision. State who may recommend, approve, commit, stop or escalate—and under what conditions. The six-stage method below is a practical proposal, not a validated standard. Its starting distinction is simple: permissions determine what a system can access; authority determines what it may commit.

Separate access from authority#

A technical permission answers: can the system access the contract, customer record or payment tool? Business authority answers: may it accept a proposed change, make a promise or release funds?

Those boundaries can be misaligned. A system may have the right documents but no clear mandate to act on them. Or a workflow may technically allow an action without specifying who owns the business decision when evidence is incomplete.

For a particular decision, distinguish four things:

• Access: What information and tools can the system use?
• Action: May it summarise, recommend, prepare, send or commit?
• Authority: Who owns the decision, and what limits apply?
• Escalation: What happens when those limits are reached?

This is an operating distinction, not a formal definition established by external research. It helps turn “Is the AI allowed to do this?” into questions a workflow owner can answer.

Define the decision and its limits#

Choose one consequential decision in a real process. Avoid a broad goal such as “automate procurement”. Narrow it to a decision a person could make: for example, whether to accept a supplier’s proposed change to a delivery commitment.

First, name the people and systems involved. Identify who recommends, who approves and who makes the final commitment. If responsibilities overlap, specify who owns the decision.

Next, define what the system may do routinely, what requires approval and what it must not do. Include exceptions such as conflicting contract terms or missing evidence. List its information and tool access separately from its authorised actions: access to a contract does not, by itself, permit the system to vary it.

The National Institute of Standards and Technology’s AI Risk Management Framework (AI RMF 1.0) calls for documented roles and communication lines, and for policies that distinguish human and AI oversight responsibilities. Its actions are not a checklist or necessarily ordered steps. The framework supports making roles explicit, but does not validate this article’s six-stage method or guarantee that a particular control will prevent errors. NIST, AI Risk Management Framework 1.0, “AI RMF Core”

An authority statement might read:

The system may compare proposed delivery changes with approved terms and recommend an action. It may not accept a change to the delivery commitment. Conflicting terms, missing evidence or an unapproved exception must go to the procurement owner.

This identifies the action reserved for a person and the conditions that trigger review.

Test a routine case and an exception#

Before expanding what the system may do, test the boundary with an ordinary case and an exception. This will not prove the system reliable; it can reveal whether the rules make the decision boundary clear.

Consider an illustrative supplier workflow:

• If the proposed delivery date matches the approved order, the system may prepare a routine confirmation within the existing process.
• If the supplier asks to change a material commitment, the system may summarise the request and relevant terms, but the procurement owner must approve any acceptance.
• If the contract and order appear to conflict, defer the decision and escalate it. Other work may continue only if it is independently authorised.

For the exception, compare the preferred action with a credible alternative. The system might recommend accepting the change because the latest email appears to confirm it. But if the signed contract says something different, deferring acceptance may be safer. Record the evidence for each view, why one was chosen and who has authority to resolve the conflict.

A deliberate escalation is different from a workflow failure. Check whether the named owner receives enough information and has authority to act. NIST’s AI RMF describes assigning responsibilities and mechanisms to supersede, disengage or deactivate AI systems whose outcomes conflict with intended use. That is a governance reference for defining a stop route, not a claim that every workflow needs the same mechanism. NIST, AI Risk Management Framework 1.0, “AI RMF Core”

Record what the next owner needs#

A record should help someone reconstruct what happened, not merely show that a step was completed. Keep it proportionate to the decision: a routine action may need little documentation; a disputed commitment needs enough detail for review.

Review before changing authority#

Review what happened: what was accepted, what remains uncertain, who needs to act and what should change. An exception may reveal a missing rule, an unclear owner or evidence that the workflow cannot reliably distinguish routine cases from consequential ones.

Escalations, overrides, unresolved exceptions and cases returned for rework are possible measures to examine. They are not reported results, and fewer escalations do not necessarily mean better decisions.

Change the boundary in response to a specific problem: clarify an exception, restrict a permitted action, improve the evidence available to the decision-maker or assign a different escalation owner. Another approval is not automatically the answer; it can add delay without clarifying who is responsible.