AI Governance Inside a Company

5 min read · updated August 3, 2026

An internal AI review board has exactly two failure modes: it approves everything, in which case it is theatre, or it becomes the reason nothing ships, in which case teams route around it and it is worse than theatre. Both are avoidable, and the avoidance is mostly about latency.

What a board is for

Not to decide whether AI is a good idea, and not to re-litigate a technology choice per project. A board exists to do three things that nobody inside a single team can do.

Give one answer. Two teams asking the same question about the same data class must get the same answer, or the policy is not a policy. Consistency is the whole product.
See the aggregate. Six individually reasonable projects can add up to a data flow nobody would have approved as a whole, or to a dependency on one supplier that nobody chose deliberately. Only a central view notices.
Keep a record. A decision log with reasons is what makes the next decision fast and what answers an auditor. This is also what makes reviews cheap over time: most questions have been answered, and the answer is findable.

Note that catching problems is not on the list. A board that reads documents is a poor detector; the detection work belongs in the review and the monitoring. The board decides, records and generalises.

Who sits on it follows from those three jobs, and the answer is smaller than most organisations reach for. You need someone who can speak for legal and data protection, someone who can speak for security, and someone who understands what the systems actually do well enough to tell a real control from a described one. Three or four people who can decide beats nine who can comment: a body large enough that no individual feels responsible for the answer produces minutes rather than decisions, and it cannot meet weekly, which is the property that matters most.

The tiering rule

Four yes/no questions, answered by the requesting team, in about two minutes. The tier is a function of the answers rather than an assessment, which is what allows the fast path to exist at all.

Q1  Does an output reach someone outside the building team
    without a human reading it first?
Q2  Does it process RESTRICTED data (personal, customer,
    regulated, confidential-by-contract)?
Q3  Can it take an action — send, write, pay, schedule, call
    a tool — rather than only produce text?
Q4  Does it inform a decision ABOUT a person: hiring, credit,
    eligibility, discipline, health, access?

Q4 = yes                        -> TIER 3, always
two or more of Q1-Q3 = yes      -> TIER 3
exactly one of Q1-Q3 = yes      -> TIER 2
none                            -> TIER 1

Q4 is a standalone escalation because decisions about people carry obligations the other three do not — including, in several jurisdictions, a duty to explain the decision — and because the risk-tier logic in the EU AI Act turns on categories of this kind rather than on how clever the system is.

The rule is deliberately crude. A crude rule that a team can apply without asking produces consistent tiering; a nuanced one produces a conversation about tiering, which is the queue you were trying to avoid, held one step earlier.

What each tier produces

Tier	Description
1 — register	A form: what it does, which tool, which data class, who owns it. No review, no waiting, effective immediately. The register exists so the aggregate view is possible and so the same thing can be re-tiered if it changes. Most internal experimentation should land here.
2 — async review	The data-flow page, the named owner, and the risk rows the team has already identified. Reviewed asynchronously by one reviewer against the published pattern list. No meeting. A decision within the published response time.
3 — full review	Everything in tier 2, plus: the evaluation result on a frozen set, the monitoring plan (what is measured, what alerts, who is on call), the human-review design, the rollback mechanism, and a stated review date. Discussed in a meeting, decided in writing, recorded with reasons.

One rule holds the tiers together: the tier is a property of the deployment, not of the project. The same model doing the same task is tier 1 in an internal draft tool and tier 3 the day somebody wires its output to an outbound email. Re-tier on change, and make “we changed one of the four answers” a thing teams know they must report.

The proportions are the health check. If almost everything is landing in tier 3, the tiering questions are too broad or the organisation is attempting only high-stakes work, and either diagnosis is actionable. If almost nothing is, either the register is not being filled in or the questions are being answered optimistically — which you can test by picking three tier 1 registrations at random and asking the four questions yourself. That spot check, done quarterly, is worth more than any amount of process documentation, because it is the only thing that verifies the input the whole system depends on.

The response time is the product

A governance function should publish and measure its own latency the way any service does, because latency is the variable that decides whether teams use it or evade it.

TIER 1   immediate, self-service
TIER 2   decision within 5 working days of a complete
         submission
TIER 3   slot at the next scheduled session; sessions are
         weekly, not monthly

PUBLISHED MONTHLY
  median and p90 time to decision, per tier
  number of submissions returned as incomplete
  number of exceptions granted, and for what

The p90 matters more than the median, exactly as it does for a service: the projects that wait three weeks are the ones that teach everyone else to avoid the process. And the “returned as incomplete” count is the board’s own quality metric — a high number means the submission template is unclear, which is the board’s problem rather than the requester’s.

What should not happen when the response time is missed is automatic approval. That converts a delay into an uncontrolled risk. The right escalation is that a missed target is an incident for the board — reported, with a cause — and that a persistent breach is a resourcing decision made by whoever set the target.

Pre-approved patterns

The single highest-leverage thing a board can build. A pattern is a named combination — vendor, data class, control set, deployment shape — that has already been reviewed and approved. Anything matching a pattern is a registration rather than a review.

PATTERN "internal-draft"
  vendor        <approved provider, enterprise terms>
  data          INTERNAL only, no RESTRICTED
  controls      no tool access; output shown to the author
                only; per-key spend cap; standard logging
                with redaction at capture
  deployment    staff-facing, human edits before any use
  status        approved 2026-04-11, review 2027-04-11

Matching a pattern -> tier 1 registration.
Deviating from one -> the deviation is what gets reviewed,
                      not the whole project.

The last line is the trick. Reviewing only the delta turns the fifth project through a known shape into a twenty-minute exercise, which is what makes the board sustainable as the number of projects grows.

Two things keep patterns honest. Each carries a review date, and each is invalidated by a change in what it depends on — new sub-processor, changed retention default, a model with new capabilities such as tool use. And every approved tier 2 or tier 3 project should end with the question “is this a new pattern?”, because a governance function that is not converting decisions into patterns is re-answering the same question forever. Feed the residual risks from each decision straight into the risk register rather than leaving them in the minutes, and keep the decision log somewhere an auditor could actually be shown.