Part 2 fixed the routing. Cases now reach the human exception owner because of what they are: reversible or not, large or small, first refund or sixth. The AI agent's confidence no longer decides who sees what. Now watch what happens to the person at the end of that queue.
Week one. A human exception owner handles the refund exceptions. Forty cases reach her each day. She reads the trigger, opens the order history, checks the device links, and decides. A case takes her about four minutes. She changes the AI agent's proposed answer on roughly one case in fifteen.
Then a fraud ring gets through on refunds just under the magnitude threshold. Finance escalates. Someone lowers the threshold from €250 to €80 to be safe. Her queue goes from forty cases a day to a hundred and fifty.
Week three. She opens a case, sees the AI agent's proposed answer at the top, glances at the trigger line, and clicks approve. A case takes her twenty seconds. She has not changed an answer in nine days. Her team lead praises the drop in handle time in the Monday meeting.
Nothing in this story is laziness. Of the last few hundred cases she opened, the AI agent was right on almost all of them. Approving without reading was the correct answer for nearly every click. She is doing the job the queue taught her.
The button is faster than reading
Human-factors research has studied this for decades, mostly where a miss costs a life.
The first is the prevalence effect. In 2005, Jeremy Wolfe, Todd Horowitz and Naomi Kenner had people search mock baggage X-rays for weapons (Nature, 2005). When a target was in half the bags, searchers missed about 7% of targets. When a target was in 1% of bags, they missed about 30%. The searchers learned that the answer is usually "nothing" and quit looking sooner.
Experience does not protect you. In 2013, Karla Evans, Robyn Birdwell and Wolfe tested radiologists who read mammograms for a living (PLoS ONE, 2013). Under normal screening conditions, where cancer is rare, they missed 30% of the cancers. Shown the same cancers in a session where half the cases were positive, they missed 12%. The doctors and the images were the same. Only the rate changed.
The second finding is alert fatigue. A 2006 review by Heleen van der Sijs and colleagues found that physicians override 49% to 96% of drug safety alerts (JAMIA, 2006). The volume taught them to click through.
The third is that training does not fix it. Raja Parasuraman and Dietrich Manzey reviewed the research on automation bias, the habit of following a machine's suggestion instead of checking it (Human Factors, 2010). They found it in novices and experts alike, and found that training and instructions did not prevent it.
Put the three together and week three stops looking like a discipline problem. A reminder to "please read every case" is an instruction, and instructions do not prevent automation bias. The queue's rate of real problems is doing the teaching.
The share of cases that need a human decides whether the human reads. Every case you add that does not need her lowers that share.
In the loop, on the loop, a signature
The decline has three stages. None of them shows up on an operations dashboard, because every metric on it improves.
The third stage is worse than having no reviewer. With no reviewer, everyone knows the AI agent decided alone, and finance and the parameter owner watch it with suspicion. With a signature, every case carries a human name and the audit trail says reviewed. When a customer complains, the answer is "a human approved it", and the investigation stops there. The signature takes the blame and adds no judgment.
Regulators have already named this risk. Article 14 of the EU AI Act requires that the people who oversee a high-risk AI system stay aware of "automation bias", the tendency to over-rely on the system's output. Most refund and billing AI agents will not count as high-risk under that law. Still, a log full of approve clicks is weak evidence that a human was aware of anything.
Send fewer cases
The instinct after an incident is to widen the queue. Lower a threshold, add a trigger, route more to humans. It feels like adding safety. It adds volume, and volume lowers the share of cases where the human should change the answer. That share decides whether anyone reads.
I call that share the yield of the queue: the percentage of flagged cases where the human exception owner should change the AI agent's answer. Her wide queue and a narrow queue look like this.
On paper the wide queue is safer, because it contains all six risky cases. In practice it is read like week three, and the research above suggests a reviewer at 4% yield misses far more than one case in six. The narrow queue gives up one risky case on purpose so that the human actually sees the other five.
The case the narrow queue gives up goes to what Part 2 already built: the random audit sample, read after the fact by someone who is not working a queue.
Where the floor sits is a judgment call, and it belongs to the parameter owner. I would start at 10% and adjust it from what the audit sample shows. A change rate near zero has two causes: the queue is too wide, or the human stopped reading. The change rate alone cannot tell you which.
Make reading the fast path
A narrow queue makes reading worth it. On its own it does not make reading happen. The review screen decides whether reading is also the easy option, and the KPIs decide whether anyone can tell. Four changes help.
The blind decision gives you the most useful comparison in the queue. Each case now carries two answers: one from the AI agent, and one from a human who did not see it. Measure the overlap and the deviation between them. The deviation is the change rate from the yield rule, measured cleanly, because the human answer is no longer a copy of the proposal. Break it down by trigger and by direction. If humans decline where the AI agent refunds on Pattern cases, the AI agent is missing what the history shows. If humans refund where the AI agent declines on Value-at-risk cases, the AI agent is pricing your best customers' goodwill too low. Each split is a specific instruction to the parameter owner. When the two answers differ, the seeded cases and the audit sample tell you which side was right.
Seeded cases do two jobs. They turn "was this case read?" into a number per person and week, which separates a wide queue from a reviewer who stopped reading. They also raise the yield the reviewer experiences, which is the prevalence fix the screening research points to. A human who finds something every day keeps looking.
What this costs you
First, you will auto-resolve cases a human used to see, and some of them will be wrong. The yield rule trades a visible review that nobody reads for a risk you measure through the audit sample. That trade needs the parameter owner's name on it, in writing, before the next incident.
Second, each case gets heavier. Thirty cases at 17% yield are harder work than a hundred and fifty at 4%. This queue needs your most experienced people, and a job grade that says so.
What comes next
The queue is now small, and someone reads it. One problem is left inside the cases themselves.
The triggers from Part 2 protect different things. Magnitude and pattern protect money. Value at risk protects the relationship. When both fire on the same case, they point in opposite directions: decline to protect the margin, or refund to keep a customer worth ten times the charge. Today the human exception owner resolves that conflict in her head. The colleague on the next shift resolves it differently. Nobody sees the trade, and nobody owns it.
Part 4 makes that trade visible. It gives money and experience to two managers who are built to disagree, and sends a case to a human only when they do. It is also the cleanest way to keep the queue small.
That is Part 4.