The committee, the CAIO, and the supporting cast

Lesson 3 of 5 in Designing the AI Governance Operating Model.

Whatever the archetype, decisions on contested cases end up in front of an AI governance committee (also styled AI review board or responsible-AI council). Committees fail in boring, predictable ways — no quorum rules, advisory-only findings that businesses ignore, a membership of enthusiasts with no authority — so charter design is where the real work happens. Six elements decide whether yours will function:

Mandate and decision rights. Write down what the committee can decide versus merely recommend. A committee with veto power over deployment is a control; a committee that "provides perspectives" is a focus group. Most effective charters grant binding authority over defined tiers (it can block a tier-1 launch) and advisory status elsewhere — and they name who can overrule it (typically only the executive risk committee, in writing).

Membership mix. You need four competencies at the table: the business (someone who owns the P&L consequence), the technical (someone who can interrogate a model card), the legal/compliance (someone who knows which statutes bite), and the risk/ethics lens (someone whose job is the affected person’s interest). Committees of only lawyers reject everything; committees of only engineers approve everything.

Quorum and cadence. A quorum rule that requires at least one member from each competency prevents the Thursday meeting where three engineers approve a hiring tool. Cadence follows volume — biweekly is typical — but the charter must also define an emergency path for incidents that cannot wait.

Fast-track lanes. The committee should almost never see routine cases. A triage rule sends low-tier, precedented use cases through delegated approval with a defined checklist — reserving full committee review for novel, high-tier, or contested cases. Without a fast lane, the committee becomes the bottleneck from the last lesson and the business learns to avoid it.

Escalation and appeal. Rejected requesters need a legitimate route up (usually to the executive risk committee) — otherwise they take the illegitimate route around. Symmetrically, conditions attached to approvals need an owner and a due date, or "approved with conditions" quietly becomes "approved".

Minutes as evidence. Decisions, dissents, conditions, and recusals go on the record. When a regulator or plaintiff later asks who approved this and what did they know, the minutes are the answer — thin minutes read, in hindsight, like negligence.

The committee escalation path: how a use case moves

  1. Use case enters intake

    From the intake process (next module): a completed form with gating questions answered.

  2. Triage against tiering rules

    A governance analyst (or spoke lead) applies the tiering scheme and checks for precedent.

  3. Novel, high-tier, or contested?

    The charter defines the thresholds. Everything else takes the fast lane.

  4. Fast lane: delegated approval

    Checklist-based sign-off by the delegated approver, logged in the registry. Sampled quarterly by the second line for calibration.

  5. Full committee review

    Quorum required across all four competencies. Requester presents; second line challenges; minutes record the decision and dissents.

  6. Committee decision

    Approve, approve with conditions (owner + due date per condition), or reject with reasons.

  7. Conditions tracked to closure

    Open conditions block go-live or trigger review at the due date. Unclosed conditions escalate automatically.

  8. Appeal to executive risk committee

    The single legitimate route past a rejection — in writing, with the committee’s reasoning attached.

  9. Registered and monitored

    The decision, tier, and conditions land in the AI registry; monitoring obligations begin.

Above the committee sits the question of executive ownership: does the organisation need a Chief AI Officer? The role makes sense when AI is both a strategic bet and a material risk — someone must own the tension between the two, and splitting it (CTO owns value, CRO owns risk) reproduces the exact conflict governance is supposed to resolve. It makes less sense in organisations where AI is a modest tool: there, a well-mandated head of AI governance reporting to the CRO or General Counsel does the same work without another C-suite seat.

The reporting line is the real design decision. A CAIO reporting to the CTO inherits delivery incentives — governance becomes a speed bump the same executive is paid to minimise. Reporting to the CEO or COO signals that AI is enterprise strategy, not an IT project, and keeps the veto independent of the people being vetoed. Wherever the line lands, map the borders explicitly: the CDO owns the data the models consume, the CISO owns their security, the privacy officer owns the personal-data obligations, the General Counsel owns legal exposure. The CAIO’s distinct job is the system-level accountability none of them individually holds. (The full roles crosswalk lives in the foundations module Who’s Who in AI Governance.)

Below the executive layer, a handful of named roles make the machinery turn. The titles vary by industry — banks inherit vocabulary from model risk management, tech firms from MLOps — but the functions are stable, and every one of them needs a name attached to every system in the registry.

Model owner — accountable for one system, end to end

A business-side individual (not a team, not a committee) accountable for a specific AI system: its purpose, its performance, its compliance actions, its retirement. The single most diagnostic field in any AI registry is the owner field — when it is blank, stale, or points at someone who left, nobody is accountable. Ownership transfers on staff churn must be an explicit process, not an assumption.

Business sponsor — accountable for the why

The executive who wants the system to exist and owns its business case. Sponsors matter to governance because they are who you escalate to when the model owner will not fund a required fix — and who formally accepts residual risk within their delegated appetite.

Model risk manager / second-line reviewer

Sits in the risk function. Sets the standards models must meet, challenges the first line’s assessments, and independently reviews high-tier systems. In banks this role predates AI governance by a decade — it is the model risk management function built to satisfy Fed SR 11-7.

Validation lead — independent technical testing

Runs or commissions independent validation of high-tier models: performance on the deployment population, fairness metrics, robustness, stability. Independence matters — validation by the team that built the model is proofreading your own essay.

Data steward — accountable for what goes in

Owns the quality, lineage, and permissible use of the datasets feeding models. The bridge to the data-governance program: when a model wants to reuse customer data collected for another purpose, the steward is where purpose-limitation questions land first.

AI ethics lead — the affected person’s advocate

Owns the harms-and-stakeholder lens: who is affected, who was consulted, what would this look like on the front page. In mature programs this is a standing committee seat with real veto-triggering power, not a communications role. The test of whether the role is real: has it ever changed or stopped a launch?

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.