Good AI governance is not just about identifying risk. It is about deciding who has authority when that risk needs to be accepted, challenged, changed, or stopped.
AI Governance Breaks Down When Decision Rights Are Unclear
Most firms can eventually answer a basic question such as who uses a particular AI tool.
The harder questions come after that.
Who approved the use?
Who decided the controls were sufficient?
Who can challenge that decision?
Who approves a material change in scope?
Who owns an exception?
Who can suspend the tool if it is no longer operating as intended?
That is where AI governance becomes operational.
Part 1 of this series focused on identifying where AI is being used and understanding the risks around those uses.
The next step is assigning authority.
Without clear decision rights, firms can end up with a governance structure where many functions are involved, but no one is clearly responsible for the final call.
Start With the Decision, Not the Committee
AI governance discussions often begin with structure.
Should the firm create an AI committee?
Should Compliance approve every use?
Should Technology own the process?
Those are secondary questions.
The first question should be: what decisions actually need to be made?
For a material AI use, those decisions may include:
whether the use can proceed
what conditions apply
what level of human review is required
whether a vendor is acceptable
whether a change in functionality requires another review
whether an exception can be granted
whether the use should be restricted
whether the tool should be suspended
Once those decisions are clear, assigning ownership becomes much easier.
The governance model should follow the decision rather than forcing every decision through the same forum.
The Business Should Own the Use
The business function benefiting from the AI use should generally remain accountable for the activity.
That means it should be able to explain why the tool is needed, what process it affects, and what outcome it is intended to support.
It should also own the consequences when the use changes.
For example, if an Operations team introduces AI into client onboarding, that function should not be able to transfer accountability simply because Technology implemented the tool or Compliance reviewed the controls.
The business should remain responsible for the process.
That includes deciding whether the use still makes sense when assumptions, volumes, client impact, or functionality change.
This is an important distinction.
Using AI does not create a new business process. It changes how an existing business process is performed.
Governance should preserve accountability for that underlying process.
Compliance Should Have Challenge Rights, Not Automatic Ownership
Compliance has a critical role, but it should not become the default owner of every AI-related decision.
Its role is more useful when it is clearly defined as challenge and oversight.
That may include assessing regulatory implications, identifying control gaps, determining whether a use affects registration or other regulatory obligations, and escalating concerns where a proposed use creates unacceptable risk.
CIRO has stated that it will ask dealers about the use of AI during Financial and Operations examinations and will review the operational controls implemented to ensure AI is working as designed. CIRO also notes that dealers should assess whether AI or automation affecting regulatory functions could constitute a material business change requiring notification or registration updates.
That makes the distinction between ownership and challenge especially important.
Compliance should be able to ask:
Who approved this?
What changed?
Who reviewed the change?
What evidence supports the decision?
Who can stop the use if the control no longer works?
Those questions are stronger than making Compliance responsible for operating the tool itself.
Approval Authority Should Follow Impact
Not every AI use needs the same approval.
A low-impact internal productivity tool should not necessarily go through the same process as a tool that influences suitability, surveillance, trading, complaints, regulatory reporting, or client communications.
The approval structure should therefore be proportionate.
A practical model may look like this:
Low-impact uses can be approved within the business, subject to defined standards.
Moderate-impact uses may require review by Compliance, Risk, Legal, or Technology, depending on the issue.
Higher impact uses may require senior management approval or an existing governance committee.
The key is to define the thresholds in advance.
If every use requires senior approval, governance becomes slow and superficial.
If nothing requires senior approval, material risk may never reach the right level.
Someone Needs the Authority to Say No
Governance models often describe who can approve something.
They are less clear about who can stop it.
That is a weakness.
A firm should identify the functions that have authority to restrict or suspend an AI use when risk exceeds acceptable limits.
That authority may sit with the business owner, Compliance, Risk, Information Security, senior management, or some combination depending on the issue.
The important point is that it should be known before an incident occurs.
Examples could include:
repeated inaccurate output
a material control failure
use of data outside approved parameters
a significant vendor change
unexpected client impact
an information security event
a change that increases automation of a regulatory function
the tool no longer performing as designed
A governance framework is incomplete if it explains how AI enters the organization but not how it is restricted or removed.
Material Changes Need Their Own Governance
Approval at implementation should not be treated as permanent approval.
AI uses can change materially even where the underlying tool remains the same.
A vendor may introduce a new model.
A business team may expand the use from drafting to decision support.
The tool may begin processing additional client information.
Human review may be reduced.
A pilot may become embedded in a production process.
Those changes can alter the risk profile substantially.
Firms should therefore define what constitutes a material change and who has authority to approve it.
This is particularly relevant in light of CIRO’s guidance that firms consider whether AI or automation of regulatory functions may represent a material business change.
The practical lesson is simple.
Approval should attach to the use that was assessed, not indefinitely to the name of the tool.
Exceptions Need an Owner and an Expiry Date
Every governance framework eventually encounters exceptions.
A business may want to proceed before a control is fully implemented.
A vendor may not meet one requirement.
A limitation may be accepted temporarily.
The issue is not whether exceptions ever occur.
It is whether they are governed.
An exception should normally identify:
what requirement is not being met
why the exception is being accepted
who approved it
what compensating controls apply
how long the exception lasts
what would trigger reconsideration
who is responsible for remediation
Open-ended exceptions are especially dangerous because temporary decisions can quietly become permanent operating practices.
If a firm cannot explain who accepted the exception and on what basis, accountability has already become blurred.
Third-Party AI Does Not Transfer Accountability
Vendor-supplied AI creates another common governance gap.
A firm may rely on a third party for the technology, model, infrastructure, or data processing.
That does not remove the firm’s responsibility for the way the tool is used.
The vendor may own the technology.
The regulated firm still owns the regulatory outcome.
That means governance should address questions such as:
Who approved the vendor?
Who understands the intended use?
Who reviews material vendor changes?
Who assesses whether contractual protections remain adequate?
Who decides whether the firm continues using the tool after a significant incident or change?
Who owns contingency planning if the vendor becomes unavailable?
This is where third-party risk, operational resilience, and AI governance intersect.
Existing Governance Should Do Most of the Work
Not every firm needs a dedicated AI committee.
In many cases, the better approach is to use existing decision-making structures.
A vendor issue may go through the existing third-party risk process.
A material technology change may go through change governance.
A regulatory issue may go through Compliance.
A high impact model may go through a model risk process where one exists.
A major operational incident may go through established incident management and escalation.
This is consistent with the broader risk-based approach reflected in OSFI Guideline E 23, which emphasizes proportional governance, clear responsibilities, approval authority, review, and monitoring based on model risk. The guideline applies to federally regulated financial institutions, but the governance principles are useful more broadly.
The objective should be to integrate AI into existing governance rather than create a parallel organization.
Governance Should Be Documented at the Decision Level
A policy that says “AI uses require appropriate approval” is not enough.
A regulator or internal auditor will need to understand what happened in a specific case.
That means firms should be able to reconstruct the decision.
For a material use, the record should show:
who proposed the use
who assessed the risks
who challenged the proposal
who approved it
what conditions were imposed
what exceptions were accepted
what monitoring was required
what material changes occurred later
who approved those changes
This is where governance becomes defensible.
The strongest framework is not necessarily the one with the most policies.
It is the one where the firm can explain who made the decision and why.
A Practical Decision Rights Model
For many firms, the following structure is enough.
Business owner
Proposes the use, owns the business outcome, and remains accountable for the underlying activity.
Technology or vendor owner
Owns implementation, access, integration, security coordination, and vendor management.
Compliance and Legal
Assesses regulatory and legal implications and exercises challenge where required.
Risk function
Provides independent challenge for higher impact uses and significant exceptions.
Senior management
Approves material uses, major exceptions and significant changes where appropriate.
Board
Receives visibility over material AI risk where it forms part of the firm’s broader risk profile.
The exact titles may differ.
What matters is that the authority is clear.
Five Questions That Reveal Whether Governance Is Real
A firm should be able to answer these without hesitation:
Who can approve this use?
Who can challenge that approval?
Who can approve a material change?
Who can accept an exception?
Who has authority to stop the use?
If the answers depend on who happens to be in the room, the governance model isn't mature yet.
Good Governance Creates Faster Decisions
Clear governance should not make AI adoption harder.
It should reduce uncertainty.
When decision rights are established in advance, lower impact uses can move quickly.
Higher impact uses can receive the scrutiny they require.
Exceptions can be managed deliberately.
Material changes can be assessed consistently.
Issues can be escalated before they become incidents.
That is a better model than asking Compliance to review everything or allowing every business unit to make its own judgment.
AI Governance Is Ultimately About Authority
Part 1 of this series focused on visibility.
Firms need to know where AI is being used and what risks it creates.
Part 2 is about what happens after that risk is identified.
Someone has to make the decision.
Someone has to challenge it.
Someone has to approve changes.
Someone has to accept exceptions.
And someone needs the authority to stop the use when the risk is no longer acceptable.
That is what turns AI governance from a policy into an operating model.
This article is part of GoldSleeve’s AI Governance for Regulated Firms series.
Previous: AI in Regulated Firms: What Compliance Leaders Should Be Asking Now
Next in the series: Using Generative AI in Compliance: Where the Control Risks Begin
