An engineer needed a plain-language answer out of a supplier's spec sheet by four o'clock. The company's own tool for that — the one with logging, the one legal had signed off on — needed an access request routed through two managers, and the queue was running at a week and a half. He did not have a week and a half; he had three hours and a quote to finish. He opened a free tool on his own laptop, pasted in the page, got his answer, and sent the quote on time. He did not think of it as breaking a rule. He thought of it as Tuesday.
Nobody asked him about it afterward, because nobody was looking there. The governance dashboard for that quarter showed zero exceptions on the sanctioned tool — a clean, reportable number, same as every quarter before it. The number was true. It was also the wrong number. It measured a system almost nobody under deadline was actually using, not what the engineers in that office did with whatever was in front of them.
Why we build it this way
Most AI governance gets built the way a single locked door gets built: one queue, one review, applied the same way to a drafting assistant and a system that decides whether a part passes. It reads as responsible on the page. Put it in front of a real deadline and it produces exactly the scene above — people go around the slow door and keep working, and the only thing the slow door measures afterward is how few people chose to use it.
The failure is not that people cut corners under pressure. They always will, with or without an AI system anywhere near the decision. The failure is building a control that assumes they will not, and then believing its own dashboard when it quietly confirms they did not. Governance that gets routed around is worse than no governance at all — it replaces a gap you knew about with a false sense that the gap is closed.
So the test we hold a control to is not whether it reads strict in the policy document. It is whether the sanctioned path is also the fast one.
A dashboard with zero exceptions on it is not proof that nothing went wrong. It is proof that nobody went near the door you were watching.
How it works, roughly
Making the safe path the fast one is mostly a matter of not treating every request the same:
- Each use case gets its tier — how much review it earns — decided before anyone builds it, so a routine request is not waiting behind one that actually matters
- Each tier carries its own promised turnaround, and the light tier clears the same day, not the same week
- Using the sanctioned route does the logging automatically, so taking it is not extra paperwork stacked on top of the fast answer
- What people actually reach for, officially or otherwise, gets watched — so a pattern of going around the queue shows up as a defect in the queue, not as a clean quarter
When a tier's turnaround starts slipping past what people can realistically wait for, that is treated as a fault in the control, not a discipline problem in the team. Whoever is accountable for governance resets the turnaround, or the review itself — not the wording of the policy that nobody was reading anyway at four o'clock on a Tuesday.
A year in, what a company has is not a thicker policy binder. It is a record of which path people actually took under real deadlines, tier by tier, and a standing habit of shortening the slow one instead of policing the workaround. A person still decides how much oversight each use case earns, and that decision stays where it was made — inside the company's own building, answerable to whoever has to defend it, not to a dashboard that only counts what came through the front door.
See how we build governance to be used →