What controls does a board need before scaling AI

The risk committee asked for an AI data policy and had it in three days. What it still doesn't have, six months later, is an answer to the question that actually matters: what happens when the control says no and the business decides to proceed anyway.

Carlos Andrés Ramírez · 2026-08-25

The risk committee asked for an AI data policy and had it in three days. What it still doesn't have, six months later, is an answer to the question that actually matters: what happens when the control says no and the business decides to proceed anyway.

I have watched the same pattern play out in more than one boardroom. Someone asks for the AI controls before approving a scale up, and within weeks a thick folder appears: a responsible use policy, a bias checklist, a privacy clause reviewed by legal. All correct, all hygiene, and none of it answers the one thing an auditor will actually ask: who has the authority to stop a use case that is already approved, at what threshold, and what happens if the business pushes back.

The gap is not a missing control. It is treating controls as a stack of documents signed once, instead of a decision mechanism that activates every time something drifts from what was approved. A policy nobody enforces is a PDF with good intentions.

The symptom

What controls does a company need before scaling AI?

The answer circulating today is a hygiene list: ethical principles, a risk checklist, an advisory committee. Frameworks like ISO/IEC 42001 or the NIST AI RMF help structure that list, but neither one tells your specific company who signs off when the control raises a hand. That call belongs to the board, not the standard, and most boards haven't made it yet.

• The ethics committee reviews the case once, at approval, and never looks at it again once it's live.
• There is a responsible use policy, but nobody can say which function enforces it or what happens when a team ignores it.
• The risk threshold lives on a slide, not in a process. Nobody has tested what happens when a real case crosses it.
• When the control says no, the final call goes to whoever holds more power in the room, not whoever holds the written authority.
• The external auditor asks for the decision log, and the answer is a buried email from eight months ago.

The problem underneath

Nobody has decided who wins when the control and the business disagree.

Every AI governance framework assumes the control wins automatically. That is not how a boardroom works. The use case that would delay the quarterly close, or the one the CEO already promised on an investor call, carries a weight no policy weighs the same way. If nobody has written down in advance who decides when that collides with the control, whoever holds more power that day wins, and the control becomes a formality that got worked around.

And there is something more uncomfortable still. A board that approves a long list of controls feels covered. It is covered on paper. It is not covered in practice if nobody can name, for the last use case that got scaled, who reviewed it, on what criteria, and when. That gap goes unnoticed until there is an incident, and then the board discovers it signed off on a policy, not a mechanism.

A board that approves AI controls without naming who enforces them is not managing risk. It is postponing it to the day of the incident.

BECOME

The framework

What has to be written down before you scale?

Threshold

The size, scope or reversibility level at which a use case needs committee sign-off instead of just the team that built it. Without a written number or criterion, every team sets its own.

Veto authority

Who can stop an already-approved use case once the control flags something, and how fast that call gets executed. If stopping it requires reconvening the same committee that approved it, the veto doesn't exist. A meeting does.

Decision log

What got decided, by whom, and on what evidence, for every use case that crossed the threshold. It is the first thing an auditor asks for, and it almost never exists when they do.

Review cadence

How often an already-approved case gets looked at again, not just at scale up. A model that cleared review in March can be behaving differently by October, and nobody has checked since.

Exit

What happens when the control says no and the business pushes back anyway: who has the final word, and what gets documented when the call goes against the committee's recommendation.

None of the five is a technical standard. They are five corporate governance decisions, the kind a board already knows how to make in other areas: financial risk, regulatory compliance, security. The only difference with AI is that these five haven't been made yet, because the topic entered the agenda as a technical matter and got delegated to a committee with no authority to stop the business.

Take the last use case that got scaled and ask who would have signed off on stopping it if the control had said no. If nobody in the room can answer with a name, you don't have a control framework. You have a folder of documents nobody has tested under pressure.

Let's design your control framework