Who Should Be in Your AI Steering Group (And Who Shouldn't)

Two steering groups fail, and they fail for opposite reasons.

The first is too technical. It's full of people who understand the AI, the data pipeline, and the model architecture, and short on people with the authority to trade off resource, risk, and commercial priority against everything else the business is running. Every meeting turns into a technology briefing. Nobody in the room can decide whether an experiment scales, because the people who could commit budget or reassign a team aren't in it.

The second is too senior. It's the CEO, the CFO, and two other executive committee members, all with full diaries and none of them able to meet more often than once a month. Every experiment approval waits for a calendar slot that doesn't exist. The programme needs fast, frequent decisions. The steering group can only give it occasional, heavyweight attention, and the gap between the two is where momentum dies.

Both patterns come from building the steering group around who feels important to include, rather than around the decisions the group actually has to make.

What the steering group is for

The steering group isn't the team running the experiments. That's the core team: a programme lead, a technical AI lead, and a business process owner, working day to day with protected time. The steering group sits above that team to make the decisions the core team can't make on its own: approving experiments that touch real data or real processes, allocating resource across a growing pipeline, deciding whether a finished experiment scales or gets killed, and owning the risk if something goes wrong.

Who owns a capability once it's live in production is a separate, later question, one I've covered in who owns an AI capability after the experiment team moves on. This piece is about governing the programme while it's still experimental.

Composition: roles, not titles

Use the Programme Governance Roles (06a) template to define who sits on the steering group, and resist the instinct to default to job titles. A steering group needs three things from its members: enough authority to approve experiments and commit resource without escalating further, enough operational knowledge of the functions the programme touches to make a real risk judgement, and enough time to actually turn up on a fortnightly cycle. In practice, that's usually directors, not the executive committee.

A regional grocery chain nearly derailed its own programme by getting this wrong at the top. The CEO wanted to sponsor personally, and every experiment decision got routed to a diary with no room for it. The programme stalled while the team waited for CEO availability. The fix was a steering group of the operations, commercial, and IT directors, given explicit delegated authority for the lower-risk tiers, with the CEO retained as sponsor and kept for the highest-tier decisions through monthly briefings. Delegation replaced escalation, and the experiment pace picked up as soon as it did.

The opposite trap is composition skewed entirely toward technology. A multi-brand hospitality group ran its programme inside IT because "AI is technology." The first two experiments produced technically sound solutions the operations teams never adopted, because operations had never been in the room to shape them. A steering group needs people who own the processes being changed, not only the people who can evaluate the AI.

Keep the sponsor separate from the steering group's routine decisions. The sponsor operates one level up: visible backing, resource protection, blocker removal, and escalation on the highest-risk calls. Fold the sponsor into every fortnightly steering meeting and the too-senior problem reappears at a smaller scale.

Cadence: setup isn't steady state

The steering group's rhythm changes once experiments start running. At setup, before anything has been approved, the group's job is to agree the governance model itself: composition, tiers, and decision rights. Once experiments are live, the standing cadence is a fortnightly steering update: thirty to sixty minutes, reviewing progress against agreed success criteria, deciding what to approve, scale, kill, or extend, and surfacing resource issues and emerging risk. The steering group's job in that meeting is to decide. A group that spends the session reviewing experiment outputs line by line has a delegation problem with the core team that the meeting itself won't fix.

Weekly stand-ups belong to the experiment team. Monthly sponsor briefings and quarterly board reporting sit above the steering group. Keeping those layers distinct, rather than compressing them into one meeting because it feels efficient, is what lets each layer do the job it's there for.

Decision rights: write them down before the first approval

Four things a steering group needs explicit authority over: approving experiments before they start, allocating resource and budget across a growing pipeline, deciding whether a completed experiment scales or gets killed, and confirming who owns the risk if something goes wrong. None of this is complicated in principle. It gets contentious the first time an experiment produces an ambiguous result and nobody agreed in advance what evidence would trigger scaling versus stopping. Define the criteria for each decision at setup, before the first experiment is running, using the Tiered Governance Decision Guide (06c) to set out what needs steering group approval and what the core team can decide on its own.

The first three meetings

Meeting one is a founding session. Its purpose is to agree composition, confirm the three governance tiers, and map decision rights before any experiment starts. The Programme Setup Facilitation Guide (06i) structures this as a working session: team design, governance model, and stakeholder mapping in one sitting. Use the Stakeholder Matrix (06e) here to separate the people who need a seat in the room from the wider group who only need to stay informed, and the Stakeholder Map (06f) to see where support and resistance actually sit before the programme starts.

Meeting two classifies and approves the first-wave experiments. Each candidate gets a tier using the Tiered Governance Decision Guide (06c), and the steering group approves the experiments that need its sign-off, with a brief risk assessment and agreed success criteria already attached. Tier 1 experiments shouldn't need to be on this agenda at all. If they are, the tiering from meeting one wasn't applied properly.

Meeting three is the first live progress review, run to the fortnightly format the programme will keep going forward: what's on track, what's blocked, what decision is needed. It's also usually where the sponsorship gets its first real test. A data owner pushes back, or a competing priority tries to pull resource away, and how the steering group and sponsor respond in that meeting sets the tone the rest of the programme will read from.

Get this in place first

A steering group assembled around who felt important to include, rather than around the four decisions it actually has to make, spends its first six months improvising those decisions anyway, under pressure, without the criteria agreed in advance. Get the composition, the cadence, and the decision rights settled before the first meeting happens. The fortnightly rhythm that follows then has a structure to run on, not just a diary invite.

The full setup sequence, including team composition, governance tiers, and the operating rhythm this piece draws on, is in Section 6: Setting Up for AI.