AI Decision Authority and Human Approval

A fictional freight forwarder, Northline, redesigned its shipment-exception desk around an AI agent. When a truck is delayed or a port closes, the agent drafts customer notices, offers goodwill credits, rebooks loads onto other carriers, and prepares carrier payments. The operations vice president, burned by an early mistake, set one rule: a person approves every action. Three reviewers handled the queue and it worked for weeks. Then a storm closed two ports, exception volume more than doubled, and approvals fell an hour behind. Carrier pickup cutoffs passed while rebooking requests waited. Reviewers began approving in batches of twenty without opening the details. The control existed on paper and no longer checked anything.

The rule failed for a reason that has nothing to do with the model. It treated every action as equally dangerous, so the reviewers’ limited attention was spread across notices that cost nothing to correct and payment changes that cost a great deal. This article shows how to assign authority by action instead of by system: how to judge consequence and reversibility, which autonomy levels exist, how to size approval capacity so that waiting does not defeat the purpose, what the system should do when no one answers or when it must be stopped, and who answers for each decision. Northline is invented, and every figure below is hypothetical and computed for the example.

Authority belongs to the action, not the system

“Is the AI trustworthy enough to run this process?” is a question that cannot be answered, because one process contains actions with very different consequences. The unit of decision is the single kind of action the system can take: send this message, issue this credit, move this load, release this payment. For each one, two properties set how much human control is worth paying for. Consequence is how much harm a wrong action does, to a customer, to the budget, to a regulatory position. Reversibility is how much of that harm can be undone, and how fast. The two-way door distinction captures part of this, and it separates three things that are easy to blur: changing a decision, restoring a system, and undoing effects the decision already produced. Canceling a rebooking before pickup is a reversal. Recalling a payment that has settled to another party depends on that party and the bank, not on Northline.

The agent’s actions also differ in how far one mistake can spread, which is the idea behind blast radius. A single wrong credit affects one customer. A wrong rule applied to every delayed shipment on a route affects all of them at once. Limits on amount, count, and scope turn a potentially large consequence into a bounded one, and bounds are what make autonomy defensible. The limits must be enforced where the action executes rather than requested in a prompt; the article on agent tool execution explains why a limit stated only to the model is a suggestion.

Northline’s team lists the agent’s actions and rates each on those properties. The right-hand column records the decisions the following sections reach.

Action	If wrong	Reversibility	Bound enforced in the tool	Authority
Send a delay notice from an approved template	A confused customer	A correction can be sent; the first message cannot be unsent	Template only; no free text about fees or liability	Agent acts; sample review
Issue a goodwill credit	Up to \$50 lost per credit	Treated as unrecoverable once applied	\$50 per credit, 200 credits per day: at most \$10,000 per day	Agent acts; sample review
Rebook a load onto another carrier	Higher freight cost or missed service	Cancelable until pickup; committed afterward	Alternate carriers from the contracted list; cost increase capped per load	Agent acts after a veto window
Change a carrier’s remittance details or release a carrier payment	Money sent to the wrong party	Depends on recovery from a third party; may be lost	None short of a prohibition	Person approves

When a review is worth its price

Review has a cost, and the cost can be compared with the loss it prevents. Suppose a reviewer takes three minutes per item at a fully loaded \$45 per hour, so each review costs \$2.25. A review pays for itself when the expected loss it prevents is larger: the error rate, times the loss from an uncaught error, times the share of errors that review actually catches. All three inputs below are hypothetical.

For credits, assume 2% of the agent’s credits are wrong, the average wrong credit costs \$30, and a reviewer catches 80% of the wrong ones. Reviewing one credit prevents 0.02 × \$30 × 0.8 = \$0.48, far less than the \$2.25 it costs. The error rate would have to reach 9.4% (2.25 ÷ 24) before reviewing each credit saved money. For payment changes, assume 0.5% are wrong, an uncaught error costs \$18,000, and review catches 60%. Each review then prevents 0.005 × \$18,000 × 0.6 = \$54, twenty-four times its cost; the break-even error rate is about 0.02%. The same reviewers and the same three minutes are worth spending on one class and wasted on the other.

