The Question Every Board Should Be Asking Before Their Next AI Approval
Most boards are approving AI initiatives without answers to the three questions that determine whether the system is actually governed. Marques Consulting Group on what boards need to ask before any AI approval, and why governance belongs at the decision point, not after it.
GOVERNANCE AND RISK
Most boards are asking the wrong question.
When an AI initiative comes to the table for approval, the conversation centres on capability. What the system can do. What efficiency gains it will deliver. What the projected return looks like and over what timeline. These are not irrelevant questions. But they are the second conversation. The first conversation is almost never happening.
Before any board approves an AI initiative, three questions need answers. Not approximate answers. Specific, documented, operationally grounded answers that exist before the system touches anything real.
What is this system not permitted to do.
Who reviews its outputs, at what points, and under what authority.
What happens when it operates outside its approved scope.
If those three questions do not have precise answers at the point of approval, the board has not approved an AI initiative. It has approved an assumption. And assumptions, at the scale and speed that intelligent systems operate, produce consequences faster than governance can catch them.
What the system is not permitted to do
Most AI governance conversations focus on capability. The permission boundary, the precise definition of what the system is not authorised to pursue, is treated as a technical detail to be handled after approval, during implementation. It is not a technical detail. It is a governance decision, and it belongs at the board level before a single workflow is built.
A system without a defined permission boundary will find the edge of whatever space it has been given and operate there. This is not a malfunction. It is how systems built to optimise for an objective behave when the objective has been defined without sufficient constraint. The boundary has to be explicit, documented, and built into the architecture before deployment. Not inferred from the objective. Not assumed from the use case. Explicit.
The board that approves an AI initiative without a defined permission boundary has not governed the system. It has delegated that responsibility to whoever builds it, with no framework for what that boundary should look like or how it will be enforced.
Who reviews outputs, at what points, and under what authority
Human review is not a feature. It is not a compliance requirement to be satisfied with a checkbox. It is the mechanism by which an organisation maintains accountability for what its systems produce, and it has to be designed into the workflow before the system operates, not added as a layer of oversight after outputs are already being acted on.
The governance question is specific. Which outputs require human review before they are used. At which points in the workflow does a human need to verify, approve, or reject what the system has produced. Who holds that review authority, and what happens to the output if the reviewer is unavailable, disagrees, or identifies something outside the system's approved scope.
These are not questions with generic answers. They are specific to the workflow, the data, the decision, and the consequences of getting the output wrong. A board that approves an AI initiative without those specifics documented is approving a system that will produce outputs under conditions the board has not actually considered.
What happens when the system operates outside its approved scope
Every intelligent system will, at some point, encounter a situation its design did not anticipate. The question is not whether this will happen. It is what the organisation does when it does.
The answer has to exist before deployment. Who is notified. What authority does that person have to halt the system. What is the documented process for reviewing what happened, determining whether the scope definition needs to be updated, and deciding whether the system resumes operation and under what conditions. Who holds final accountability for that decision.
Without those answers documented in advance, the organisation's response to an out-of-scope event is improvised. And improvised responses to AI governance failures, at the speed and scale these systems operate, are not adequate. By the time the response is assembled, the system has continued operating.
Why this conversation is not happening at the board level
The gap is not ignorance. Most board members understand that AI governance matters. The gap is framing. AI initiatives arrive at the board as capability and return conversations. The governance questions arrive later, at the implementation stage, managed by teams the board has already delegated to. By the time the governance architecture is being built, the approval has already been given and the framing has already been set. Governance becomes a constraint on something that has already been approved rather than a condition of the approval itself.
Marques Consulting Group builds the answers to those three questions into the engagement before any system is designed. The permission boundary, the human review architecture, and the out-of-scope response protocol are defined during Phase One and Phase Two of every MCG engagement, documented in the Key Findings Report, and built into the workflow architecture before Phase Four begins.
This is not governance added after the build. It is governance that makes the build possible, because a system built without those answers is not ready to be built.
The board's role is not to approve a technology. It is to authorise a governed system. Those are not the same thing. And the difference between them is visible the moment something unexpected happens, which it will.
The question is not whether your organisation is ready to use AI. The question is whether the answers to those three questions exist before your next approval.
If they do not, the approval should wait until they do.
Marques AI Consulting · MCG
Marques AI Consulting is the specialised practice of Marques Consulting Group (MCG).
© 2026 Marques Consulting
