How to Set Up an AI Committee: Members, Decisions and Minutes

An AI committee is the body that decides what the company automates, within what limits, and who answers when something goes wrong. Four to six people, one hour a month, with real decision-making power and minutes that get published. It is neither a forum to discuss news nor a technical review board: if the meeting ends without prioritizing, approving or stopping something, it was not a committee, it was a chat.

We set one up when a company moves from one experiment to three or four agents in production and the uncomfortable questions start: who authorized this agent to write into the ERP? Why was this prioritized over finance? What do we do when it gets something wrong? This article covers composition, cadence, decision criteria and the minutes template we use — and when setting up a committee is a mistake.

What exactly does an AI committee decide?

Four things and nothing more. Everything else belongs to whoever executes, and dragging it into the committee is the fastest way to turn governance into bureaucracy.

1. Prioritization. Which use cases get tackled this quarter and in what order. It is the highest-impact economic decision and the one most often made on instinct when no committee exists.
2. Approving production release and autonomy levels. An agent that suggests is not an agent that executes. Widening its autonomy is a risk decision, not a technical one, and it needs an owner.
3. Risks and incidents. Reviewing what failed, deciding whether to fix, restrict or retire, and recording it. Without this, incidents get resolved privately and nobody learns.
4. Budget and retirement. Approving the period's investment and — the part everyone forgets — switching off what is not delivering. Zombie agents cost maintenance and pollute the data.

What it does NOT decide: how anything is implemented, which model is used, how the agent's instructions are written, or integration detail. Those belong to whoever builds. A committee reviewing prompts has lost the plot and, worse, has slowed down the team that was actually delivering.

Who should sit on it?

Four to six people. Above six, the meeting stops deciding and starts reporting. The profiles that work:

Two rules we always apply. First: the sponsor genuinely attends. A committee without authority to spend and unblock is useless, and it shows by the second meeting. Second: the case owner rotates with the agenda. If the quarter is about finance, finance comes — which avoids the classic committee of five executives opining on a process none of them runs.

In companies under 50 people this compresses to three people and works just as well. What does not change is the split between who decides, who builds and who supervises, which is the backbone of the AI-First operating model.

How often should it meet?

Monthly, 60 minutes, with the agenda locked 48 hours ahead. That cadence sustains momentum without eating the leadership calendar. During an active transformation — first six months, several projects at once — moving to fortnightly makes sense, then back to monthly once the rhythm stabilizes.

Add a longer quarterly review, 90 minutes, with different content: results against what was promised, the case pipeline for next quarter, and switch-off decisions. That session is what connects the committee to company planning and stops AI living in a lane parallel to the budget.

Nothing waits between meetings. Serious incidents escalate to the sponsor and security immediately, and the committee reviews them afterwards. A governance model that requires waiting for the monthly meeting to react to an agent doing damage is a badly designed model.

How are use cases prioritized?

With three numbers per case and a short conversation — not a twenty-criteria matrix nobody fills in. Score 1 to 5:

• Estimated annual value in hours freed or euros. Hours × loaded cost (€25-35/hour for administrative profiles). If nobody can estimate it, the case is not ready.
• Effort: weeks of development and number of systems to integrate. For an SMB, a custom agent runs €15,000-40,000 and 4-8 weeks; that is the reference frame.
• Risk: what happens when it gets it wrong. An error in a draft email is an annoyance; an error in a payment is a problem.

The decision rule: take high-value, low-effort, low-risk first, and cap work in progress at two or three simultaneous cases. The most common cause of failure we see is not picking the wrong case — it is opening seven at once and finishing none.

Always record why a case was rejected. After a year, the rejected list with reasons is the committee's most useful asset, because half of them come back when a condition changes — an API appears, costs drop, volume shifts — and then the decision takes two minutes.

How is increased autonomy approved?

Through explicit gates, not gut feel. An agent passes through three states and the committee approves each jump with evidence in front of it:

1. Shadow. The agent works but publishes nothing: classifies, drafts, proposes. Its output is compared with the human's for two to four weeks.
2. Assisted. It executes with prior human approval on every action. You measure the unchanged-approval rate; when it holds high for several weeks, the jump gets proposed.
3. Bounded autonomy. It executes alone within written limits: case types, maximum amounts, time windows — always logged and reversible.

What the committee must demand at each gate: the measured accuracy metric, the proposed limits in writing, who supervises day to day, and how it gets rolled back. The specific permissions — what the agent can read and write in each system — are documented separately, at the level of detail we set out in AI agent governance and permissions.

Minutes template (one page, always the same)

The minutes are what turn a meeting into governance. One page, identical format every month, published where staff can read it:

• Date, attendees and absences.
• Portfolio status: agents in production, in pilot and queued, one line each.
• Period metrics: hours freed, automatic resolution rate, incidents.
• Decisions taken, each with an owner and a deadline. A decision without a name and a date is not a decision.
• Cases approved, rejected and why.
• Open risks and who is watching them.
• Next review.

On compliance, one dated note: as of August 2026, the EU AI Act's application calendar has been amended during the year by the Digital Omnibus package, which pushed back part of the high-risk system obligations while the rest of the regulation — transparency, AI literacy and prohibited practices — keeps its schedule. Since the framework is still moving, do not pin dates in your plan without checking them with your legal advisor. What you can do today is write down who supervises each agent and what training the people using it have had.

When you should NOT set up an AI committee

If you have fewer than 30 people and one agent in production, do not set up a committee: set up a 20-minute monthly review between the manager and whoever builds. Governance cost has to be proportional to what is governed, and a formal committee in a 15-person company slows things down without protecting anything.

Do not set one up if it will have no teeth either. Three symptoms of degeneration: it meets and decides nothing; its decisions go unimplemented and nobody notices; or it has become a permission gate teams route around. If any of the three appears, shrink it to three people and half an hour, or dissolve it and come back later.

And a warning on composition: a committee made only of executives and IT decides about processes it does not run. Having whoever does the work in the room for the discussion is the difference between prioritizing well and prioritizing what sounds best in a slide. How these roles fit the wider structure is covered in the AI-First org chart and roles.

If you want to set it up with people who have done it before — and who start from a process diagnosis rather than an org chart — that is how we work at our AI consulting practice.

Frequently asked questions

Who should chair the AI committee?

The executive sponsor — usually the CEO or CFO — not the head of IT. The reason is practical: the committee's decisions are business decisions (priority, budget, acceptable risk) and need someone with authority to unblock resources. Chaired by IT, it tends to become a technical board and prioritization drifts toward whatever is easy to build.

Do we need a full-time head of AI?

Below 200 employees, almost never. A part-time owner who already knows the processes — typically operations or transformation — with external technical support works better. Creating a new role before you have three or four agents in production usually produces a title with no authority and no agenda.

How do we stop the committee from slowing projects down?

By defining what does not go through it. Set a threshold — low-risk cases under a certain budget, for example — that the owner can approve directly and report afterwards. The committee should accelerate the big decisions, not toll every one of them.

What if our external vendor sits on the committee?

They can attend and contribute estimates, but they should not vote. Whoever builds has a natural conflict of interest in deciding what gets built. The pattern we recommend: the vendor presents effort and alternatives, leaves the room for the prioritization decision, and returns with the assignment.

How often should we review what is already live?

Monthly in the portfolio status and in depth every quarter. The quarterly review must explicitly include the switch-off question: is this agent still delivering what it promised? It is the part almost no committee does, and the one that keeps operations cleanest.