AI Governance Committee Charter: Template and RACI

An AI Governance Committee is the accountable body that owns your organisation's AI Management System (AIMS) under ISO/IEC 42001 Clause 5, deciding which AI systems get built or deployed, under what controls, and when they must be stopped. This guide gives you the full charter text, a downloadable template, and a RACI matrix that maps every AIMS decision to a single accountable role, aligned with ISO 42001, cross-referenced to ISO/IEC 27001:2022, and mapped to EU AI Act Articles 26 and 27. It is written for two readers at once: the board sponsor deciding whether to stand up such a committee, and the practitioner tasked with running it.

1. What an AI Governance Committee actually does

An AI Governance Committee is the standing body inside an organisation that holds the mandate for the AI Management System. It approves the AI policy, sets the risk appetite for AI use, decides which AI systems can be built, procured, deployed, or shut down, and reports to the Board on the state of AI risk. It is a decision body with named authority, not an advisory forum, not an ethics reading group, and not the same thing as an AI working group where engineers coordinate delivery.

The confusion around this role is worth naming up front, because most organisations already have three or four bodies with overlapping remits. The AI Ethics Board tends to give values-level guidance without decision rights. The Data Governance Council owns data quality and lineage, which touches AI but does not cover model behaviour, procurement, or lifecycle. The Risk Committee sits above the whole enterprise and cannot go deep on any single technology. And the ISMS Steering Committee, if one exists, owns information security under ISO/IEC 27001 but is not chartered for AI-specific concerns like bias, autonomy, or foundation model dependencies.

The AI Governance Committee fills the specific gap: a body with formal authority over the AIMS mandate, at a level of technical depth the Board cannot reach and a level of independence the engineering organisation cannot claim. When an organisation certifies against ISO 42001, this is the body the auditor traces every decision back to. When the EU AI Act deployer obligations bite, this is the body whose minutes show the Fundamental Rights Impact Assessment was reviewed and signed off. When a live AI system misbehaves and has to be paused, this is the body with the standing authority to make that call at speed.

One question worth resolving before you go further: does your organisation actually need a separate AI Governance Committee, or can an existing body absorb the mandate? For organisations already running an ISO 27001 ISMS Steering Committee, extending its scope to cover AI is a legitimate design choice as long as the charter is rewritten to reflect the expanded remit, the membership brings AI competence, and the meeting cadence separates AI decisions from ISMS-only decisions. For organisations with material AI exposure — first-party model development, high-risk deployer status under the EU AI Act, regulated use cases in finance or healthcare — a dedicated Committee tends to work better because the decision volume and technical depth exceed what a shared body can handle.

2. Standards mapping: ISO 42001, ISO 27001, and the EU AI Act

The AI Governance Committee is not named as such in any single standard. What each framework requires is a body with a specific set of responsibilities, and one properly chartered Committee can satisfy several at once. The accordions below map the requirement to the charter clause it corresponds to.

There is one factual guardrail worth stating: ISO/IEC 42001 is not a harmonised standard under the EU AI Act, and certification against it does not confer legal compliance with the Act. What a properly implemented AIMS does is produce the same evidence artefacts an EU AI Act regulator would ask for, in a structure that maps cleanly onto Article 26 and 27 requirements. That is a substantial practical advantage. It is not a legal shortcut.

3. The seven mandatory charter sections

Charters that work look remarkably similar across organisations, and the pattern holds because each section answers a question an auditor, a regulator, or an incoming Committee chair will ask. Skipping any one of these seven creates a specific, recurring audit finding. Each accordion below explains the section, what it must contain, and the failure mode it prevents.

4. Charter template (copy-ready)

The text below is a working charter, written to be adapted to your organisation's specifics — names, regulatory scope, reporting lines — and then approved by whichever body carries chartering authority (typically the Board or its Risk Committee). A downloadable Word version and a PDF version are linked below the template for teams that prefer to edit in document form.

5. The RACI matrix across the AIMS lifecycle

A charter tells you which body decides. A RACI tells you which role does the work, which role is accountable for the outcome, which roles must be consulted before the decision, and which roles need to be informed after. Together they turn ISO 42001 Clause 5.3 (Roles, responsibilities and authorities) and Annex B.3.2 (AI roles and responsibilities) from a compliance clause into a working operating model.

The matrices below use six roles: Board (or Board Risk Committee), AI Governance Committee, CTO / AIMS Owner, Risk & Compliance, Product / Business, and Internal Audit. A downloadable Excel version with additional columns for your CISO, DPO, and vendor management functions is linked at the end of this section.

6. Three-tier governance: how the Committee connects up and down

A single-committee model tends to collapse under its own weight within the first year. The Committee either becomes a rubber stamp for decisions made elsewhere, or it becomes the delivery bottleneck for every AI project in the organisation. The PECB ISO 42001 curriculum describes governance as three connected tiers, and this holds up in practice.

