All writing

AI governance

Governance as a clearance system

Oversight is real when the conditions for approval are published in advance and a denial tells the team exactly what to do next.

An AI governance board can become theater. The policy is written, the meeting happens, and none of it changes what ships. A charter and a standing meeting establish a forum. Published criteria, specific decisions, and a workable appeals path are what make that forum an authority.

A clearance system is the better model. Teams know what a proposed use must demonstrate, reviewers have the authority to evaluate it, and every decision names the evidence behind the answer. Nothing crosses without meeting a known standard, and what meets the standard crosses without friction.

Two ways oversight breaks down

Boards fail in one of two directions. A board that approves everything governs nothing; it exists to produce a signature. A board that holds everything teaches the business to route around it, and governance becomes the thing teams hide work from. Either way, the board is no longer where authority lives.

Start with the board’s decision rights. Give it dedicated review capacity rather than borrowed attention, and publish criteria teams can evaluate themselves before they submit. A principle like “maintain human oversight” has to become a requirement: who checks what, at which point, and how that check is recorded.

The NIST AI Risk Management Framework calls for documented roles and responsibilities and enough context for an initial go/no-go decision. A clearance system turns that guidance into a practical question for each submission: what must this use show before it proceeds?

What this looks like in practice

Consider a request to let an AI agent file vendor-onboarding records into a finance system. The board has already published what a write to a system of record must demonstrate: a preview of the exact record, the inputs it relied on, and the constraints it checked. A named reviewer must verify the one field the agent is known to get wrong. The log must show what was checked, not only who clicked.

The first submission lacks the named check. The denial says so, names the missing control, and sets a two-week resubmission window. The team fixes a specific deficiency and resubmits. It clears. Nothing about that took a quarter.

The same criteria that make a refusal defensible make an approval fast. That is the point.

Five parts of an actionable denial

When a request does not meet the standard, the response states:

  1. The criterion that was not met, quoted from the published requirement.
  2. The evidence reviewed, so the team can see the gap the board saw.
  3. What would satisfy the criterion: the check, control, or evidence that turns the answer to yes.
  4. Who hears an appeal, and how long they have.
  5. When to resubmit, so a no is a scheduled next step rather than an open-ended stop.

If a denial cannot be written in this form, the board does not yet have a criterion. It has an opinion. Fix the standard before asking the team to fix the submission.

The test is simple: can a team that was denied explain what happened and what to do next? When it can, governance is doing work. When it cannot, the board is producing theater, however well attended.