Key takeaways
- No regulation anywhere requires an AI governance committee. Four things are required, and a committee is only useful because it produces them.
- The EU AI Act allocates duties to named people, not to bodies. Annex V(8) requires the declaration of conformity to carry the name and function of the person who signed it, and Article 26(2) requires human oversight to be assigned to natural persons with competence, training and authority.
- Article 17(1) requires providers of high-risk systems to maintain an accountability framework setting out the responsibilities of management and staff. That sentence, not an org chart, is what an auditor tests.
- A quarterly cadence cannot meet the Article 73 incident clocks of 15 days, 10 days and 2 days. Cadence is a control, and it needs a standing delegation behind it.
- After Regulation (EU) 2026/1744, Annex III high-risk duties apply from 2 December 2027 and Annex I from 2 August 2028, while AI literacy and transparency duties are already live. A charter written to the old timetable is already wrong.
Search for how to set up an AI governance committee and you will find a great deal of agreement. Bring together legal, IT, security, data science, human resources and the business. Meet quarterly. Write a charter with a principles preamble. Approve use cases. Train everyone. The advice is sensible and it is what almost every page in the results says. It is also, on its own, unauditable. Not one of the top forty results for this query names a single legal provision that the structure has to satisfy. The charter template that ranks fourth was written in 2023, provides for seven officers and five rotating members, and its entire compliance article commits the body to “all relevant legal and ethical standards” without naming one. Google’s own summary of the topic mentions the EU AI Act once, as a framework to align with, and then moves on. This guide takes the opposite route. It starts from the four obligations that actually exist, works backwards to the seats, decision rights, cadence and records that discharge them, and says plainly when an AI governance committee is the wrong answer.
What an AI governance committee actually is
An AI governance committee is a standing body with delegated authority to decide whether, how and under what conditions an organisation builds, buys and operates AI systems. The important half of that sentence is “delegated authority”. A group that reviews and advises is a working group. A group that can stop a deployment is an AI governance committee. Three bodies get confused with an AI governance committee, and the confusion has consequences when an authority asks who decided something. A steering committee owns the AI strategy: what to invest in, in what order, for what return. Its output is a roadmap and a budget. An ethics board or ethics committee gives an opinion on whether a use is acceptable, usually without the power to compel anything. It is closest in shape to a research ethics committee and it works best when its members are partly external. An AI governance committee sits between them and owns the decisions that carry legal consequence: risk classification, conditions of deployment, who is named as the accountable person, and when a system stops. Most organisations do not need three bodies. They need one AI governance committee with clear decision rights and honest minutes, plus a named person who signs things. What they usually build instead is a steering committee wearing a governance label, which is why the second and third meetings are about tool budgets rather than about the classification of the systems already running. The label matters less than the decision rights. Whatever you call it, write down what it may decide, what it must escalate, and what never reaches it. Everything below follows from that. Our AI governance pillar covers the wider operating model this body sits inside.
An AI governance committee is not a legal requirement. These four things are
Every AI governance committee charter should open on this section. The ranking pages skip it, and it is the only one an auditor will care about.
Article 17(1): the accountability framework
Providers of high-risk AI systems must put in place a quality management system. Article 17(1) lists its elements, and among them is an accountability framework setting out the responsibilities of the management and other staff with regard to all the aspects listed in that paragraph. Those aspects include the regulatory compliance strategy, design and testing procedures, data management, risk management, post-market monitoring, incident reporting and record keeping. Read that as the checklist for your AI governance committee charter. For each element of the quality management system, some named role has to own it. If your charter says the AI governance committee is responsible for “compliance”, it has not satisfied Article 17(1). If it says the Head of Data Engineering owns data management under Article 10 and reports quarterly to the committee, it has.
Article 26(2): oversight assigned to natural persons
Deployers of high-risk AI systems must assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Three separate tests sit in that sentence. Competence means the person understands the system’s outputs and its limits. Training means they were trained on that specific system. Authority means they can actually override it or escalate, which in practice means they cannot be junior to the person whose targets the system serves. An AI governance committee cannot exercise Article 26(2) oversight. It can only name the people who do, verify their capacity and record that it did. See our guide to human oversight for what the Article 14 and Article 26 duties require in operation.
Annex V(8): somebody signs
Article 47 requires the provider to draw up a written, machine-readable, physically or electronically signed EU declaration of conformity for each high-risk AI system, and to keep it at the disposal of national competent authorities for ten years. Annex V sets out what it contains, and item 8 requires the name and function of the person who signed it, an indication of who they signed for, and a signature. A committee has no signature. Someone in your organisation will personally attest that a system conforms to the Regulation, and they will do it under the sole responsibility of the provider, as Annex V(3) puts it. The single most useful thing an AI governance committee can do in its first meeting is establish who that person is and what they will need in order to sign without embarrassment. Most organisations discover the answer during conformity assessment, which is late.
ISO/IEC 42001 Clause 5.3 and NIST AI RMF GOVERN 2
Outside the EU, the same expectation appears as a management-system requirement. ISO/IEC 42001 Clause 5.3 requires top management to assign, communicate and authorise roles, responsibilities and authorities for the AI management system, including responsibility for reporting the system’s performance back to top management. Auditors read Clause 5.3 as documented accountability across the AI lifecycle, not as an organisation chart. The NIST AI Risk Management Framework puts the same content in GOVERN 2. GOVERN 2.1 asks that roles, responsibilities and lines of communication for mapping, measuring and managing AI risks are documented and understood. GOVERN 2.2 asks that personnel and partners are trained to perform those duties. GOVERN 2.3 puts risk-tolerance decisions with executive leadership rather than with whoever built the model. Our AI governance framework guide maps the three regimes against each other. Four obligations, no committee among them. The committee earns its place only by producing the accountability framework, the named overseers, the signing officer and the evidence that the first three are real.
Who sits on it, and what each seat owns
Membership lists for an AI governance committee usually read as a list of departments. That is a room, not a governance body. Attach a duty to every seat. Chair, usually an executive with profit-and-loss authority. Owns the risk tolerance the committee applies and the escalation to the board. NIST AI RMF GOVERN 2.3 puts this decision at executive level for a reason: a risk appetite set by a working group is a preference, not a mandate. Signing officer. The person named under Annex V(8) for declarations of conformity. Often the same person as the chair in a smaller provider, and often the head of product or engineering in a larger one. This seat exists whether or not you fill it deliberately. Legal and regulatory. Owns the classification decision under Articles 6 and 7 and the answer to which role the organisation holds for each system: provider, deployer, importer, distributor or authorised representative. Most disputes inside an AI governance committee are actually role disputes in disguise. Data protection. Owns the interaction with the GDPR, including whether a data protection impact assessment is required alongside the fundamental-rights assessment, and the lawful basis for training data. Our note on AI impact assessment covers which regime applies when. Security. Owns the Article 15 accuracy, resilience and cybersecurity requirements, adversarial testing, and the interface with incident response. The AI red teaming programme reports here. Model and data owner from the business. Owns performance monitoring, drift, and the honest answer to what the system is actually used for, which is frequently not what the intake form said. Human resources or works council liaison, where employment is in scope. Owns worker notification under Article 26(7) and, in Germany, the co-determination rights the works council holds under the Betriebsverfassungsgesetz. In France, the information duty toward the social and economic committee applies before deployment, not after. Two rules keep the room honest. First, distinguish members who advise from members who are accountable, and mark it in the charter, because an accountable member cannot abstain. Second, cap the size. An AI governance committee of fifteen makes no decisions; it receives presentations.
Decision rights: what the committee may decide, and what it may not
Write the AI governance committee’s decision rights before its membership. A body without them will drift toward the easiest available work, which is tool procurement. Four dispositions are enough: approve, approve with conditions, defer pending evidence, and terminate. Give each a named owner for the follow-up and a date. “Approve with conditions” is the workhorse and the one most charters omit, which forces a binary choice the committee is not ready to make. Some decisions must escalate to the board. A prohibited practice under Article 5, any first deployment of a system classified as high-risk, any decision to accept a residual risk the risk owner has formally objected to, and any serious incident with a reporting obligation. Boards do not want the rest, and directors’ oversight duty is discharged by receiving the exceptions and the aggregate picture, not the queue. Some decisions must never reach the AI governance committee at all. Low-risk internal productivity tools with no personal data and no external output should clear through a standing policy, and if your intake process routes them to the committee, the committee will spend its authority on them. Risk tiering is the filter that protects the agenda. Classify on intake, route by tier, and reserve the room for the systems that carry legal consequence. Our AI risk management guide covers how to set the tiers. The last rule is the one no ranking page raises. The body that approves a use case cannot also be the body that assures it. The Institute of Internal Auditors maps AI oversight onto the Three Lines Model across three domains, Governance, Management and Internal Audit, with the internal control environment established by management in the first line and the governing body relying on information supplied by internal audit. An AI governance committee that writes the control, operates the control and signs off the control has produced a document, not assurance. Keep AI audit work independent of the committee that approved the system.
Cadence is a control, not a calendar
Almost every AI governance committee charter in circulation sets a quarterly minimum, with monthly at the chair’s discretion. Compare that against the clocks the Regulation actually runs. Article 73 requires providers to report a serious incident to the market surveillance authority without undue delay and in any event within 15 days of becoming aware of it. Where a death may have been caused, the deadline is 10 days. Where the incident is a widespread infringement or a serious and irreversible disruption of critical infrastructure, it is 2 days. Article 73(5) permits an initial incomplete report followed by supplementary information, which is a concession to exactly this problem. No quarterly AI governance committee meets a 2-day clock. Nor does a monthly one. This is not an argument against a standing cadence; it is an argument that the cadence carries only the deliberative work, and that everything time-bound runs on a standing delegation. Three mechanisms cover it. A duty officer rota, so that at any hour a named person can classify an event and start the clock. A convening trigger written into the charter, specifying who may call the committee within twenty-four hours and what they may decide alone in the meantime. And a standing agenda item on post-market monitoring, so that the drift and complaint signals that precede most incidents reach the room before the incident does. Our AI incident reporting guide covers the Article 73 workflow in detail. The deliberative cadence itself should be tied to throughput rather than to the calendar. If intake produces twelve high-risk classifications a quarter, quarterly meetings guarantee a queue, and a queue is where shadow deployment begins.
What the AI governance committee has to produce as evidence
An authority does not inspect an AI governance committee. It inspects records. Five artefacts carry the weight. Minutes as decision records. Attendance and apologies, the decision, the four dispositions above, the rationale, any dissent by name, the conditions attached, the owner and the date. Minutes that record only outcomes are worthless in an investigation, because the question will be whether the decision was reasonable on the information available at the time, and only the rationale answers it. The use-case register. One row per system, with the role held, the classification and the reasoning behind it, the named overseer under Article 26(2), the lifecycle stage and the review date. This register is also the practical answer to shadow AI, since a system nobody registered is a system nobody oversees. See AI system documentation for what the record has to contain. Logs. Article 26(6) requires deployers to keep the logs automatically generated by a high-risk AI system, to the extent those logs are under their control, for a period appropriate to the intended purpose and of at least six months, unless Union or national law provides otherwise. Six months is a floor, not a target, and it is shorter than most investigation timelines. Annex IV technical documentation. Somebody owns it, it has to be current at the moment the system is placed on the market, and it has to be updated as the system changes. The AI governance committee’s job is to confirm the owner exists and that the document is not eighteen months behind the deployed model. The declaration of conformity. Signed, machine-readable, and retained for ten years after the system is placed on the market or put into service. A useful test: ask what the AI governance committee could hand an authority tomorrow morning without preparing anything. If the honest answer is a slide deck, the body is not yet a control.
The 2027 calendar a charter written today has to assume
Timing is where a lot of published AI governance committee guidance is now simply wrong, because the timetable moved after most of it was written. Already in force: the prohibited practices in Article 5 and the AI literacy duty in Article 4 have applied since 2 February 2025, and the general-purpose AI obligations since 2 August 2025. AI literacy is the one most organisations under-serve, and it is the duty an AI governance committee can discharge fastest. Our AI literacy guide covers what Article 4 actually asks for. From 2 August 2026: the Article 50 transparency duties on synthetic content, chatbot disclosure, deepfake labelling and emotion recognition. If the organisation generates or manipulates content, this is the nearest hard date. Deferred: the Digital Omnibus on AI, Regulation (EU) 2026/1744, was approved by the European Parliament on 16 June 2026 and by the Council on 29 June 2026, published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It moved the standalone Annex III high-risk obligations to 2 December 2027 and the Annex I embedded high-risk obligations to 2 August 2028. Prohibited practices and the general-purpose AI regime were not changed. For an AI governance committee this deferral is not a reason to slow down; it is a budget. Classification work, the accountability framework and the register are the long-lead items, and organisations that treat 2 December 2027 as the start date rather than the deadline will be assembling Annex IV documentation for systems that have been running unmonitored for two years. Our EU AI Act high-risk guide covers the classification decision itself.
When you should not create an AI governance committee
One of the higher-ranking pages on this query argues that you do not need an AI governance committee at all. That deserves an answer rather than silence, because it is right more often than the vendor guidance admits. A standing AI governance committee is the wrong structure when three conditions hold together: the organisation is neither a provider nor a deployer of any high-risk system, it operates no general-purpose model of its own, and its AI use consists of a small number of vendor tools with no automated decisions about people. In that situation a committee produces ceremony. The right structure is a single named accountable owner, an AI policy that is actually enforced, and a standing item on an existing risk or audit committee. An AI governance committee is also the wrong structure when it becomes a way to distribute responsibility until nobody holds it. If the charter names no accountable individuals, the committee has made accountability harder to locate than it was before, which is the failure mode Article 17(1) and Clause 5.3 exist to prevent. Two honest triggers for creating an AI governance committee: the first system that classifies as high-risk under Annex III, and the first time two functions disagree about a deployment and there is no forum in which the disagreement can be settled with a record. Before either, a named owner and a good AI policy will serve better.
FAQ
What is the role of an AI governance committee? Its role is to hold and exercise delegated decision rights over AI systems that carry legal or material consequence, and to produce the records that prove those decisions were made deliberately. In practice that means classifying systems and the organisation’s role for each, approving or conditioning deployments, naming the people accountable for oversight and for signing conformity documents, and reviewing incidents and post-market monitoring. Advisory input is a secondary function. A body that only advises does not need a charter. Who is responsible for AI governance? Named individuals, not the committee. The EU AI Act allocates duties to the provider or deployer as an organisation and then requires that organisation to identify natural persons: the overseers under Article 26(2), the staff whose responsibilities appear in the Article 17(1) accountability framework, and the person who signs the declaration of conformity under Annex V(8). ISO/IEC 42001 Clause 5.3 asks the same of top management. The committee’s contribution is to make those assignments explicit and to check they are real. How is an AI governance committee different from an AI steering committee? A steering committee decides what the organisation should build and fund. An AI governance committee decides whether and under what conditions it may operate what has been built. They answer to different questions and, ideally, they do not share a chair, because the person accountable for delivery should not also be the person who approves the risk acceptance. Where headcount forces one body, split the agenda and minute the two roles separately. How often should an AI governance committee meet? Set the deliberative cadence by intake volume rather than by habit, and never rely on the meeting calendar for anything time-bound. Article 73 runs incident clocks of 15 days, 10 days and 2 days, so the charter needs a duty officer, an emergency convening rule and a written scope of what a single officer may decide alone. Monthly deliberation with a standing delegation beats weekly meetings without one. Do we need an AI governance committee for ISO 42001 certification? No. Clause 5.3 requires assigned and communicated roles, responsibilities and authorities, and a route for reporting AI management system performance to top management. A committee is one way to evidence that, and for many organisations the most convenient one, but an auditor is testing whether accountability is documented, understood and exercised, not whether a body with a particular name exists. Our ISO 42001 certification guide covers what auditors actually sample. What should an AI governance committee charter contain? Purpose and scope, the four decision dispositions and who holds them, the escalation matrix to the board, the seats with a named duty attached to each, the quorum and the conflict-of-interest rule, the convening trigger and duty-officer arrangement, the standing agenda, the record-keeping obligations with retention periods, and the review cycle for the charter itself. Map each element of Article 17(1) to a named role in an annex. That annex is the part an auditor will ask for.
Conclusion
The ranking pages for this query describe an organisational design. The Regulation describes an accountability chain, and it ends at a person with a pen. An AI governance committee is valuable exactly to the degree that it makes that chain explicit: who classified this system and on what reasoning, who oversees it and with what authority, who will sign for it, and where the record of all three is kept. Build the charter backwards from Article 17(1), Article 26(2), Annex V(8) and Clause 5.3. Give the AI governance committee real dispositions and a real escalation path. Keep assurance independent of approval. Set the cadence against the incident clocks rather than the calendar. And if the four obligations do not yet apply to you, say so in writing and appoint an owner instead. A committee that exists because the duties exist is a control. One that exists because a competitor announced theirs is a meeting.