What Does an AI Steering Committee Decide?

What does an AI steering committee do?

An AI steering committee decides which AI initiatives go ahead and under what controls. That covers the whole lifecycle: intake, approval, risk assessment, monitoring, remediation and retirement. A committee that writes policy but never sets the rules use cases are judged by is not steering anything.

Many employers have stopped at the policy. Littler Mendelson's 2026 employer survey found 68% of employers have a formal AI governance policy, yet only 55% have a formal review process for AI tools.² A policy states what the company expects. It does not say who looks at a proposed use case, which criteria it is judged against or who has the authority to stop it.

The committee owns that review at every stage, even where it does not make each call itself. At intake and approval, someone decides whether a use case goes ahead and which controls come with it. At risk assessment, someone decides whether the risk is acceptable. Once the system is live, monitoring, remediation and retirement each end in a decision too: keep it running, fix it or switch it off.

Those rulings separate an AI governance committee that steers from one that only publishes. Call it a steering committee, an AI council or a steerco. Judge it by the decisions it holds over real AI work, not by the documents it has approved.

What decisions should an AI steering committee make?

It should make the decisions no single team can make alone: the criteria an AI use case must meet, the controls around data and experimentation and which cross-functional governance initiatives go ahead. One VP in the public sector in our network directed cross-functional AI and data councils that put governance initiatives in place, improving data quality and adoption metrics by 30%. The work those councils ruled on crossed functions, and that is the test for what belongs on a committee's agenda.

Review criteria define what every use case must show before it is approved, so they bind every function that brings AI work forward. Controls around data and experimentation work the same way. Littler found only 54% of employers restrict what information can be entered into AI tools,³ and a rule like that means nothing unless it holds across the company. Cross-functional governance initiatives, by definition, need more than one function to agree.

The committee should not sit in the approval path for every individual use case. Its role is to set the standards and ratify the initiatives that cross functions. Once the criteria exist, approving a single use case means checking it against rules the committee has already agreed, and that work belongs to whoever runs the process day to day.

This split keeps the committee's time for the calls only a committee can make. It also leaves a question: if the committee should not approve every use case, who should?

When does one accountable leader beat an AI council?

One accountable leader is better when the problem is how fast AI work gets approved. One VP in healthcare in our network redesigned the AI governance intake process and cut approval time from four to five weeks to about one week. Keep a committee for the decisions that need several functions to agree, and give one leader everything else.

Horses for Sources reports that most enterprises are still gridlocked in governance committees and change management debt.⁴ The people side of that debt is its own subject, covered in our analysis of why most AI transformations stall. The governance side has a structural fix.

A committee in the approval path becomes the queue. Every use case waits on a group that has to convene and agree before anything moves. One owner of intake removes that queue by applying agreed criteria as use cases arrive. The healthcare redesign changed intake, the point where every use case enters the process, and that is the step one leader can own outright.

The committee still has a job. The criteria, the data and experimentation controls and the initiatives that cross functions all need several functions to agree. Give the committee the rules and one accountable leader the flow of work through them. If approvals are slow and a committee owns intake, that is the bottleneck to fix, and the charter is where the split gets written down.

What should an AI steering committee charter include?

A charter should name four things: the decisions the committee holds, the review criteria every use case must meet, the one leader who runs the process day to day and a target for approval time. One VP in financial services in our network built an AI review process and ran more than 300 use cases through it, cutting average approval time from three to four weeks to one to two weeks, about 60%, without loosening the review criteria.

That case is the argument for writing both the criteria and the owner into the charter. The speed came from the process while the criteria stayed where they were.

Each element does a specific job:

• The decisions the committee holds. Listing them tells every team what reaches the committee and what does not, so ordinary use cases stop waiting on it.
• The review criteria. These are the standard every use case is judged against, and the part that should not move when the process speeds up.
• The one leader who runs the process. A named owner keeps the committee from becoming the queue. Where that person sits is a separate decision, covered in our guide to the right AI leadership reporting structure.
• A target for approval time. Both the healthcare and financial services leaders measured their results in approval time. A target in the charter gives the committee a number to hold its owner to.

Leave one out and the gap shows: with no list of decisions, everything drifts to the committee; with no criteria, every approval is argued from scratch; with no owner, nobody is accountable for speed. Naming that owner is a hiring decision, and it gets harder when there is no council at all.

Who should run AI governance without an AI council?

Without a council, hire a leader who can run a review process and bring other functions along on their own. AI governance job postings we analyzed treat making the case for change and handling resistance as a minor point at both director and VP level, while VP-level leaders in our sample give it moderate weight on their resumes. Test for it in interviews rather than following the job description's lead.

With no council to share the persuasion, the single leader carries all of it. Every function that has to accept the review criteria, live with the data controls or wait on an approval has to be brought along by that one person. Yet employers' postings put less weight on this skill than VPs in our sample put on it themselves.

A more senior title does not settle the question. C-suite resumes in our sample, which include founders and chiefs of small companies, also treat making the case for change and handling resistance as a minor point. The title alone does not tell you whether a candidate leads with this skill.

So write it into the brief yourself. In interviews, ask candidates for a specific time they brought a reluctant function along on a governance decision, what the objection was and what changed. A candidate who has run a review process across functions should be able to answer with a real case.

Give the committee the rules and one leader the queue

An AI steering committee earns its place by holding real decision rights over AI work that crosses functions: the review criteria, the data and experimentation controls and the initiatives no single team can approve alone. Running approvals at speed belongs to one accountable leader, as the healthcare and financial services cases illustrate. Hiring that leader means testing for the ability to bring other functions along, a skill employers' postings treat as minor. If you need someone running the review process before a permanent hire is in seat, fractional AI leadership is one way to put an owner in place.