Once an organization has more than a handful of AI use cases, decisions start landing in the wrong inboxes: legal gets asked about model choice, engineering gets asked about acceptable use, and nobody is sure who can approve a customer-facing launch. An AI steering committee fixes the routing. What follows is recommended practice drawn from how enterprises commonly structure these bodies — adapt it to your size and regulatory context with your counsel.
Who belongs in the room
Keep it to six to eight voting members. A workable core:
| Seat | What they bring |
|---|---|
| Executive sponsor (chair) | Authority to make decisions stick; ties AI to business strategy |
| Engineering / platform lead | What is technically true: platforms in use, feature availability, controls actually enforced |
| Security / CISO delegate | Data handling, access control, incident readiness |
| Legal / privacy | Contract terms, regulatory exposure, retention obligations |
| Risk or compliance officer | Risk-tiering consistency, audit evidence |
| Business-line representative(s) | Where value actually comes from; keeps governance grounded in real use cases |
Invite subject-matter guests per agenda item rather than adding permanent seats. In regulated industries, an internal-audit observer is worth the chair.
The decisions the committee owns
The committee should own decisions that are cross-cutting, expensive to reverse, or precedent-setting — and explicitly delegate everything else. A concrete decision list:
Platform and vendor posture. Which routes to Claude are approved — the first-party API, Claude Platform on AWS, Amazon Bedrock, Vertex AI, Foundry — and under what data-handling terms. This is a committee decision because the terms genuinely differ: for the Claude API, Anthropic acts as data processor and states a default of deleting inputs and outputs within 30 days, while on Bedrock and Google Cloud the cloud provider is the data processor and its policies apply. Contractual arrangements such as zero data retention (ZDR) or a HIPAA-ready configuration with a signed Business Associate Agreement are requested through Anthropic's sales or account team — exactly the kind of negotiation a committee should sanction once, centrally.
The risk-tiering rubric and review gates. The committee approves the rubric and the evidence required at each tier; it does not perform every review. High-tier launches come to the committee; low-tier ones are handled by the delegated fast-track path.
Policy and exceptions. Changes to the internal AI use policy, and rulings on exception requests that would set precedent.
Spend guardrails. Not the invoices themselves, but the guardrail structure — for example, whether organization-level spend limits and per-workspace caps are configured on the Claude Console, and who may raise them. (On the Claude API, admins can set a monthly spend limit below the usage tier's cap, and per-workspace limits can only be set lower than the organization's.)
Incident thresholds. What severity of AI incident convenes the committee out of cycle, per the incident playbook.
Cadence: frequent enough to unblock, rare enough to matter
A common pattern that works: monthly one-hour meetings while the portfolio is growing, dropping to quarterly once intake volume stabilizes, plus an asynchronous approval channel so a launch never waits four weeks for a calendar slot. Every meeting should see the same one-page dashboard: new intake requests, launches since last meeting, the inventory delta, exceptions granted, and incidents. If your platform team pulls usage data from the Claude Admin Usage and Cost API, spend and usage by workspace can be part of that dashboard rather than an anecdote.
Where to go next
Write the committee's authority down in a program charter so it survives personnel changes, and stand up the use-case intake process that feeds its agenda. The platform overview is useful pre-reading for the platform-posture decision.