Two small pilots go in front of the same monthly review at once. One is a tool that drafts the weekly shift-handover note from the day's logs — useful, and wrong in the way a draft is wrong: someone rereads it against the source before it goes out. The other watches the end of a production line and recommends whether a finished part should ship. Both land on the same twelve-item checklist, in front of the same two-hour meeting, because that is the only review anyone has built. The board has one slot a month and five items to clear before lunch, so the drafting tool waits six weeks behind systems that actually needed the scrutiny, and the part-inspection tool gets the same forty minutes as everything else on the agenda. Nobody in that room thinks the two carry the same risk. The process does, because it was built with one setting.
Why we build it this way
The instinct, once a company decides to take AI governance seriously, is to write one strong process and run every use case through it. That reads as rigour. It behaves as something else: a review has a fixed amount of attention in any given week, and a single process spends that attention evenly across everything that arrives, regardless of what is actually at stake. Spent evenly, it is thorough about the draft and thin on the part that ships.
The fix usually tried is to make the one process heavier — more documents, more signatures, a longer meeting. That does not move the attention to where it is needed; it just makes the drafting tool wait longer too, while the inspection system still gets its forty minutes, now preceded by more paperwork that nobody reads closely because there is more of it.
What a use case is allowed to do should be judged by what happens when it is wrong, not by whether it involves AI. A drafting assistant that is wrong gets reread. A system with a say in whether a part passes is wrong in a way that can leave a plant, or a customer, holding something nobody actually looked at. Those two cases do not belong on the same clock.
A review that gives everything the same amount of attention does not examine anything enough — it is thorough about the draft and fast about the part that ships.
How it works, roughly
Each use case gets a tier before anyone builds it, decided by what happens if it is wrong:
- Whether a mistake is caught before anyone acts on it, or only after
- Whether what it touches is reversible — a redrafted email, or a part already welded into an assembly
- Whether getting it wrong exposes the business to a regulator, a customer audit, or just an annoyed colleague
Documentation, testing and who has to sign off all scale with that tier, not with how much anyone likes the project. A drafting assistant ships once someone has used it for a week and found it useful; nobody needs to convene a board for that. A system with a say in whether a part passes carries a named person who signs before it goes live, a record of what it was tested against, and a rule that it recommends rather than decides — the pass or fail stays with the inspector, every time, not only when the system itself is unsure. When that person overrides it, the override sits next to the recommendation in the record, not quietly in place of it.
A year in, a low-stakes tool ships in days because nothing about it needed a committee's calendar, and the one system actually deciding what ships gets the scrutiny that decision deserves, before anyone trusts it. The record of which tier a use case got, and why, stays inside your own building — not in whoever happened to be in the room that month.
See how a use case gets tiered →