An AI steering committee usually starts with the right people in the room. The CIO is there. Legal is there. Security, HR, finance, and a few business leaders. The charter says the group will guide adoption, manage risk, and identify value.
Then someone asks whether a sales team can use a new tool with customer call transcripts. Everyone has an opinion. Nobody knows who can say yes. The request goes to the next meeting. The team buys the tool on personal cards or gives up.
The committee lacks decision rights.
An AI steering committee has a narrow job: make the cross-company decisions that departments cannot make alone, then leave each department to run its work. Its charter should name the decisions, the person who can make each one, the information they need, and how quickly an answer arrives. Without that, a committee is a calendar event with an AI label.
The committee should own the choices that cross departments
Most AI work belongs with the team doing the work. A marketing leader should decide whether a writing workflow is useful. A finance leader should decide whether a forecasting output is good enough to use. A central committee cannot review every prompt, choose every use case, or run a training program for every team. It will become the bottleneck it was meant to prevent.
Its job begins where one team’s choice creates a cost, risk, or dependency for the rest of the company. The choices are usually few.
| Decision | Accountable owner | What the committee decides |
|---|---|---|
| Approved tools and plan tiers | CIO or technology leader | Which tools can handle company work and when a new request needs a central review |
| Data and autonomy limits | Security, privacy, and the executive accountable for risk | Which data may enter a tool, when an agent needs human review, and when a workflow is off-limits |
| Shared platform and integration rules | Technology leader | Which systems may connect, who administers them, and what monitoring is required |
| Workflow ownership | Business leader | Who owns the output, accepts exceptions, and reports whether the work is better |
| Portfolio priorities | Executive sponsor | Which cross-functional investments get funding and which experiments end |
A role description says who participates. A decision-rights document says whether security can block a customer-data use case, whether it advises the business owner, and how a disagreement gets resolved. The answer needs a name.
Microsoft’s current guidance for agent centers of excellence makes the same split plainly: the central group owns standards, risk tiers, release gates, and monitoring rules; domains own priorities, quality, day-to-day operation, and value tracking inside those rules.1 That boundary keeps governance close to the choices that need it without making every low-risk workflow wait for a committee.
A charter needs five sentences that produce an answer
The usual charter lists admirable goals. Enable innovation. Reduce risk. Share best practices. Those are outcomes. They do not tell a director what happens when a department wants to connect an AI tool to a system of record next Tuesday.
The useful charter is less impressive and more specific. It says:
The committee approves the company tool list and reviews requests that touch restricted data, a system of record, or an unattended action. The business leader owns the use case and its result. Security and privacy set the controls for the stated risk tier. The executive sponsor decides unresolved trade-offs between business value and risk. Requests receive an answer in ten business days, with a written reason and an owner for the follow-up.
That is enough to begin. It gives someone the authority to approve, someone the responsibility to run the work, and an escalation when those people disagree. The answer can be no. A fast no is far better than a request that drifts for a quarter.
NIST’s AI Risk Management Framework calls for roles, responsibilities, and lines of communication to be documented and clear across the organization, with executive leadership responsible for deployment-risk decisions.2 A policy document alone does not settle the decision. When no one can tell a team who decides, the team either waits or builds around the process. Both outcomes create the risk the committee was supposed to manage.
The business owner has to survive the meeting
One missing name causes more trouble than the others: the owner of the workflow.
A committee can approve Claude, Copilot, or any other tool. It cannot decide whether a customer-support summary is accurate enough for a manager to use, whether the approval loop catches bad output, or whether the new method saves time after the novelty wears off. Those are business decisions. They belong to the leader receiving the output.
That leader needs to be named before a workflow is treated as real. They accept the result, name the human review point, carry the cost in their budget, and say whether the work should continue. This is the same distinction behind a useful AI champion job description: a champion can improve and document a method, while the business owner remains accountable for the result.
The verification test helps separate work ready to move from work that only sounds ready. A workflow with clear source material, a fast quality check, and a contained error path can run under a light review. A workflow making an employment decision, changing a customer record, or committing money needs a stronger control and a clearer escalation. The committee should define those risk tiers once. It should not rediscover them in every meeting.
The policy, portfolio, and risk register need one operating rhythm
An AI policy is where employees learn the boundary. It needs approved tools, off-limits data, a named owner, and a short request path. A one-page policy works because it answers the question a person has while they are doing the work.
The committee is where that policy changes when reality changes. A new tool enters the approved list. A connector needs a restriction. An unattended workflow needs an owner. A department reports that a supposedly useful tool has no active users. These are policy and portfolio decisions, so they belong in one regular review rather than a series of emergency meetings.
The review can stay short when the inputs are real: a list of tools and active users, new requests by risk tier, the production workflows with named owners, and incidents or exceptions since the last meeting. The shadow AI diagnosis belongs here too. Unapproved usage is evidence that a need or request path is missing. It is not a reason to turn every employee into a suspect.
For a director, the board-ready sentence is straightforward: “We have a central group that owns the tool, data, and risk boundaries. Each business workflow has a named owner who accepts the result and reports the value.” That is more useful than saying there is an AI steering committee. The board already knows what a meeting is. It wants to know who can decide.
Footnotes
-
Microsoft, “Define roles, responsibilities, and decision rights”, updated July 2026. Its guidance distinguishes central standards and guardrails from domain ownership of priorities, quality, operation, and value tracking. Last verified August 19, 2026. ↩
-
NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), GOVERN 2.1–2.3. It calls for clear roles and communication, accountability structures, and executive responsibility for AI risk decisions. Last verified August 19, 2026. ↩