How to Structure an AI Steering Committee That Actually Steers

The steering committee met monthly. The program lead presented a status deck covering the past four weeks. The committee members asked clarifying questions. A few concerns were raised and noted. Nobody made a decision. The next meeting was scheduled for four weeks out. After eight months of this, the program was exactly as stalled as it had been when the committee was formed — except now there was a documented trail of meetings proving that the right people had been in the room.

This is the modal outcome of AI steering committees at financial institutions, and it is not an accident. It is the predictable result of a committee that was designed to receive information rather than to produce decisions. The name says "steering" but the structure — monthly cadence, status-deck format, no explicit decision authority — produces reporting. A reporting forum and a steering forum are different things, and confusing them is one of the reasons AI programs stall at the governance layer rather than the technical one.

The difference between a committee that moves programs forward and one that consumes time without producing decisions comes down to three design choices made before the first meeting: who chairs it, what it is explicitly empowered to decide, and how often it meets. Get those three things right and a steering committee will work. Get them wrong and you will have a well-attended series of meetings that functions as cover for inaction.

What a steering committee is actually supposed to do

A steering committee exists to resolve things the program team cannot resolve on its own. That is the entire job. Not to review status — the program team knows the status. Not to provide encouragement — the program team doesn't need encouragement. Not to ensure senior visibility — visibility without decision authority is not valuable when the program is blocked.

The things a program team cannot resolve on its own are typically three types. First, cross-functional resource conflicts: the data engineering team is committed to another project, the IT security review is taking longer than planned, the MRM team is at capacity. These conflicts have owners outside the program, and resolving them requires someone with authority over those owners. Second, scope decisions: a requirement has changed, a use case has expanded, the original budget assumptions have turned out to be wrong. These decisions require sign-off from someone accountable for the overall program investment. Third, strategic direction changes: the competitive environment has shifted, a regulatory development has changed the risk calculus, the executive sponsor needs to make a call about whether to proceed, accelerate, or pause.

None of these require a monthly status deck. All of them require a senior person with genuine decision authority and the willingness to use it. A steering committee that is designed around the status deck is optimized for the wrong thing.

The three design choices that determine whether a committee steers

Who chairs it — and whether they actually chair it. The executive sponsor must chair the steering committee. Not a delegate. Not the program lead. Not the CTO's chief of staff. The executive sponsor: the person whose name is on the program, who made the commitment to the board, who has the authority to resolve cross-functional conflicts and make scope decisions.

This is the most consistently violated rule in AI steering committee design, and the consequences are direct. A committee chaired by someone without genuine decision authority cannot make decisions. When a conflict arises — and in a cross-functional AI program at a financial institution, conflicts always arise — a delegated chair has to escalate to get resolution. That escalation takes time, introduces friction, and signals to the committee that the meeting is not the place where things get decided. Which means it isn't.

The executive sponsor chairs, attends every meeting, and comes prepared to make decisions rather than to ask questions. If the sponsor cannot commit to that, the committee is not ready to be convened, and the program is not ready to be governed. Forming the committee before the sponsor commitment is real creates the illusion of governance without the substance.

What it is empowered to decide — written down in advance. Every steering committee needs an explicit mandate: a written list of the decision types that are the committee's to make. This list does two things. It tells the program team which problems to bring to the committee instead of trying to resolve them bilaterally. And it tells the committee members what they signed up for — that attendance at this committee means making decisions, not just hearing about them.

The mandate should be specific. Not "the committee will provide strategic oversight" — that phrase is meaningless and produces exactly the status-deck dynamic described above. Instead: the committee is empowered to approve scope changes above a defined threshold, resolve cross-functional resource conflicts that the program lead cannot resolve at the working level, approve budget changes above a defined threshold, and make go/no-go decisions at defined program checkpoints. Each of those is a real decision that someone with authority needs to make. Naming them in advance is the difference between a committee that has permission to steer and one that is implicitly expected to observe.

How often it meets — and what the cadence signals. Monthly steering committee meetings are appropriate for programs that are progressing normally and need executive visibility at a regular interval. They are not appropriate for programs that are stalled, programs that are in a critical phase, or programs that have active cross-functional conflicts that need resolution faster than once a month.

The cadence of a steering committee is a signal. Monthly signals that the executive sponsor considers this a normal-tempo initiative that can wait four weeks between touchpoints. Bi-weekly signals heightened attention. Weekly signals urgency — either because the program is in a critical window or because something has gone wrong and the sponsor is engaged at a different level.