The governance tier is the Board plus the AI Governance Committee. This tier owns policy, appetite, and material decisions. It sets the boundary conditions inside which everyone else operates. Its cadence is slow — monthly at the Committee, quarterly at the Board — because the decisions at this tier are supposed to be durable. Governance-tier questions sound like: what is our position on foundation model dependency, where is our line on autonomous decision-making, what risks are outside appetite regardless of business case.

The steering tier is the CTO or AIMS Owner, plus a working group typically drawn from engineering leadership, product leadership, risk, and information security. This tier translates governance decisions into standards, methodologies, and operating procedures. It maintains the AI system inventory, keeps the risk register live, runs impact assessments, and prepares material for the Committee. Its cadence is weekly to fortnightly. Steering-tier questions sound like: how do we operationalise the new policy, what does the impact assessment look like for this class of system, are we ready to take this deployment to Committee.

The operational tier is product and engineering teams building or running AI systems. This tier does the actual work: builds the model, integrates the vendor system, monitors production, responds to incidents. Its cadence is continuous. Operational-tier questions sound like: is this feature within our authorised scope, do we need to trigger a change review, what does the monitoring dashboard say this morning.

The failure pattern that shows up most often in practitioner engagements is a governance tier and an operational tier with nothing in between. The Committee meets, decides, and hands work to teams who lack the standards, the templates, and the routine cadence to translate the decision into practice. Six months later the Committee is looking at a risk register that hasn't been updated, an inventory that no one owns, and impact assessments written by whoever had time that week. This is what auditors mean when they describe a management system as "documented but not operational."

Standing up the steering tier is often the single highest-leverage investment when implementing ISO 42001. A working group meeting fortnightly, chaired by the CTO or a nominated AIMS Owner, with membership from risk, security, and the two or three business units driving AI adoption, is what makes the Committee's monthly meetings productive. Without it, the Committee spends most of its time asking for updates instead of making decisions.

7. Common charter failure modes auditors flag

The failures below are ones that surface repeatedly during ISO 42001 pre-certification reviews. None of them are exotic; they show up in charters written by capable teams working under time pressure. Each accordion names the failure, the audit finding it produces, and the specific charter language that prevents it.

8. Standing up the Committee in 60 days

The timeline below reflects how this actually happens in practitioner engagements, not the ideal-world sequence. It assumes the organisation has a senior sponsor willing to move, at least one AI use case already in production or advanced pilot, and no pre-existing committee it is politically difficult to disturb. Shorter timelines are possible in small organisations; larger enterprises should double the calendar and expect three to four months.

Weeks 1 to 2 — Mandate and sponsor. The first work is not writing anything. It is securing a chartering authority — typically the Board Risk Committee — and identifying the senior sponsor who will chair. If the CTO is the intended chair, this is the conversation to have first, because a Committee without an engaged chair goes nowhere regardless of how well its charter reads. In parallel, do a light inventory of what AI is already in production and pilot across the organisation. The inventory need not be complete; it needs to be honest enough to tell the Board what it is really governing.

Weeks 3 to 4 — Membership and charter draft. Identify the six or seven role-holders who will be voting members and the two or three standing invitees. Test the membership against the Section 3 rule (control-function presence in quorum) and the Section 4 rule (someone in the room with real authority to say no). Draft the charter using the template above, but adapt it — do not paste. The clauses that matter most for local adaptation are Section 2 (Scope, especially the exclusions), Section 4 (Decision Rights, especially the escalation triggers), and Section 6 (Reporting line, especially where the Committee sits relative to any existing ISMS Steering Committee).

Weeks 5 to 6 — First meeting and RACI ratification. First meeting agenda should be short and decisive. Ratify the charter. Approve the initial AI system inventory with proposed risk classifications. Ratify the RACI, ideally distributed a week before so members arrive having done their reading. Set the schedule for the next three meetings. Assign the first two or three impact assessments to their responsible parties with due dates. The single most useful test of whether the Committee has traction is whether decisions taken in this meeting produce visible movement by the second meeting. If they do not, the Committee will drift.

Weeks 7 to 8 — First risk review and Board report. Second Committee meeting reviews the first completed impact assessments, updates the risk register based on what those assessments surface, and drafts the first quarterly Board report. The report itself is a leading indicator of whether the Committee is working. If it can name specific decisions made, systems authorised, risks accepted or rejected, and actions in flight, the operating model is stable. If the report reads like a description of the Committee's existence rather than of the work it did, something in the mandate, membership, or cadence needs to change before the next quarter.

Two practitioner observations worth noting. First, the hardest week is week 5 to 6, not the drafting. A charter that looks defensible on paper can collapse in the first meeting if the members do not treat it as binding on themselves, and the chair's job in that meeting is to enforce the charter against the room, not with it. Second, the Committee's authority is established by its first hard decision, not by its charter. The first time it declines to authorise a deployment that a business unit wants, or mandates the suspension of a system that a product owner is protective of, is when the rest of the organisation learns whether the mandate is real. That decision, and how it is handled, is worth more than any number of pages of charter text.

9. Frequently asked questions