Who Owns AI Governance? Building the Committee Before the Regulator Asks

AI governance should be owned by one named executive, supported by a small cross-functional group that meets on a fixed schedule and has the authority to say no. Everything else is detail. The failure I see most often is not a bad structure; it is no structure, held together by the assumption that someone else is handling it.

That assumption is expensive. When a tool goes wrong, the first question anyone asks is who approved it, and diffuse ownership means the honest answer is nobody.

Who should the single accountable owner be?

Whoever can stop a deployment without asking permission.

That is the only test that matters. Title varies by company: a COO in a services firm, a CTO in a software company, a chief privacy officer in a regulated one. What does not vary is the authority. If your named owner has to escalate to prevent a launch, they are a coordinator, not an owner, and the role will not survive its first real conflict.

Two common choices that usually fail. Putting it with legal alone produces careful analysis and no operational traction, because legal cannot see what teams are actually running. Putting it with IT alone produces good technical controls and blindness to fairness and disclosure questions, which are business decisions.

In a company under about fifty people, this is one person with a fraction of their week, not a department. Say so explicitly. Pretending it needs a full-time hire is how the role stays unfilled.

What does the committee actually decide?

Give it a real docket or it becomes a status meeting people skip.

The first line is the one that gives the committee teeth. If new systems can reach production without passing through it, the committee is advisory and will be treated accordingly.

Who sits on it?

Four to six people, with a bias toward small. Beyond six, the meeting becomes a briefing.

• The accountable executive, who chairs and breaks ties.
• Privacy or legal, for obligations and disclosure.
• Security or IT, for technical controls and data flows.
• A business representative from wherever AI use is heaviest, usually operations, sales, or support.
• Optionally, the person who actually builds or integrates the systems, if you have one.

The business seat is the one that gets dropped, and dropping it is why governance committees develop a reputation for blocking. Someone in the room needs to feel the cost of a no.

How do you keep it from becoming theatre?

Three habits separate committees that work from committees that meet.

Decide in the room, in writing. Every item ends with a decision, an owner, and a date, recorded where an auditor could read it later. A committee that defers everything to offline follow-up produces no evidence that it functions. Our incident log and assessment records exist partly to hold those decisions in one place.

Bring real cases, not policy debates. A committee that spends its second meeting wordsmithing a policy has already lost the room. Bring the resume screener the hiring manager wants to keep, and decide about that.

Publish the queue. People will route around a committee they cannot predict. If teams can see what is pending and how long approval typically takes, they stop going around it. Unpredictable governance creates shadow AI faster than strict governance does.

What about the rest of the organization?

Three roles below the committee, and they should be written into your AI use policy.

System owners keep their inventory entry accurate, flag material changes, and answer for the outcomes of the system they chose. Reviewers are the humans exercising oversight on individual outputs, and they need explicit authority to override, not just to observe. Everyone else needs one thing: a clear, low-friction way to register a tool they want to use. If registering is harder than not registering, you will get shadow use, regardless of the policy.

That last point deserves emphasis. The most effective governance control I have seen in a Canadian mid-sized company was not a policy. It was a two-field form that returned a decision in under three business days. Compliance followed convenience.

When should you formalise this?

Earlier than most teams think, but lighter than most templates suggest.

The trigger is not headcount. It is the first AI system that influences a decision about a person, or the first one processing personal information at scale. Before that, an owner and a written policy is proportionate. After it, you need the committee, the register, and the assessment path, because that is the point at which a regulator, an insurer, or an enterprise buyer will ask who decided.

For the assessment that usually follows the committee's first real decision, when a privacy impact assessment is required under Law 25 sets out the trigger tests.

This is general information, not legal advice.

Valdra keeps the register, the risk tiers, the assessments, and the decision record in one place, so the committee reviews evidence rather than assembling it. The AI governance view is built around that meeting.