For a program that has stalled, the first governance intervention is often simply changing the meeting cadence. Moving from monthly to bi-weekly, with an explicit statement from the sponsor that the program has their attention until the blocker is resolved, does more to unstick a program than most technical interventions. The stall is usually organizational, not technical — and an organizational signal from the right level of seniority is what moves it.

What belongs on the agenda — and what doesn't

The agenda design problem at most steering committees is that the status update consumes the time that should be used for decisions. A ninety-minute meeting with forty-five minutes of status presentation leaves forty-five minutes for discussion, most of which is clarifying questions about the status presentation rather than decisions.

Status updates should be distributed before the meeting and read before people arrive. The opening five minutes of the meeting should confirm that the pre-read was reviewed and identify any questions. The remaining time should be used entirely on the items that require the committee's decision authority.

What belongs on the steering committee agenda: cross-functional blockers that the program team has been unable to resolve, proposed scope changes above the defined threshold, budget variances requiring approval, go/no-go decision points, and any strategic context changes that affect the program's direction. These are agenda items that produce a decision at the end. The meeting is over when the decisions are made.

What does not belong: technical deep-dives that don't require a decision, vendor demonstrations, progress updates that could be communicated in a written pre-read, and working-level discussions that should happen between program teams before being escalated. When these items appear on the steering committee agenda — and they will, because program teams understandably want to use the visibility — the chair needs to redirect them. A technical deep-dive that produces no decision is a use of steering committee time that belongs in a working session, not a governance forum.

How to run the first meeting after a program has stalled

When an AI program has been stalled for a meaningful period and the steering committee has been the monthly-status-deck variety, the first meeting after a reset is the most important one. It sets the expectation for what the committee is now, and it either signals that something has changed or confirms that nothing has.

The sponsor opens by naming what has happened: the program has not progressed at the expected pace, the steering committee has not been producing the decisions needed to unblock it, and that is changing. This is not a dramatic statement — it is a direct one. The room already knows the program is stalled. What they need to hear is that the sponsor knows it too and is engaged at a different level.

The agenda for the reset meeting should contain exactly two items: a clear-eyed diagnosis of what is actually blocking the program, and the decisions required to unblock it. Not the full status history — the current blockers. Not a retrospective on what went wrong — what needs to happen next. The meeting ends when those decisions are made and owned. If they can't be made in that meeting, they are escalated with a named deadline.

The reset meeting often reveals that the program was never actually blocked by a technical problem. The blocker was almost always organizational: a resource conflict that nobody with authority had resolved, a scope question that nobody had been willing to answer, a risk tolerance question that had been deferred because the right person wasn't in the room. Getting the right person in the room and making them answer the question is the work of a functioning steering committee. It is almost never the work that happens in the status-deck forum.

Five questions to answer before the first steering committee meeting

If you are setting up an AI steering committee — or resetting one that isn't working — these five questions should have clear answers before the first meeting is convened.

Who is the chair, and have they committed to attending every meeting and making decisions? If the answer involves any ambiguity about whether the executive sponsor will personally attend, or whether decisions can be made by a delegate, stop here. The committee is not ready.

What is the written mandate — the specific list of decision types this committee is empowered to make? If the answer is "strategic oversight" or "executive visibility," the mandate needs to be rewritten. Decision types, not governance principles.

What is the cadence, and does it reflect the urgency of the program's current state? Monthly for a progressing program; bi-weekly or weekly for a stalled one. The cadence should match the reality, not the template.

What is the pre-read discipline — will status updates be distributed and read before meetings, freeing the meeting time for decisions? If the answer is "we'll see," the status deck will eat the agenda. Establish the expectation before the first meeting.

What is the first decision this committee needs to make? If there is no decision on the first agenda, the committee is not needed yet. Convene when there is something to decide.

The most reliable diagnostic for whether a steering committee is working is simple: count the decisions produced per meeting. A committee that meets monthly and averages less than one decision per meeting is not steering. It is convening. The distinction matters for whether the program moves.

If your institution has an AI steering committee that has been meeting for six months and the program has not progressed, the committee structure is almost certainly part of the explanation. The fix is not a better status deck. It is answering the five questions above honestly and rebuilding the committee around the answers.