An AI Governance Committee Charter for the EU AI Act

An AI governance committee is a practice, not a requirement. Regulation (EU) 2024/1689 never mentions a committee, a charter, or a board. It imposes duties — screen for prohibited use (Article 5), classify by use (Article 6), run a risk-management system on high-risk systems (Article 9), oversee, document — and is silent on who in your organisation discharges them. A committee is one common and effective answer: a standing body that owns the hard decisions a single person should not make alone. The charter is the document that gives it teeth.

This guide sets out what belongs in that charter — mandate, membership, decision rights, the specific screens and sign-offs it owns, escalation, and cadence — and shows how it ties to the Article 9 risk-management system and the use-case register. Treat it as a template to cut down to your size, not a maximal structure to adopt wholesale.

---

What the charter is for (and what it must not pretend to be)

A charter does one job: it makes accountability unambiguous. Without it, AI decisions diffuse — a product team classifies its own system, nobody signs off the high-risk ones, and a prohibited use slips through because no one owned the screen. The charter names a body, gives it decision rights, and says what it must decide before an AI system goes live.

What the charter must not do is imply that having a committee equals compliance. The committee is governance scaffolding; the statutory duties still attach to providers and deployers regardless of how you organise. A charter that lists "we have an AI committee" as a compliance control, without the committee actually owning the Article 5 screen and the high-risk sign-off, is theatre.

---

1. Mandate

State, in two or three sentences, why the committee exists and what authority it holds. A workable mandate: "The AI Governance Committee owns the organisation's approach to AI risk under the EU AI Act and adjacent law. It approves the AI risk appetite, screens new AI use cases for prohibited and high-risk classification, signs off high-risk systems before deployment, and escalates material risk to the board. Its decisions are binding on all business units." The word that matters is binding — a committee that only advises will be overruled by a product deadline.

2. Membership

Keep it small enough to decide and broad enough to see the whole estate. A typical composition:

In a smaller firm one person may hold several seats (governance lead + DPO, say) — the charter should name the roles and allow individuals to double up, rather than mandate six separate people.

3. Decision rights

The heart of the charter. Spell out what the committee decides versus what is delegated:

• Reserved to the committee: approving the AI risk appetite; the Article 5 prohibited-use determination (a "no" here stops a project); high-risk go/no-go sign-off before deployment; approving the classification methodology; accepting or rejecting an Article 6(3) exemption argument.
• Delegated to product/system owners, reviewed by the committee: day-to-day classification of new systems; running the Article 9 process; maintaining instructions-for-use and oversight arrangements.
• Delegated with reporting: minimal-risk and Article 50 limited-risk systems — owners self-certify and log them; the committee sees them on the register but does not gate each one.

A clear split keeps the committee from becoming a bottleneck that every minimal chatbot must pass through, while ensuring the genuinely risky decisions land at the right level.

4. The two screens the committee owns

Prohibited-use screening (Article 5)

Every new AI use case is screened, at intake, against the Article 5 prohibitions — social scoring, manipulative or exploitative techniques, crime-risk prediction based solely on profiling, untargeted facial-image scraping, emotion recognition in the workplace or education, certain biometric categorisation, and real-time remote biometric identification in public for law enforcement. These have been prohibited since 2 February 2025. From 2 December 2026 the screen must also catch two bans added by the Digital Omnibus: AI that generates non-consensual intimate images of identifiable people (Article 5(1)(ba)) and AI that generates child sexual abuse material (Article 5(1)(bb)). The committee (via the governance lead) owns this screen because a prohibited system is not a compliance project to be fixed — it must not be built. A "no" here is final.

High-risk classification and sign-off (Annex III / Article 6)

For systems that clear the Article 5 screen, the owner classifies under Article 6 and Annex III (the eight high-risk areas). Where a system is high-risk — or where the owner invokes the Article 6(3) exemption — the committee reviews and signs off before deployment, confirming the Article 9 RMS, Article 11/Annex IV documentation, Article 43 conformity assessment, Article 49 registration and (where it applies) the Article 27 FRIA are in place. This sign-off is the committee's most consequential act.

5. Escalation

