Governance without blocking delivery

Why governance gets resented

Ask an engineer what AI governance means and you will often get a description of paperwork. That reaction is earned. Most of what engineers have encountered under that name was designed to produce evidence that a process happened, not to reduce the chance of something going wrong.

Those are different goals and they produce different artifacts. Evidence-oriented governance asks you to fill in a form. Risk- oriented governance asks what could go wrong here and what would catch it. The first can be satisfied by a document nobody reads. The second cannot.

The tell is whether the process has ever changed an outcome. If no model has been delayed, modified or stopped by your review process, it is not a control. It is a receipt.

The review-gate anti-pattern

The most common design: every model goes to a committee before it ships. It is appealing because it is simple to describe and easy to point at. It fails in three predictable ways.

It creates a queue. The committee meets fortnightly. A model finished the day after a meeting waits two weeks. Teams learn to schedule around it, which means bundling changes into bigger, riskier releases — the opposite of what you wanted.

It reviews the wrong things equally. A recommendation tweak and a credit decisioning model get the same slot and the same attention. The committee's finite attention is spent uniformly on non-uniform risk.

It makes review adversarial. When the gate is the only interaction, the governance function is the thing standing between a team and shipping. People stop bringing you problems early, which is exactly when you could help.

Tier by actual risk

The single change that makes governance survivable: stop treating all systems the same. Most of what a team ships needs nothing beyond a register entry.

The objection is always that tiering lets something slip through on a wrong classification. It can. But the alternative — uniform heavy review — reliably produces shallow review of everything, plus a backlog. A wrong classification is a bounded, fixable error. A process everyone routes around is not.

Make the classification itself cheap and reversible: one question at the start of work, revisited if the purpose changes.

The question that does the work

You can get most of the way to a tier with a single question: if this system is confidently wrong about one person, what happens to them?

If the answer is that they see a slightly worse recommendation, it is minimal risk. If the answer is that they wait longer for a reply, it is limited. If the answer is that they do not get the loan, the interview or the appointment, it is high, and the rest of the process follows from there.

This phrasing works better than reading tier definitions, because it puts a person at the centre rather than a technology category. It is also a question a product manager can answer without an engineer present, which is what lets classification happen at the start of work instead of the end.

What to automate, what needs a human

The useful split is not by importance. It is by whether the question has a determinate answer.

   AUTOMATE (has a right answer)      HUMAN (requires judgement)
   ─────────────────────────────      ──────────────────────────
   Is it in the register?             Is this the right use case?
   Does it have an owner?             Is the training data fair here?
   Did evals run and pass?            Can a reviewer realistically
   Is a model card present?             override this in context?
   Is the version logged?             What happens to the person
   Is PII in the training set?          when we get it wrong?
            

Everything in the left column belongs in CI, where it costs seconds and never forgets. Everything in the right column needs a conversation, and putting it in a checklist produces theatre: a tick-box marked "bias assessed" with nothing behind it.

This split also fixes the adversarial problem. When the mechanical checks are automated, the human review is no longer about compliance box-ticking. It is a design conversation, which is a thing engineers will actually come to you for.

What good looks like at three sizes

A team of five, one AI feature

A file in the repository listing what the model does, who owns it, and what you checked. A CI job that fails if that file is missing. That is the whole programme, and it is sufficient. Do not buy anything.

Thirty engineers, a handful of models

A real register, generated from deploy manifests. Tiered review with the mechanical checks in CI. One person who owns the process part-time — not a department. Written classification criteria, so the tier is not decided by whoever is asked.

A few hundred engineers, models across several products

Now you need someone whose job this is, and probably a tool. But the shape is the same: automated checks at the boundary, human review reserved for the systems that can hurt someone, and a register that maintains itself.

The failure mode at this size is building the platform first. Teams buy a governance suite, configure it for eighteen months, and still cannot say how many high-risk models they run. The register comes first; the tool is an optimisation.

How you know it is working

Three signals, none of which is a completed checklist.

Teams come to you before they build. Not because policy requires it, but because the conversation is useful. If the first time you hear about a model is at review, you have a gate however you have described it.

Something has been stopped or changed. Over a year, a working process should have altered at least one launch. Zero interventions means either you are reviewing the wrong things or the review is not real.

You can answer a question in an afternoon. When a customer's security team asks what models touch their data, the answer should take hours, not a fortnight of interviews. That is the return on the register, and it is usually what pays for the whole programme in commercial terms.