Answer box
A good AI governance committee charter is short (two pages), unambiguous about authority, and crosswalkable to a recognized framework — NIST AI RMF GOVERN, ISO 42001 §5.3, and EU AI Act Article 26. The template below is the starting point AccuroAI customers adapt when they need to stand up a committee in weeks rather than quarters. Copy it, customize the six items flagged below, and ratify it at your first meeting. You need a charter an auditor can read in five minutes and a chair can defend in five seconds.
Why most AI governance charters fail
Most committee charters we see fail for one of three reasons — and all three are decisions the drafter avoided making.
They're too long. Charters past two pages stop functioning as governance documents and start functioning as compliance theater. No member reads page seven. No auditor cross-references appendix C. A fifteen-page charter is almost always the output of a working group that could not agree on what to cut.
They're vague about authority. The common failure mode is a charter that says the committee "oversees," "advises," or "recommends" — but never says what the committee can actually approve or block. A committee that can only recommend has no governance power. When a product team wants to ship a high-risk model and the committee objects, what happens? If your charter cannot answer that in one sentence, your charter is decorative.
They don't align to a framework. A charter that doesn't name NIST AI RMF, ISO 42001, or the EU AI Act forces every future auditor to invent a crosswalk from scratch. The fix is one paragraph naming the frameworks and clauses you align to. We cover the mapping in our unified AI compliance crosswalk.
The charter template — copy and adapt
What follows is a working charter you can paste into your governance repository and edit. It is deliberately compact. Blockquoted passages are language you can use verbatim; the surrounding notes explain what to change and why.
1. Purpose
Open with one paragraph naming the committee, declaring why it exists, and tying it to enterprise risk management. Avoid mission-statement language.
The AI Governance Committee (the "Committee") is established by the Audit Committee of the Board to oversee the responsible development, procurement, deployment, and retirement of artificial intelligence systems across [Organization]. The Committee exists to ensure AI systems are deployed in a manner consistent with applicable law, internal policy, and the organization's tolerance for risk, and to provide assurance to the Board through periodic reporting.
2. Scope
Scope is where most charters quietly fail. State explicitly what is in and out.
In scope:
- All AI and machine learning systems developed, procured, fine-tuned, or deployed by or on behalf of the organization, including systems embedded in third-party software.
- Generative AI tools and agents used in production workflows, regardless of vendor.
- Models that produce decisions affecting customers, employees, or regulated transactions.
- Pilots and proofs of concept that touch production data or regulated data classes.
Out of scope:
- Personal consumer AI tools used by employees on personal devices without organizational data.
- Pre-deployment academic research conducted without production data.
- Vendor-managed AI features inside SaaS tools that have already cleared third-party risk review and do not process restricted data classes.
3. Authority
This section determines whether your committee is real. Name what it approves, what it can deny, and where escalation goes.
The Committee has authority to approve, condition, defer, or deny the deployment of any AI system within scope. Approval is required prior to production deployment of any AI system classified as high-risk under the organization's AI Risk Classification Standard. The Committee may impose remediation requirements, suspend a deployed system pending review, or refer a matter to the Audit Committee for resolution. Decisions of the Committee are binding on functional leadership; disputes escalate to the Audit Committee of the Board.
If your committee cannot stop a deployment, say so honestly — but understand that you have an advisory body, not a governance committee, and an auditor will treat it accordingly.
4. Membership
Keep the voting body small enough to make decisions. We recommend six to eight voting members. Anyone else attends as a non-voting participant.
Voting members (required):
- Chief Information Security Officer (Chair, by default)
- Chief Information Officer or Chief Data Officer
- Head of Governance, Risk, and Compliance
- Chief Privacy Officer (or Data Protection Officer)
- General Counsel or senior legal designee
- Head of Engineering or Head of Product
Non-voting standing attendees:
- Internal Audit (observer)
- AI/ML technical lead
- Business unit representative for the matter under review
For the deeper view of what each role actually does, see the operational reference for committee roles and responsibilities.
5. Meeting cadence
Specify cadence, quorum, and reporting rhythm. Don't bury this in an appendix.
The Committee meets monthly. A quorum consists of four voting members, including either the Chair or the Vice Chair. The Committee reports to the Audit Committee of the Board at least quarterly, and on demand for material incidents. Ad-hoc meetings may be called by the Chair with twenty-four hours' notice for time-sensitive approvals.
6. Decision-making
Choose the voting rule in advance. The two rules that work in practice:
Routine decisions, including risk classification, policy revision, and standard deployment approvals, pass by simple majority of voting members present. Decisions to override a denial issued by the Chief Information Security Officer, the Chief Privacy Officer, or General Counsel require unanimous agreement of voting members and concurrent notification to the Audit Committee. Tie votes result in deferral and escalation.
The unanimity requirement on overriding the CISO, CPO, or GC is the most important sentence in the charter. It is what prevents the committee from drifting into a body that rubber-stamps business pressure over risk objections.
7. Responsibilities
Be concrete. Auditors sample against a defined responsibility set. Vague verbs ("oversee," "promote," "support") give them nothing to test.
- Maintain and approve the organization's AI policy, AI Acceptable Use standard, and AI Risk Classification Standard.
- Approve or deny the deployment of all in-scope high-risk AI systems prior to production release.
- Review the AI inventory at least quarterly and confirm completeness with Internal Audit.
- Review every reportable AI incident, including model drift events, prompt injection incidents, data leakage incidents, and unsafe output incidents, and approve remediation plans.
- Approve third-party AI vendor onboarding above an agreed materiality threshold.
- Review external regulatory developments and recommend changes to policy or controls.
- Report to the Audit Committee quarterly with a written record of decisions, incidents, exceptions, and outstanding risks.
This list maps directly to the seven concerns the board will probe — covered in seven questions the board will ask the CISO about AI.
8. Framework alignment
One paragraph. Name the frameworks and the clauses. Future auditors thank you.
The Committee is established and operates in alignment with NIST AI Risk Management Framework function GOVERN-1.1 (organizational policies, processes, procedures, and practices); ISO/IEC 42001 §5.3 (organizational roles, responsibilities, and authorities); and EU AI Act Article 26 (deployer obligations) where the organization acts as a deployer of high-risk AI systems. The Committee's structure also reflects the integrated governance principles of COSO ERM (2017).
9. Conflict resolution
State what happens when the committee cannot agree. Most charters skip this. Skipping it means your committee will eventually freeze on a contentious decision, and there will be no documented path forward.
If the Committee cannot reach a decision within two consecutive meetings, the Chair shall escalate the matter to the Audit Committee of the Board with a written summary of positions. Pending escalation, the underlying AI activity remains in its current state — systems already deployed may continue operating under existing controls; systems not yet deployed shall not be released.
10. Review cadence
Charters drift. Set the review rule explicitly.
This Charter shall be reviewed by the Committee annually, and additionally upon any material change in applicable AI regulation, enterprise risk appetite, or organizational structure. Material amendments require approval by the Audit Committee of the Board.
Six items you must customize before adopting
Every charter we've seen succeed has been edited in at least these six places. Skip the customization pass and you have a generic document, not a governance instrument.
- Scope language. The in-scope and out-of-scope bullets are defaults. Adjust them to match your data classification taxonomy and your definition of "production." If you run regulated workloads, expand in-scope explicitly.
- Authority limits. Decide honestly whether your committee can block deployments. If the answer is no, edit Section 3 to say "recommend" — and plan how you will get to "approve" within twelve months.
- Audit committee referent. Replace "Audit Committee of the Board" with the actual board committee that owns risk in your organization. In some firms it's the Risk Committee; in smaller firms it may be the full board.
- Framework selection. Section 8 names three frameworks. Cut any that don't apply (EU AI Act is irrelevant without an EU footprint). Add sector frameworks that do apply.
- Voting rules. The unanimity rule on overriding CISO/CPO/GC objections is opinionated. If your culture cannot support it, document an alternative — but expect the auditor to ask why.
- Review cycle. Annual is the floor. In a fast-moving regulatory environment, move to semi-annual.
What auditors actually look for in a charter
When an external auditor or regulator reviews your charter, they are looking for three things — none of them length, formatting, or sign-off pages.
Explicit authority. Can the committee approve or deny? Where does escalation go? If the charter doesn't answer those questions on first read, the auditor will mark the governance function as immature regardless of how active the committee actually is.
Framework alignment. Can the auditor walk from the charter to a known framework clause without inventing the mapping? If the charter names NIST GOVERN-1.1, ISO 42001 §5.3, and EU AI Act Article 26, the audit becomes a sampling exercise. If it doesn't, the audit becomes an investigation.
Evidence of operation. The auditor will ask for meeting minutes, decision logs, and inventory reviews to confirm the committee operates as the charter describes. A clean charter with empty minutes is worse than no charter at all — we treat this evidence trail as the operational layer of AI compliance.
How to roll out the charter once you have it
The rollout determines whether the charter becomes a working document or a binder on a shelf. Three steps:
1. Share with proposed members and get sign-off. Before any board involvement, walk the draft individually with each proposed voting member. Resolve objections privately. The biggest failure mode is presenting a charter cold to a CIO or General Counsel who then publicly contests the authority section. Do the friction privately, then land the version everyone already supports.
2. Present to the audit committee. Bring the version your members have endorsed. Explain the framework alignment, the authority statement, and the unanimity rule. Ask for ratification, not feedback. If you ask the audit committee to "review and provide input," you will get six months of redlines.
3. Ratify at the first committee meeting and publish. The committee's first formal action is to ratify its own charter. Publish it to the internal compliance hub and link it from the AI policy. To benchmark current maturity gaps before publishing, use the AI governance maturity assessment.
FAQ
Do we need separate charters for different business units?
No. One charter, with business unit representatives rotating into the committee for matters affecting their unit. Multiple charters fragment authority and create gaps. If a BU has unique regulatory exposure (e.g., a regulated subsidiary), add a BU-specific addendum rather than a separate charter.
Should this be in the company employee handbook?
A summary belongs in the handbook so employees know the committee exists and how to escalate AI concerns. The full charter belongs in the compliance documentation hub alongside policies and standards. Don't paste the full charter into a handbook — it dilutes both documents.
How often should we amend the charter?
Annually at minimum, and on any material regulatory or organizational change. Expect one structural amendment in the first year as the committee discovers what doesn't work, then steady-state annual reviews. Document amendments at the bottom of the charter so version history is visible.
Who owns the charter?
The committee chair owns it — typically the CISO or the Head of GRC. Ownership means responsibility for the annual review, drafting amendments, and ensuring published versions are current. Co-ownership doesn't work; pick one person.
Should the board pre-approve the charter?
Yes. The Audit Committee of the Board (or the equivalent risk committee) should ratify the charter before the AI Governance Committee holds its first formal meeting. Board ratification is what gives the committee the authority described in Section 3. Without it, the committee is informal and its decisions are challengeable. For the broader practice of running the committee once chartered, see the best practices guide.