Most conversations about artificial intelligence and risk stop at the moment of approval. A model is vetted, a vendor is reviewed, a committee signs off, and the assumption — rarely stated but widely held — is that the hard work is now done. Dr. Jonah Tebaa's recent writing on AI governance takes direct aim at that assumption, arguing that the sign-off is not the finish line of governance but merely its opening move. What happens in the minutes after an automated system misbehaves, he suggests, matters at least as much as what happened before it was switched on.
A scenario built to expose a gap
To make the point concrete, Tebaa constructs an illustrative scenario rather than citing a named client: a mid-size online retailer whose automated refund engine encounters a bug in a payment webhook and begins issuing duplicate refunds. In his telling, 214 orders are refunded three times over, and the only structural safeguard in place is a nightly reconciliation run scheduled for 11 PM — nine hours away. The story is hypothetical, but its mechanics are familiar to anyone who has worked around production systems: early signals are dismissed as noise, a pattern eventually gets noticed, and then a strange kind of paralysis sets in. Someone has to ask who is actually responsible for this system, and for a period of minutes, nobody has a confident answer.
In Tebaa's account, the scenario resolves in thirteen minutes, once a manager verbally authorizes pausing the webhook. By his estimate, the bulk of the financial exposure in the scenario — a hypothetical $340,000 in duplicate payouts — accrues in the final six minutes, after the problem has already been identified but before anyone with the standing authority to act can be found. The detail he keeps returning to is not the bug itself but the lag between detection and authority. The engineer capable of pausing the system was reachable early; the permission to do so was not.
Two different questions, one governance conversation
Tebaa's broader argument rests on separating two questions that current AI governance practice tends to collapse into one. The first is a pre-deployment question: should this system be allowed to run at all? The second is an operational question that only becomes relevant once the first has already been answered yes: given that the system is running and has just done something wrong, who owns the next ten minutes? Risk committees, vendor due diligence, and approval chains are built almost entirely to answer the first question. Very few organizations, in his assessment, have built anything comparable to answer the second.
He draws a useful parallel to fields that solved a version of this problem long ago. Software engineering teams built incident-response discipline and on-call rotations precisely because they recognized that a system passing its launch review would still, eventually, fail in production — and that when it did, ambiguity about ownership was itself a source of damage. He also points to existing regulatory language that gestures at the same distinction without fully closing it: the NIST AI Risk Management Framework separates a "Govern" function from a "Manage" function, with the latter explicitly concerned with detecting and responding to problems in systems that are already live, not certifying them before launch. The EU AI Act's post-market monitoring obligations point at a similar seam — approval is treated as a single moment, while monitoring and response are meant to be continuous. Tebaa's contribution is less to introduce a new framework than to insist that organizations actually staff the second half of it, rather than treating it as a formality attached to the first.
What Tebaa says has to exist before the incident does
The practical core of his argument is a short list of things he believes need to be in place before anything goes wrong, not improvised once it has:
- A named, reachable owner. Not a shared inbox, not a committee, but one specific person whose contact details can be found faster than a message thread can be searched.
- Pre-granted authority to pause or roll back. Assigned to a role in advance, so that the person capable of stopping a system is also the person allowed to. Tebaa argues that this gap — between technical capability and standing authority — is where most of the damage in his scenario accumulates.
- An automatic, timestamped log written at the moment of detection. He is skeptical of timelines reconstructed afterward from chat logs and email threads, noting that a record assembled two days later is a record of what people remember, not of what happened.
He adds a fourth recommendation that is less a control than a habit: rehearsal. A tabletop exercise, run with a clock and the actual named owner in the room, using a plausible failure mode — a pricing error, a duplicated transaction, an output that should never have reached a customer — costs little and, in his view, reveals gaps that no policy document will surface on its own.
An argument aimed at practice, not paperwork
What distinguishes Tebaa's position from a general call for "better AI risk management" is its specificity about timing. He is not arguing against pre-deployment review; he treats it as necessary but, on its own, insufficient — describing it, in effect, as governance that stops at the door. His interest is in the interval that begins the moment something goes wrong, and in the observation that most organizations have built elaborate machinery for the first interval and almost nothing for the second. For leadership teams evaluating their own AI deployments, his framing offers a simple diagnostic question, one that a policy binder cannot answer on its own: if something breaks in the next hour, does a specific person already know it is theirs to fix, and do they already have permission to fix it?