Define the triggers that force a decision upward: a candidate prohibited use; a high-risk system that cannot meet its obligations by its deadline; a serious incident requiring Article 73 reporting; a material change that re-classifies a system; a vendor whose conformity evidence is missing. Each trigger has a route — to the committee, and from the committee to the board where the AI risk appetite is breached. Escalation paths that exist only on paper fail in the moment; rehearse the serious-incident one.

6. Cadence

A standing quarterly meeting for the full register review and risk-appetite check, with an out-of-cycle mechanism for high-risk sign-offs and prohibited-use calls that cannot wait for the next quarter. Smaller organisations may run it monthly when the AI estate is growing fast, then settle to quarterly. The charter should fix the minimum cadence and the rule for convening between meetings.

---

How the charter ties to Article 9 and the use-case register

The committee does not float free of the statutory machinery — it sits on top of two artefacts:

• The use-case register is the committee's working document: every AI system, its Article 5 screen result, its Article 6 classification, its role (Article 16 provider / Article 26 deployer), its owner, and its status. The committee reviews the register each cycle; you cannot govern what you have not listed.
• The Article 9 risk-management system is the statutory obligation for each high-risk system — a continuous, iterative process across the lifecycle. The committee does not run each Article 9 process (the product owner does) but it owns the assurance that every high-risk system has one with an owner and a cadence, and that it feeds Article 72 post-market monitoring once live. The charter is the bridge: it routes the Article 9 obligation to a named owner and gives the committee the sign-off that confirms it exists.

In short: the register tells the committee what it governs; Article 9 is the discipline it assures; the charter is what makes both land on people.

---

Worked example: a charter cut to size

Vesterbro Health Systems ApS — ~320 employees, ~€60M turnover, a Danish health-tech company building scheduling and triage software — stands up an AI Governance Committee. Its charter, cut down:

• Mandate: binding authority over AI classification, high-risk sign-off and risk appetite.
• Membership: the CTO chairs (accountable executive); the AI governance lead (who also acts as DPO) runs the agenda; the head of security and a product director complete it — four people, two of them double-hatted.
• Decision rights: the committee reserves the Article 5 screen and high-risk sign-off; product owners classify and self-certify minimal and Article 50 systems.
• The screen in action: an "emotion recognition for patient triage" idea is caught at the Article 5 intake screen — emotion recognition is prohibited in some contexts and high-risk in others — and the committee refers it for a careful Annex III / Article 5 analysis before any build. Its triage-support tool that influences clinical pathways is flagged potentially high-risk and routed to full sign-off; its internal meeting-scheduler AI is minimal and self-certified.
• Cadence: monthly while the AI estate grows, with an out-of-cycle sign-off route for the triage tool.

Vesterbro's charter is four roles, three reserved decisions, and a quarterly-tending-monthly cadence — enough to catch the prohibited idea and gate the high-risk tool, without forcing the scheduler through a committee.

---

The deadlines the committee plans against

The committee's calendar is set by the Act's dates. Article 5 prohibitions and Article 4 AI literacy are in force now (since 2 February 2025) — so the prohibited-use screen and a literacy programme are present obligations, not future work. Article 50 transparency has applied since 2 August 2026, and the two new Article 5 bans apply from 2 December 2026. High-risk Annex III obligations apply from 2 December 2027 under the Digital Omnibus, Regulation (EU) 2026/1744 — published in the Official Journal on 24 July 2026 and in force since 27 July 2026 — deferred from 2 August 2026; Annex I product-embedded systems follow from 2 August 2028. The committee plans high-risk sign-offs against 2 December 2027.

---

How Confir helps

Confir gives the committee the register it governs from: every AI system with its Article 5 screen, its Article 6 / Annex III classification, its Article 16/26 role, and its obligation list routed to an owner. The classification is deterministic and rule-based — same intake, same finding, with the rule that fired recorded — so when the committee signs off a high-risk system it has a defensible, reproducible basis, not a consultant's opinion. It generates the Article 11/Annex IV pack and Article 27 FRIA the sign-off depends on.

Related guides

• AI governance operating model
• Board reporting on AI risk
• An AI governance RACI model
• Three lines of defence for AI
• Article 5 prohibited practices
• Article 9 risk-management system
• The Article 6(3) exemption explained