To set up an AI governance committee, write a one-page charter that defines its mandate and decision rights, appoint a small cross-functional membership with an executive chair, assign responsibilities in a RACI, and fix a cadence: a monthly working meeting, a quarterly risk review and an annual policy refresh. The committee decides what is allowed, who approves high-risk AI use and what risk the organization accepts. It does not enforce those decisions by hand. Enforcement belongs in a control plane that applies policy to every AI agent at runtime and produces the inventory, incident and audit data the committee reviews. Without that link, a committee produces policies nobody can show are followed.
Why a committee, and why now
AI agents have moved from experiments to production systems with credentials, tool access and budgets. That shifts AI from an innovation topic to an operational risk topic. Three pressures usually trigger a committee:
- Accountability gaps. Nobody can say who owns a given agent, who approved its access, or who decides whether it may act without a human.
- Framework expectations. The Govern function of the NIST AI Risk Management Framework expects defined roles, responsibilities and accountability structures for AI risk. ISO/IEC 42001 expects top management to establish an AI policy and assign roles. See ISO 42001 for AI management systems.
- Board questions. Directors now ask how AI risk is governed. Someone has to own the answer, and our post on board reporting on AI risk covers what they expect to see.
A committee is not the only model. Small organizations can assign AI governance to an existing risk or security committee. The test is simple: is there a named body with authority to say no to an AI use case? If not, you need one.
Step 1: Write the charter
Keep the charter to one page. Longer charters are rarely read. It should answer six questions.
| Charter element | What to write | Example |
|---|---|---|
| Mandate | Why the committee exists | "Ensure AI systems are used safely, lawfully and in line with company risk appetite." |
| Scope | Which AI is covered | Internal agents, AI features in products, third-party AI tools with access to company data |
| Decision rights | What it can approve, reject or require | Approve high-risk use cases; set AI policy; require controls before go-live; order suspension of an agent |
| Membership and quorum | Who sits on it and how many must attend | Chair plus five standing members; quorum of four including the chair |
| Escalation | Where decisions go when risk exceeds its authority | Executive risk committee, then the board |
| Reporting | What it reports, to whom, how often | Quarterly AI risk report to the executive team; annual summary to the board |
Two decisions in the charter matter most. First, risk tiering: define what makes an AI use case high-risk (autonomous actions, access to personal or financial data, customer-facing output, regulated domain). Only high-risk cases should reach the committee; the rest follow a standard path. Second, suspension authority: name who can stop an agent in an emergency without waiting for a meeting.
Step 2: Choose members
Keep the standing group small enough to decide. A typical composition:
- Chair: an executive with budget authority, often the CTO, CISO, CRO or Chief Data Officer.
- Security: owns threat models, access control and incident response for agents. See AI agent governance for CISOs.
- Legal or privacy: owns regulatory interpretation, data protection and contractual terms with AI vendors.
- Compliance or risk: owns the risk register, framework mapping and audit readiness.
- Engineering or platform: owns how policy becomes technical controls.
- Data: owns data quality, provenance and model evaluation.
- Business representative: speaks for the teams that want to use AI, so the committee does not become a blocker.
Invite use-case owners to present their case when it is on the agenda. They should not be standing members.
Step 3: Build the RACI
The most common failure is confusing who decides with who operates. The RACI below separates them.
| Activity | Committee | Security | Legal / Privacy | Engineering / Platform | Use-case owner |
|---|---|---|---|---|---|
| Set AI policy | A | R | R | C | I |
| Define risk tiers | A | R | C | C | I |
| Approve high-risk use case | A | C | C | C | R |
| Maintain AI inventory | I | C | I | A / R | R |
| Implement guardrails and access policy | I | A | C | R | C |
| Approve individual high-risk agent actions | I | C | I | C | A / R |
| Respond to AI incident | I | A / R | C | R | C |
| Suspend an agent in an emergency | I (informed after) | A / R | I | R | I |
| Produce quarterly risk report | A | R | C | R | I |
R = responsible, A = accountable, C = consulted, I = informed. Adjust the names to your organization, but keep one A per row.
Note the row for individual agent actions. The committee sets the rule ("payments above a threshold need human approval"). It does not approve each payment. Day-to-day approvals belong with the use-case owner, through a human-in-the-loop step built into the workflow.
Step 4: Set the cadence
| Cadence | Meeting | Agenda |
|---|---|---|
| Monthly | Working session (60 min) | New high-risk use cases, open exceptions, incidents since last meeting, inventory changes |
| Quarterly | Risk review (90 min) | Risk register, metrics trends, framework and regulatory updates, report to executives |
| Annually | Policy refresh | Review charter, AI policy, risk tiers and the RACI; reassess maturity |
| Ad hoc | Incident or urgent decision | Convened by the chair within 48 hours |
Regulatory tracking belongs in the quarterly review. The EU AI Act is a good example: the Digital Omnibus, adopted as Regulation (EU) 2026/1744 in July 2026, moved the high-risk application dates to 2 December 2027 and 2 August 2028, so the committee should record which dates it plans against and revisit them when guidance changes.
Step 5: Decide what the committee looks at
A committee that only reads slides does not govern. Give it a standard pack with data from systems, not self-reported spreadsheets:
- Inventory: number of AI agents by risk tier, new agents since last meeting, agents with no named owner, unsanctioned tools found. See shadow AI.
- Controls: share of agents behind guardrails, share of high-risk actions gated by approval, open policy exceptions.
- Incidents: guardrail blocks and redactions, policy violations, suspensions, with trend lines.
- Cost: AI spend by team and agent, against budget.
- Evidence: the audit trail for the period, with any gaps or integrity-check failures called out.
Our post on executive reports for AI governance shows how to turn these into a one-page summary.
Setup checklist
Common failure modes
- Too large. Twelve members means no decisions. Keep it to seven or fewer.
- Approval bottleneck. If every AI use case needs committee approval, teams route around it. Tier the risk and delegate the low tiers.
- Policy without enforcement. A rule that lives in a PDF is a hope. Every policy decision should map to a technical control or a named manual check.
- No inventory. You cannot govern agents you do not know about. The inventory comes before the first meeting.
As the committee matures, it moves from reviewing individual use cases to reviewing metrics and exceptions. Our AI governance maturity model describes those stages.
Where Praesidia fits
The committee decides policy. Praesidia is a control plane that enforces it and feeds the committee its data, in three steps:
- Discover: an inventory of AI agents, with OpenTelemetry-based discovery and shadow MCP server detection, so the committee reviews the real estate rather than a self-reported list.
- Secure: guardrails that block, redact or warn, MCP tool scoping, a BYOK gateway, human-in-the-loop approvals and a per-agent kill switch, which turn committee decisions into runtime controls.
- Prove: a signed, tamper-evident audit log and executive reports that feed the quarterly pack and the board report.
Praesidia does not replace the committee's judgment. It closes the gap between what the committee decides and what agents actually do. For the wider operating model, see AI agent governance for enterprises and our AI governance guide.