This comparison leaves things out, and the omissions matter. It ignores the cost of waiting, treated below. It prices a loss as money, while a wrong notice about a customer’s rights may carry a legal or relationship cost with no clean price. It also assumes the stated error rate is known, which at the start of a deployment it is not. The calculation is a way to see why uniform review is wasteful and to challenge a reflexive “approve everything”; it does not replace judgment about harms that money does not capture.

Autonomy is a ladder, and each action sits on a rung

Automation is not a switch between manual and automatic. Parasuraman, Sheridan, and Wickens describe automation as applying to four kinds of function (acquiring information, analyzing it, selecting a decision, and implementing the action) and at any level from fully manual to fully automatic within each. The consequence for a leader is practical: a system can analyze at a high level and act at a low one. The agent may read every shipment record, rank carriers, and recommend a rebooking with no one reviewing the analysis, while the final step of changing a payee still requires a person. Granting autonomy should name which function is being released, not just that “the AI handles it.”

For the action step, four arrangements cover what Northline needs, ordered by how much a person stands between the decision and its effect.

1. Recommend. The agent proposes and a person carries out the action. The person remains the actor, so this suits cases where the agent’s output is an input to someone else’s judgment.
2. Act on approval. The agent prepares the exact action and waits. Nothing happens until an authorized person says yes, and silence means no.
3. Act unless vetoed. The agent announces the action and performs it after a fixed window unless a person stops it. Silence means yes.
4. Act within limits, reviewed afterward. The agent acts immediately inside enforced bounds. People inspect a sample of actions and every case that hit a limit or an exception.

The rungs differ in what a person can still prevent. Approval and recommendation can stop a harmful action before it happens. A veto window can stop it only if someone is watching and the window is long enough to notice. Review after the fact cannot prevent the first error at all; it finds and corrects errors and limits how many follow. That is why it is appropriate when the bound is tight and the loss is small, and inappropriate for an action whose first mistake is the expensive one.

A rung is also not a promise that a person is exercising judgment. The glossary entry on human oversight makes the point that an approval click is weak evidence when the reviewer cannot see the source, has no time to check, or cannot refuse without penalty. For high-risk AI systems, Article 14 of the European Union’s AI Act turns part of this into a requirement: oversight measures must let the people assigned to the system understand its capacities and limits, stay aware of the tendency to over-rely on its output (automation bias), correctly interpret what it produces, decide to disregard or override it, and interrupt it. Northline’s freight desk is not such a system, but the list is a good test of any approval design. If the reviewer cannot do those things, the rung is labeled approval and operates as act-and-notify.

With the ladder in hand, Northline assigns the right-hand column of the table. Notices and credits sit on the fourth rung because their consequences are small and bounded. Rebooking sits on the third, because waiting for approval costs more than an occasional wrong rebooking and the action is cancelable until pickup. Payment changes sit on the second. The approval protocol itself, including what a reviewer must see, how long an approval stays valid, and what record it leaves, is the subject of Human Approval and Escalation in AI Workflows. The leader’s decision is which rung each action gets and what evidence would move it.

Approval has a latency, and the queue sets it

An approval gate adds time between the agent’s proposal and the effect. The glossary entry on decision latency defines the measure: elapsed time from a ready proposal to the decision reaching the requester, split into queue time, information time, deliberation time, and communication time. For approvals of agent actions, queue time dominates once reviewers are busy, and it grows sharply as utilization approaches one.

Northline’s numbers show the shape. On a normal day 40 exceptions arrive per hour, each review takes three minutes (20 reviews per hour per reviewer), and three reviewers can clear 60 per hour. The queue model used here, a standard multi-server queue with random arrivals and exponentially distributed review times, gives the mean wait before a review starts.

