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.
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 no