A credit line moves from $10,000 to $4,000 in under a second. Reversing that decision takes forty-five days. In the space between those two numbers, a customer's mortgage rate lock falls through — and nobody on the governance committee did anything wrong.
I want to walk through a case I have seen in slightly different form at more than one financial institution, presented here as a composite so no client or system is identifiable. It is the clearest illustration I know of a pattern I keep coming back to in my other writing on AI governance: the gap between how fast a model can act and how fast the people supervising it can catch up.
The Decision That Moved Faster Than the Committee
A regional retail bank runs a model that adjusts consumer credit limits monthly, based on spending patterns and risk signals. It touches roughly 40,000 accounts a cycle, raising some limits and cutting others. The bank has what most people would call real governance around it: a Model Risk Committee that meets monthly, samples fifty decisions per cycle, and has a documented escalation path for disputes.
In one cycle, the model flags a customer as elevated risk. The trigger is a single large purchase — a wedding expense — that the model reads as the start of a debt spiral rather than a one-time event. It cuts the customer's credit line from $10,000 to $4,000. The decision executes instantly, and under the bank's own bureau-reporting SLA, it is reported to the credit bureau within 48 hours. That leg of the pipeline is fast by design; bureau-reporting compliance has its own deadline, and the bank meets it.
The Model Risk Committee reviews the case three weeks later, in its normal monthly cycle. It gets the call right: this was a single event, not a trend, and the model's confidence score on the decision was 58 percent — below the bank's own 70 percent threshold for auto-execution. Below that line, the case should have routed to a human reviewer. It didn't, because of a gap in how the threshold was configured. The committee votes to reverse.
But a bureau-reported limit cut is not a database field you edit. Undoing it means filing a formal dispute with the credit bureau, which carries a standard 45-day resolution window. In the meantime, the customer — who never knew any of this happened, because nothing about it was disclosed to them in real time — applies for a mortgage rate lock. The application is declined. Their credit utilization ratio, thanks to the sudden limit cut, spiked overnight.
Why "We Review It Monthly" Is Not Governance
Here is the part that I think gets missed in most governance conversations: the committee in this example did not fail at its job. It reviewed the decision. It correctly diagnosed the error. It voted to fix it. Every box that a well-run oversight committee is supposed to check, it checked.
It still failed the customer, because a review that happens after a decision has executed, reported, and caused downstream harm is not a control — it is documentation. An audit trail tells you what happened and why. A control changes what happens before it becomes permanent. The Model Risk Committee produced an excellent audit trail. It was never structurally able to function as a control, because by the time it convened, the point of no return was three weeks in the past.
This is not a story about a badly run committee. It is a story about a well-run committee sitting on top of a badly designed clock.
The Two Clocks Every AI Decision Runs On
Every automated decision of consequence runs on two clocks at once. There is the execution clock — how long it takes the system to act and for that action to become binding, reported, or otherwise hard to unwind. And there is the review clock — how long it takes a human process to notice, evaluate, and intervene. Governance only functions where the review clock is faster than the execution clock. Where it isn't, the review clock is measuring something that has already become history.
Once you see the pattern, it shows up well outside banking. An automated pricing engine can reprice thousands of SKUs overnight off a demand signal that turns out to be a data glitch, while the pricing committee that would catch it meets weekly. A content moderation system can suspend a business account in seconds over a misread policy violation, cutting off its primary sales channel, while the appeals queue runs on a multi-day backlog. An automated hiring screen filters out candidates before a human recruiter ever sees the requisition, and the audit of its outcomes — if it happens — lands a quarter later, after every candidate in that cycle has already moved on.
In each case, the organization can point to a real governance process. In each case, that process operates entirely downstream of the point where the decision became irreversible. The process is not wrong. It is simply solving a problem — was this decision correct — after the moment when correctness stopped being able to change the outcome.
Five Questions That Tell You If a Control Actually Changes Anything
In my work advising organizations on AI governance through Webspot, my AI strategy firm in Beirut, I have found that most controls sound rigorous in a policy document and turn out, on inspection, to be timing failures dressed up as oversight. Five questions tend to surface the gap quickly, and they are questions any executive can ask in a single meeting, without needing to see the model itself:
- Does the review happen before the decision executes, or after it has already taken effect?
- Is the decision still reversible by the time the review happens, or only before the review would have started?
- What downstream systems — bureaus, customers, partners, other automated processes — get notified or act on this decision before your governance process even sees the case?
- Who specifically owns closing the gap between how fast the system executes and how fast the review process runs — and is that gap tracked anywhere, or simply accepted as the cost of scale?
- What is your worst-case time-to-reverse a wrong decision, and does that number beat your worst-case damage window — the time it takes for real harm to become locked in?
If the honest answer to the first question is "after," the rest of the list mostly answers itself. A control that only ever operates after execution is not badly designed oversight — it is a different thing entirely, wearing oversight's clothing.
Building a Governance Clock That Beats the Decision Clock
The fix is not more committees, more sampling, or more frequent meetings. A monthly review that becomes a weekly review is still a review clock, just a slightly faster one — it does not change the fundamental relationship if the execution clock is measured in seconds. The fix has to change where governance sits relative to execution, not just how often it convenes.
Three moves do most of the work. First, build pre-execution gates for decisions with high blast radius and low reversibility — where a single automated action affects many people at once, or is slow to undo once it fires. Second, make confidence thresholds actually route decisions rather than merely log them. In the case above, the 70 percent threshold existed and was even calculated correctly; the failure was that dropping below it did not reliably send the case to a human. A threshold that logs a low-confidence decision without stopping it is not a control — it is a footnote. Third, treat time-to-reverse as a governance KPI with the same weight as time-to-review. Most organizations report proudly on how many decisions they audited and how quickly. Very few can tell you how long it actually takes to undo a mistake in their highest-risk decision category — and that second number is the one that determines whether a customer's mortgage closes on time.
None of this requires slower AI. It requires governance that is honest about which of its controls run ahead of the decision and which ones only run alongside its consequences. A committee that meets monthly to review what already happened is worth having — it produces real insight, and it should keep meeting. It is just not, on its own, governance for anything that can become irreversible in seconds. That is why every AI e-mployee I put into production through BrianServes, where I deploy autonomous AI e-mployees under a written role charter, carries its reversal path and escalation route in that charter rather than in a committee's minutes. For those decisions, the only clock that matters is the one that runs before the action, not the one that runs after it.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