Arrivals per hour needing approval	Reviewers	Utilization	Mean wait before review starts
10 (the redesigned scope)	2	25%	0.2 minutes
40 (approve everything, normal day)	3	67%	1.3 minutes
50	3	83%	4.2 minutes
55	3	92%	10.2 minutes
60 or more	3	100% or more	The queue grows without limit

A normal day looks fine, which is why approve-everything survives pilots. Going from 40 to 55 arrivals per hour, a 38% increase, multiplies the mean wait by almost eight. Real arrivals are burstier than the model assumes, so the waits at a given utilization are optimistic, and the average hides a longer tail.

The storm shows the other behavior. Assume arrivals of 90 per hour for two hours against a capacity of 60. The backlog grows by 30 per hour and reaches 60 items. The last arrival waits about an hour (60 items at 60 per hour), and because normal arrivals continue at 40 per hour, the net clearing rate is only 20 per hour, so the backlog takes three more hours to drain. During those five hours every rebooking decision is late. Staffing more reviewers is one response, but a surge is exactly when people are least available, and a control whose adequacy depends on extra staff on the worst day will be weakest then.

The structural response is to reduce what needs approval and to decide in advance what a late approval means. Under the redesigned authority map, 10 of the 40 hourly exceptions need approval, which is 80 per day over an eight-hour shift. Of the remaining 240 autonomous actions, a 10% sample is 24 reviews, or 72 minutes of reviewer time, a small fraction of a three-person desk. The staffing question changes from “can three people keep up with everything” to “will two people reliably answer 10 requests an hour, including on a storm day,” and the answer to that question can be tested.

Waiting also needs a rule. Each action with an approval gate should carry a deadline tied to the value of the decision, such as a carrier cutoff, and a defined outcome when the deadline passes. That outcome is the next topic, because it is a safety decision rather than a scheduling one.

What the system does when nobody answers, and when someone says stop

A fail-safe design chooses, for each action, which direction is safe when the normal control path is unavailable. The choice is not the same everywhere. For the payment change, the safe direction is to do nothing: an unanswered approval expires, the payee stays as it was, and the request is escalated. That behavior fails closed. For rebooking, doing nothing is the expensive outcome, because the load misses its cutoff. The third-rung design fails open on purpose: the rebooking proceeds if no one vetoes it in the window, and the cost cap and cancelation-before-pickup bound the damage of a wrong decision. Failing open is acceptable here only because the bound was designed first. An action that fails open without one is a decision to accept whatever the agent proposes.

Each action’s timeout behavior should be written next to its authority level, along with who is told when a request expires. A timeout that silently converts “no one answered” into “approved” is a different control from the one that was approved, and so is one that silently converts it into “denied” without telling the requester.

The second half of fail-safe design is stopping. In August 2012, according to the SEC’s later charges, Knight Capital’s automated equity router sent more than 4 million orders into the market while trying to fill 212 customer orders, and the firm lost more than \$460 million in the first 45 minutes of trading. The SEC found that the firm lacked adequate controls over financial risk, code deployment, and incident response, among other areas. No human approval of individual orders was feasible at that speed. What was missing were the limits that bound a runaway process and a practiced way to halt it. Northline’s agent operates at a slower pace, but the lesson applies to any autonomy above the second rung: the control that matters is the one that caps the total effect and stops the process.

For high-risk AI systems, Article 14 requires that people be able to interrupt the system through a “stop button” or similar procedure that brings it to a halt in a safe state. Two details determine whether such a control works. First, it must take effect where the action happens. The kill switch entry shows how a switch read only when a run begins leaves in-flight runs free to complete their actions, while a switch checked by the tool executor just before each action stops them. Second, a halted agent leaves a gap. If the agent stops, the exception work returns to people. The safe state is only safe if the desk can absorb that work or the work can wait. An agent halted on a storm day, with a desk sized for 10 approvals an hour, is a different incident from the one the stop button was meant to prevent. Fallback capacity belongs in the same plan as the stop procedure and should be exercised, not assumed.

Who answers for each decision

