How to establish an AI governance committee

Most AI governance committees fail in one of two ways. They meet monthly, debate principles, and take a quarter to approve an internal summary. Or they never meet, and every team invents a different rule. The useful committee is small, has a written mandate, and is measured on time-to-yes for low-risk work as much as on blocks for high-risk work.

This is how to stand that group up without a 40-page charter. It sits on the same engineering backbone as AI governance: a living model inventory, risk tiers, a secure AI gateway, and a light NIST AI RMF map. The committee does not replace those artifacts. It owns them. Discover what is running. Risk-tier it. Implement guardrails in the environment. Operationalize through this group so the paved road stays shorter than the dirt path.

Score the group against the AI governance checklist. The company frame is the enterprise AI governance framework.

Give the committee a mandate that includes speed

Write one page. If the mandate is only "oversee AI risk," you will get oversight without a queue. Name the outcomes: an inventory that is current, a tier rubric people can apply without a meeting, low-risk approvals in days, high-risk work gated, an incident path that has been drilled.

The mandate should say the committee:

• Owns the living inventory (owner, data class, risk tier, last eval) and the approved-tool list.
• Owns the tier rubric and the exceptions.
• Delegates low-risk decisions to a named owner or a working chair so they do not wait for the next full meeting.
• Escalates high-risk (restricted data, customer-facing, write-backs) to security and legal seats that are already named.
• Does not own model research, vendor marketing, or "AI strategy" slides.

Yes/no:

• A low-risk internal draft has a published target measured in days, and someone reports that number.
• A high-risk write-back cannot be approved by the business owner alone.
• The committee can say no, and can say yes. A group that only delays is not governance.

NIST GOVERN is this mandate. It is not a values statement. It is who may start, stop, and promote a system.

Seat the people who can stop a system, then keep the room small

A useful default is six to eight people, not a town hall. You need a chair who will run a queue, an engineering or platform owner who runs the gateway and inventory, security, legal or compliance, and two business owners who actually use AI in production. Add a data owner if you have one. Do not add every VP who wants to be on the invite.

Roles that must be named, as people:

• Chair: owns the agenda, the target time for low-risk, and the exception log.
• Inventory owner: can produce the register this week.
• Security seat: can block a data class or a vendor path.
• Legal or compliance seat: can block a customer or regulatory exposure.
• At least one business owner who will be held to the same rubric they apply to others.

Yes/no:

• Each role has a deputy. The review happens if the sponsor is out.
• Vendors and implementers may present. They do not vote.
• A steering committee that already exists can host this as a standing agenda only if it will take decisions in the room. If it cannot, spin a working group with authority and report up.

The owner of a system is still the person on the inventory row, not the committee. The committee is the second pair of eyes when the tier requires it, and the body that keeps the rubric consistent.

Publish a three-tier rubric so most work never needs a meeting

The committee's best work is the rubric that lets teams proceed without them. Three tiers are enough.

• Low: public or internal non-sensitive input, human reads the output, no write-back, approved tool. Owner can approve. Logged. Target: days.
• Medium: confidential business data, internal decision support, human still signs. Owner plus security or the chair. Eval or a named reviewer. Company tenant only.
• High: restricted data, customer-facing output, or any write into a system of record. Full path: gateway, eval before promote, human-in-the-loop on writes, legal as needed. No personal accounts.

Yes/no for the rubric:

• It uses data class, audience, blast radius, and write permission — not sponsor rank.
• Changing a tier is recorded.
• The same rubric applies to sanctioned systems and to shadow AI findings. Brand name is not a tier.

Publish the rubric where employees already look. A committee that hides the rules will be bypassed. The paved road has to be the short one.

Run a queue, not a book club

Cadence is a standing intake, not a salon. Weekly or twice-monthly for the working chair is enough if low-risk is delegated. Full committee monthly is enough if the packet is the inventory, not a strategy deck.

Every item in the queue should be one of:

• New use case: proposed tier, data class, owner, tool, write-back or not.
• Tier change or exception, time-boxed.
• Shadow finding: pave or kill.
• Incident or near-miss: update eval and, if needed, the rubric.
• Vendor or model change that affects an existing row.

The packet for each item is short: inventory fields, data path (including what leaves the tenancy), eval status, and the ask (approve, restrict, retire). If the packet is a slide narrative, send it back.

Yes/no:

• Time-to-first-response for low-risk is tracked.
• Items do not sit until the next quarter because the meeting ran long on principles.
• Decisions are written back to the inventory the same day: keep, restrict, retire, or exception with an expiry.

This is MAP and MANAGE in a calendar. MEASURE (logs, eval) should already exist on the row. If they do not, the decision is "not yet," not "yes and we will add logging later" with no owner.

Delegate low-risk and staff high-risk so the committee unblocks instead of hoards

Unblocking in days is a design choice. It fails when every prompt change waits for the full room. It also fails when high-risk writes are rubber-stamped in Slack.

Delegation that works:

• Low-risk: owner plus the published rubric. The chair audits a sample monthly.
• Medium-risk: owner plus security or chair, async, with a two-to-five-business-day target you actually hit.
• High-risk: scheduled review with security and legal, eval attached, write-back path named, rollback named.

Yes/no:

• A team can find the intake form and the target times without asking Slack.
• Exceptions expire. "Just this vendor demo" without an owner and a date is still shadow.
• The committee reviews its own cycle time. If low-risk is taking weeks, the rubric is not being used or the gateway path does not exist.

If the official path is slower than a personal chatbot, people will keep the dirt path. The committee's job includes making the official path real: approved tool, logged gateway, named owner. That is implementation in their environment, not a memo.

Operationalize with artifacts, not another charter revision

After the first month, the test is whether the artifacts move without the original sponsor. Operationalize means:

• Inventory last-reviewed dates are not older than the cadence.
• Gateway logs can be pulled for a named service without a vendor favor.
• Eval records exist for high-risk promotes.
• Incident path has been drilled once.
• Training is the two lists (tools, data classes) and two examples, delivered by the business owners, not a lunch on the future of work.
• New AI features inside software you already bought arrive as discover items.

Yes/no:

• You can show last month's decisions and the cycle time for low-risk.
• Shadow findings are on the register, paved or closed.
• NIST mapping is a one-page crosswalk to these artifacts (GOVERN mandate and owners, MAP inventory and tiers, MEASURE logs and eval, MANAGE incidents and retirements). No second binder.

When those are true, you have a committee. When they are not, you have a meeting. If you want the engineering side — gateway, inventory, tiers, NIST-mapped deliverables — so the committee has something to operate, talk to an engineer.