🧭 The 12 Decisions Every AI Governance Council Should Own

If your AI Governance Council is reviewing every AI use case, your governance model is already starting to break.

Centralizing decisions can feel prudent. AI introduces legal, operational, reputational, and technical risks, so putting a governance body in the middle of every decision appears to provide control.

But as AI adoption scales, that model becomes unsustainable.

Business teams wait for approvals. Governance teams spend their time reviewing routine cases. And the genuinely difficult decisions compete for attention with issues that should have been resolved elsewhere.

The better model is decision-based governance.

An AI Governance Council should own the relatively small number of decisions that require enterprise authority, cross-functional judgment, or explicit acceptance of material risk.

Everything else should be governed through policies, standards, delegated authority, and clearly defined escalation thresholds.

So what decisions actually belong with the council?

A practical note: This framework reflects established enterprise governance principles, risk-based oversight, delegated authority, separation of accountability and review, documented escalation, and lifecycle governance applied specifically to the challenges organizations face governing AI at scale.

Every governance system ultimately operates within an organization's risk appetite.

The council should translate enterprise risk appetite into practical boundaries for AI: which uses are acceptable, which require additional controls, and which use cases should the organization not pursue.

This creates the foundation for every downstream governance decision.

The council should not determine the risk tolerance of individual business units independently. It should establish the enterprise boundaries within which those decisions are made.

Organizations need a common methodology for determining how AI systems are categorized and what governance requirements follow.

That might include regulatory classifications, internal risk tiers, prohibited-use categories, or combinations of all three.

The council should own the classification framework.

It should not manually classify every AI system.

Routine classification should occur through the governance process using established criteria. Only ambiguous, disputed, or materially significant cases should escalate to the council.

Some AI applications should simply fall outside the organization's acceptable boundaries.

The reasons may be legal, ethical, reputational, operational, or strategic.

The council should approve and maintain the organization's prohibited-use policy and decide exceptions where exceptions are legally and organizationally permissible.

This prevents individual teams from independently determining whether particularly sensitive uses of AI are acceptable.

Not every AI system requires the same level of scrutiny.

A low-risk productivity assistant and an AI system influencing employment, credit, healthcare, safety, or other consequential decisions should not move through identical governance processes.

The council should determine the thresholds that trigger enhanced review, additional controls, executive approval, or ongoing monitoring.

The goal is proportionality: more governance where the consequences are greater, less where they are not.

Governance decisions are only as defensible as the evidence supporting them.

The council should establish minimum evidence requirements for different categories of AI systems.

Depending on the use case, that may include testing results, data documentation, privacy assessments, cybersecurity reviews, human-oversight design, vendor documentation, model performance evidence, or legal analysis.

The council defines the evidence standard.

Control functions and business teams produce and evaluate the evidence.

One of the most important decisions a governance council can make is deciding which decisions it does not need to make.

Organizations should establish explicit approval authorities based on factors such as risk tier, regulatory exposure, financial impact, customer impact, and strategic significance.

Routine cases can then be approved by designated business leaders or governance functions.

Higher-risk cases escalate.

Without delegated authority, governance inevitably centralizes.

AI decisions frequently cross organizational boundaries.

Legal may interpret an obligation one way. Cybersecurity may identify a technical concern. The business may believe the residual risk is manageable. Data science may question whether a proposed control is technically appropriate.

The governance model needs a defined mechanism for resolving those disagreements.

The council should serve as the escalation point when material cross-functional disagreements cannot be resolved through the normal governance process.

It should not be the first forum where those discussions occur.

No governance framework anticipates every situation.

There will be cases where a business team cannot meet a governance requirement exactly as written but believes the underlying risk can be addressed another way.

Those exceptions should not happen informally.

The council should establish the exception framework and retain authority over material exceptions, including the rationale, compensating controls, duration, and conditions for continued use.

An exception should be a documented governance decision, not a workaround.

Controls rarely eliminate risk completely.

For materially significant AI systems, the remaining risk may exceed the authority delegated to the business owner or control functions.

The council should determine when residual risk must be formally accepted and by whom.

Crucially, the council itself should not automatically absorb that accountability.

Where appropriate, acceptance should escalate to the executive who owns the business outcome or to another authority explicitly designated by the organization.

Governance review does not transfer business ownership.

Governance does not end when an AI system is approved.

Performance can deteriorate. Regulations can change. New risks can emerge. Vendors can modify underlying models. The organization's own use of the system can evolve.

The council should establish the conditions under which an AI system must be restricted, suspended, reassessed, or retired.

For significant cases, it should have authority to require those actions.

Approval should never mean permanent authorization.

AI systems evolve continuously.

A change in model, data, purpose, user population, geography, integration, vendor, or decision authority can materially alter the system's risk profile.

The council should establish enterprise reassessment triggers so teams do not have to guess whether a change requires another governance review.

Routine reassessments can then occur through the established process, while significant changes escalate when necessary.

This turns governance from a one-time approval exercise into a lifecycle discipline.

The final decision is easy to overlook.

The council governs not only AI systems but also the governance system itself.

As regulations evolve, technologies change, incidents occur, and organizations gain experience deploying AI, governance policies and thresholds will need to evolve.

The council should periodically ask:

Are the right systems being escalated?

Are low-risk systems moving quickly enough?

Are controls actually reducing risk?

Are business teams finding ways around the process?

Are recurring ambiguities exposing weaknesses in the classification methodology?

Are incidents revealing gaps in existing controls?

The council should use that evidence to modify policies, decision rights, thresholds, and governance processes.

Governance itself requires governance.

The distinction running through all 12 decisions is important.

An AI Governance Council should own the rules, thresholds, exceptions, escalations, and material risk decisions that require enterprise authority.

It should not perform every governance activity.

Business owners remain accountable for the AI systems they deploy.

Legal, privacy, cybersecurity, compliance, risk, and technical teams provide specialized review and challenge.

Governance operations administer the process and maintain evidence.

Individual decisions should be delegated whenever they can be made consistently within established enterprise rules.

The operating model should look something like this:

That is how governance scales.

The objective is not to put the council in the middle of every AI decision. It is to ensure that the right decisions reach the right authority at the right time with enough evidence to make them defensibly.

The best AI Governance Councils are not the ones making the most decisions. They are the ones that create a system in which most decisions can be made correctly without them.

That is the difference between governance that controls AI and governance that simply slows it down.

Does your AI Governance Council own too much, too little, or roughly the right set of decisions?

Reply to this email and tell me how your organization divides decision authority between the governance council, control functions, and business teams. I’m especially interested in where the model breaks down in practice.

Forward this briefing to a colleague who is helping define AI governance, risk, or decision authority in their organization.

Once decision authority is clear, the next challenge is determining how AI systems should actually be classified.

In the next briefing, I’ll break down a practical enterprise classification process—from scope and evidence collection through classification, review, documentation, and reassessment—and examine where ambiguity should trigger escalation.

Disclaimer: This publication is for informational and educational purposes only and does not constitute legal, regulatory, compliance, or other professional advice. Organizations should evaluate applicable requirements based on their specific circumstances and consult appropriate legal or professional advisors where necessary.