In Moffatt v. Air Canada (2024), a British Columbia tribunal considered an airline’s website chatbot that gave a customer wrong information about bereavement fares. The airline argued it could not be held responsible for what the chatbot said. The tribunal rejected that position, treating the chatbot as part of the airline’s website and finding the airline did not take reasonable care to ensure the chatbot was accurate. The ruling is one tribunal’s decision, but it illustrates a planning assumption for executives: delegating an action to software does not delegate the answerability for it. Buying the model, the agent framework, or the whole workflow from a supplier moves some work and some contractual remedies, but the customer still deals with the company.

The practical need is a named owner for each action class. The glossary entry on responsibility and accountability separates who performs assigned work from who must answer for the decision. An engineer can be responsible for testing the agent’s rebooking logic while a service owner is accountable for letting it act. Accountability without power is a formality, so the owner needs the authority to impose conditions, change a limit, move the action to a different rung, and halt it. That is a decision right, and like any decision right it should state the class of question, the scope, the limit of what the holder may decide alone, and where an unresolved question goes. For Northline the head of customer operations owns credits and notices, the head of network operations owns rebooking, and the finance controller owns payment changes. The controller, not the AI team, decides whether the payment gate may be relaxed.

Escalation is the part that organizations tend to leave unnamed. Each approval or exception path needs three things written down: who decides when the primary reviewer cannot or will not, how long that person has, and what happens at the end of that time. A reviewer who may not reject without penalty will approve; a reviewer who is rewarded only for queue speed will batch. Escalation should therefore also cover disagreement: the reviewer’s right to reject or to send the case up must be real, and the managers who receive rejections should be measured on the quality of the decision rather than the approval rate. Every approval and every autonomous action should leave a record that shows what was proposed, what the reviewer saw, who decided, and what the system did, so that a later question about a single customer can be answered.

Moving an action up or down the ladder

The levels are starting assignments, and the evidence to move them should be agreed before launch. An action earns more autonomy when its sampled error rate stays below a threshold the owner set, over a volume large enough to mean something. At 2% errors, a 10% sample of 240 daily credits finds about half an error per day, so detecting a rate change takes weeks of data, not a day; the owner should decide how long the evidence window is and accept that the sample will lag a sudden change. That lag is the reason for hard bounds. The bound caps the damage while the sample catches up.

Autonomy comes back down faster than it went up. An incident, a change of model or prompt, a new carrier, a change in contract terms, or a drift in the sample’s error rate should each return the affected action to a lower rung until the owner has seen new evidence. Even without a trigger, a periodic review is useful because the condition that justified a rung may have quietly changed. The residual risk that remains at each rung, after the limits and reviews are in place, belongs to the owner to accept or reduce; the entry on residual risk describes how to record what remains and who decided it was acceptable.

After the storm, Northline replaced the single rule with the authority map. Notices and credits run on bounded autonomy with a daily sample and a weekly review of limit hits. Rebooking runs with a ten-minute veto window ahead of the carrier cutoff, on a contracted carrier list and a per-load cost cap. Payment changes wait for the controller’s team, expire as denied after a fixed time with a notice to the requester, and escalate to the controller’s deputy. The kill switch is checked by the tool executor before each action, and the desk runs a quarterly drill with the agent switched off to confirm that two reviewers and the on-call lead can clear a day’s exceptions at a pace the carrier cutoffs allow. The old rule promised that a person saw everything. The new arrangement promises something narrower that can be verified: the right people see the actions that matter in time to act, the rest are bounded and sampled, and when the system must stop, it can.

References

• EU Artificial Intelligence Act, Article 14: Human oversight.
• U.S. Securities and Exchange Commission, press release on the Knight Capital market access charges (2013).
• McCarthy Tétrault, Moffatt v. Air Canada: misrepresentation by an AI chatbot, on the 2024 BCCRT 149 decision.
• Parasuraman, Sheridan, and Wickens, A model for types and levels of human interaction with automation, IEEE Transactions on Systems, Man, and Cybernetics, 2000.