Accountable for AI—but able to intervene?
Four questions for leaders who need human oversight to work before consequences become difficult to reverse
Karina Carlos
Before an AI-assisted workflow goes live, ask the person expected to oversee it to walk through a decision they might need to challenge. Which information would they examine? What could they change? How would they prevent the action from proceeding while a material concern remained unresolved?
Then ask them to demonstrate the route using the permissions, workload and response channels they will actually have. A demonstration may reveal a gap that the approval diagram conceals: the person can recognize a problem, yet cannot get the right evidence or reach someone authorized to act before the workflow moves on.
For leaders, that gap deserves attention before deployment. Accountability becomes difficult to defend when the organization cannot explain what the accountable person could reasonably have done at the moment that mattered.
What the moral crumple zone makes visible
Madeleine Clare Elish introduced the concept of the moral crumple zone to describe responsibility falling on a human with limited control over an automated system. In his July 2026 California Management Review Insight, Harsh Doshi applies this concern to AI agents and organizational design.
Doshi calls for accountable ownership with authority to change an agent’s mandate, circuit breakers and organizational learning after incidents. His proposals already connect responsibility with intervention. My question is how leaders can verify that this connection holds during an actual decision.
Authority in the conditions of use
Within Human Authority, I examine the relationship between judgment, legitimate standing and the conditions that let people act. Competence and formal assignment matter, but the relevant question concerns their exercise in context. The public paper Why a Human in the Loop Is Not Enough already draws on Elish in discussing accountability and scapegoating.
The Access Problem adds a distinction worth preserving. Difficulty deploying judgment under pressure, difficulty making a rationale understandable, and lack of institutional authorization require different responses. A missing permission cannot be repaired by asking someone to appear more confident. Nor does providing a stop button establish that its holder can evaluate when using it is justified.
I would therefore examine a workflow through a concrete episode of disagreement. Choose a plausible case that challenges the system’s recommendation. Follow the concern from recognition to a decision, including the time spent waiting. Record where judgment can still change what happens.
The decision behind the rejection email
In my fictional story Who Can Stop the Rejection Emails?, product lead Clara examines what a hiring reviewer can actually do. Eva can approve a shortlist, but that approval also queues rejection emails for people outside it. Reviewing omitted applications requires another permission; pausing the batch requires an administrator. Clara does not know how long escalation would take.
That unknown matters. An approval step tells us little about whether an exclusion can still be contested. For a real workflow, I would ask the team to locate the last point at which a justified challenge could preserve the applicant’s opportunity for consideration. Then I would use four questions to examine what the organization has made possible.
Four questions to examine the workflow
1. Can the reviewer obtain the evidence needed to challenge the decision?
Start with what the person must judge. Does the screen show enough to assess the relevant criterion, or only the result the system has selected for approval? Can the reviewer identify consequential exclusions, missing inputs and unresolved uncertainty?
Ask for a demonstration with an ambiguous case. Record which evidence was available, what had to be requested and whether it arrived while the decision remained open. Access should be proportionate to the role and protect personal information; unrestricted visibility is neither necessary nor appropriate.
2. Which intervention is legitimate for this role?
Specify the action the person may take and the conditions that justify it. Some roles can suspend execution. Others must document the concern and bring it to a person with the relevant jurisdiction.
Check whether the stated route works with ordinary permissions and whether a justified intervention is supported by management. Asking a conscientious employee to borrow administrator access, bypass safeguards or rely on a personal favor would expose a design problem. The route should remain usable when that helpful colleague is absent.
3. Can a pause or escalation take effect before the consequence?
Identify the action after which correction becomes materially harder: a message sent, an opportunity closed, a resource committed. Measure the interval between raising a concern and the system actually changing course. Include acknowledgment, review and execution of the decision.
A ticket marked received may leave the underlying action untouched. Test what is held while review is pending, who can release it and how that release is recorded. The useful evidence is an observed change in the workflow before the relevant deadline.
4. What happens if the route does not respond in time?
Rehearse an unavailable decision-maker, a failed notification or a disputed handoff. Who takes responsibility for the unresolved case? What is the permitted fallback? Does execution continue by default, and has anyone explicitly accepted the risks of that default?
The appropriate response depends on the consequences of both acting and waiting. It may involve a bounded hold, a narrower automated action or an authorized alternative process. Agree it in advance and test it. A reviewer should not have to invent emergency powers to compensate for a route that was never made reliable.
What leaders should be able to show
These questions are a proposed design review, not a validated assessment instrument. Their value lies in the evidence they ask a team to produce: an identifiable decision, a reason for challenge, a legitimate intervention and a record of what happened before the consequence became harder to reverse.
A successful rehearsal would establish something bounded about that workflow under those conditions. It would still need to be revisited when the model, permissions, staffing or stakes changed. A failed rehearsal would identify work for the people able to change the design.
Before making someone answerable for an AI-assisted decision, ask the organization to show how that person’s judgment can affect its course. Responsibility should be discussed alongside the evidence, authority and time available to act. That is where the conversation about human oversight becomes concrete.


Comments