AI Ethics Board and AI Review Committee Guide

Many organisations have set up an AI ethics board, yet few of those boards have the authority, membership or evidence to change what actually gets deployed. A committee that meets quarterly to discuss principles, with no right to stop a launch, gives assurance on paper and none in practice. This guide covers how to charter an AI ethics board or AI review committee, who should sit on it, which decisions it should own, how reviews run, and how to show it is working. It is for AI governance leads, CISOs, risk and compliance officers, and the executives who sponsor these bodies. Wider AI governance design is covered in the AI Governance Guide; this guide focuses on the committee itself.

Key takeaways

Give it decision rights or do not create it. A committee that can only advise becomes a forum for objections that nobody acts on; the charter must say which deployments need its approval and what happens when it says no.
Separate the layers. An executive AI governance board sets appetite and owns risk, a working review committee assesses cases, and an optional external ethics panel adds independent challenge. Merging them slows everything down.
Route by risk tier. Only high-risk and novel use cases should reach the committee; everything else goes through a documented standard path, otherwise the committee becomes a bottleneck and teams route around it.
Decide on evidence, not presentations. Every case needs an evidence pack: register entry, impact assessment, test results, oversight design and the identities and data the system uses.
Record and revisit decisions. Conditions attached to approvals must be tracked to closure, and approvals should expire so that drift in model, data or purpose triggers a fresh review.

What an AI ethics board is, and what it is not

The labels vary (AI ethics board, responsible AI council, AI review committee, AI governance board), but the bodies fall into three functional types. Most mid-sized and large organisations need the first two; the third is optional.

Body	Main job	Typical chair and cadence	Output
Executive AI governance board	Sets AI risk appetite and policy, accepts residual risk on the highest-impact cases, resolves escalations	Executive sponsor (COO, CRO or deputy chief executive); quarterly plus on demand	Policy approvals, risk acceptance, escalation rulings
AI review committee	Assesses individual high-risk or novel AI use cases against policy and principles	Head of AI governance or responsible AI lead; every two to four weeks	Approve, approve with conditions, defer, reject
External ethics advisory panel	Independent challenge on contested or societally sensitive uses	Independent chair; two to four times a year	Written advice, published or internal

Public-sector practice shows the executive layer clearly. OMB memorandum M-25-21 (3 April 2025), which rescinded M-24-10, requires each CFO Act agency to convene an AI Governance Board within 90 days, chaired at Deputy Secretary level or equivalent with the Chief AI Officer as vice-chair, and drawing on offices such as IT, cybersecurity, data, budget, legal, privacy and civil rights. The same memo places high-impact AI under minimum practices that include an impact assessment with independent review and a signed risk acceptance. A private-sector review committee is the working body that makes that kind of independent review real.

What the committee is not: it is not a replacement for security architecture review, data protection review or model validation. It consumes their outputs. If the committee starts doing penetration-test triage or DPIA drafting, its scope has drifted.

Writing the charter

The charter is the committee's source of authority. Get it approved by the executive board or the board of directors so that its decisions bind business units. A workable charter covers these elements:

Charter element	What to write	Common weak version
Mandate	Review and decide on AI use cases rated high risk or novel under the [AI risk tiering method]; advise on AI policy	"Promote ethical AI"
Authority	No in-scope system goes live without a recorded decision; the committee may suspend an approved system pending review	Advisory only, no stop right
Scope	Built, bought and embedded AI, including AI agents, in all business units and subsidiaries	Only internally built models
Escalation	Rejections may be appealed once to the executive AI governance board, whose decision is final and recorded	Business sponsor can override informally
Quorum and voting	For example, a majority of members including at least one from legal or privacy and one from security; chair has a casting vote	Decisions by whoever attends
Conflicts of interest	Members declare interests and recuse from cases they sponsor or build	Not addressed
Records	Minutes, decision log and evidence packs kept for [retention period]	Slides in a shared drive
Review	Charter reviewed annually and after any significant incident	Never revisited

The NIST AI Risk Management Framework supports each element. GOVERN 2.1 asks for documented roles, responsibilities and lines of communication for AI risk; GOVERN 2.3 places responsibility for decisions about AI risk with executive leadership; and GOVERN 1.5 asks for planned monitoring and periodic review of the risk management process. A charter that cites these outcomes is easier to defend to auditors.

Membership and independence

Size matters: seven to eleven voting members is large enough for diverse expertise and small enough to decide. GOVERN 3.1 of the NIST AI RMF calls for decision-making on AI risk to be informed by a diverse team, which in practice means disciplines, not only demographics.

Seat	Why it is needed	Watch for
Chair: responsible AI or AI governance lead	Runs the process, owns the decision log	Chair who also leads AI delivery (conflict)
Legal and regulatory	EU AI Act classification, sector rules, contracts	Treating legal sign-off as ethical sign-off
Privacy or Data Protection Officer	Lawful basis, DPIA, data minimisation	DPO independence duties under GDPR
Security (CISO delegate)	Model, data and identity security, abuse cases	Only reviewing infrastructure
Data science or ML engineering	Reads test results, challenges claims about accuracy and fairness	Reviewing their own team's work
Risk management	Links decisions to risk appetite and the risk register	Converting everything into a single score
HR or employee representative	Workplace uses, worker information duties	Missing when monitoring tools are reviewed
Customer or product voice	Effect on customers, complaints, accessibility	Marketing framing
Independent external member (optional)	Challenge from outside the reporting line	Selection without vetting or clear role

Independence: the committee should report to the executive governance board, not to the head of the function building AI. Business sponsors present cases and leave for the decision.
Competence: members need training on the AI risk method, the regulatory map and the principles in use. Under Article 4 of the EU AI Act, as amended by the Digital Omnibus on AI, providers and deployers must take measures to support the AI literacy of staff dealing with AI systems; committee members are an obvious priority group. See the EU AI Act AI Literacy Obligations (Article 4) Guide.
Terms: fixed terms of two to three years, staggered so that the committee does not lose all its memory at once.
External members: vet them, publish their role, and agree in writing how their advice is used. An external panel whose members become the story stops functioning (see Common failure patterns).

Decision rights and what reaches the committee

The committee should see a small share of AI use cases. Triage happens before it, using the risk tier recorded in the AI register. See the AI Use Case Risk Tiering Guide and the AI Register and AI Inventory Template.

Case type	Route	Decision maker
Low risk (internal productivity, no personal data, human uses output)	Standard path: register entry and checklist	System owner, with AI governance spot checks
Medium risk (personal data, customer-facing content, limited autonomy)	Expedited review by two committee members	Delegated reviewers, reported to committee
High risk (decisions about individuals, EU AI Act Annex III areas, safety, autonomous agents with write access)	Full committee review	AI review committee
Novel or contested (new technique, public controversy, prohibited-practice boundary)	Full committee, optional external panel advice	Committee, escalation to executive board
Residual risk above appetite	Escalation	Executive AI governance board

Use four decision outcomes and record which one was given:

Approve: proceed as presented, with an approval expiry date (for example 12 months for high risk).
Approve with conditions: each condition has an owner and due date, and conditions that must be met before go-live are separated from those that follow it.
Defer: specific missing evidence named, case returns to a set meeting.
Reject: reasons recorded with reference to policy or principle; route to appeal stated.

Approvals should lapse on material change: a new model or model version, new data categories, a wider user population, higher autonomy or a new hosting region.

Running a review

Intake: the system owner submits a request linked to the register entry. The secretariat checks completeness within [five] working days.
Evidence pack: purpose and intended use, affected people, risk tier rationale, AI impact assessment and DPIA where required, test and evaluation results (accuracy, robustness, fairness, red-team findings), human oversight design, monitoring plan, identities and data access, vendor terms. See the AI Impact Assessment Template and the AI Risk Assessment Guide.
Pre-read and questions: papers circulated at least [five] working days before the meeting; written questions to the owner beforehand so the meeting is spent on judgement, not discovery.
Hearing: owner presents for no more than 15 minutes, then answers questions. The owner leaves before deliberation.
Decision and record: outcome, rationale, conditions, dissent and expiry entered in the decision log and the register on the day.
Follow-up: the secretariat tracks conditions; overdue pre-go-live conditions block deployment through the change process.
Post-deployment review: high-risk systems return after [three to six] months with monitoring data, incidents and complaints.

The questions the committee asks map closely to the NIST AI RMF Map function: MAP 1.1 (intended purpose, context and affected people documented), MAP 3.5 (human oversight processes defined and documented) and MAP 5.1 (likelihood and magnitude of each identified impact, beneficial and harmful). GOVERN 5.1 adds a duty to collect and integrate feedback from people outside the team that built or deployed the system, which is why complaints data belongs in the post-deployment review.

Principles to review against

A committee needs a stated set of principles, mapped to concrete review questions. Adopting an international set saves debate and is easier to explain externally.

Source	Principles	Practical review question
UNESCO Recommendation on the Ethics of AI (adopted by 193 Member States, November 2021)	Ten principles, including proportionality and do no harm; safety and security; privacy and data protection; responsibility and accountability; transparency and explainability; human oversight and determination; fairness and non-discrimination	Is AI proportionate to the aim, and can a human override it?
OECD AI Principles (adopted May 2019, updated May 2024)	Inclusive growth and well-being; human rights and democratic values including fairness and privacy; transparency and explainability; robustness, security and safety; accountability	Who is accountable if it fails, and can affected people understand an outcome?
NIST AI RMF 1.0 trustworthiness characteristics	Includes valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed	What test evidence shows each characteristic at the required level?

For fairness and explainability evidence, see the Explainable and Fair AI Guide.

Regulatory anchors

EU AI Act deployers: Article 26 requires deployers of high-risk systems to assign human oversight to people with the necessary competence, training, authority and support, to keep automatically generated logs for at least six months unless other law sets a different period, to inform workers' representatives and affected workers before workplace use, and to inform people subject to Annex III decisions. The committee is a natural place to confirm these before go-live. Under the consolidated text, Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. See the EU AI Act Compliance Guide.
ISO/IEC 42001:2023: specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, for any organisation that develops, provides or uses AI. If you certify against it, map the committee's charter and records to the relevant clauses of your licensed copy.
US federal agencies: M-25-21 sets the AI Governance Board structure and the minimum practices for high-impact AI described above. Check for later OMB guidance before relying on it.
Financial services: model risk governance already gives a validation and approval function; align the committee with it rather than duplicating it. See the AI Model Risk Management Guide (SR 11-7).

Where identity fits

For AI agents, the ethical question "how much should this system decide on its own?" becomes a concrete access question: which identity does it run under, which tools and scopes does it hold, and which actions need a human approval step. The committee should approve an autonomy level and a list of high-impact actions, and security should implement those as authorisation policy on the agent's own non-human identity. An approval that says "human in the loop" with no enforcement point is not oversight. See the AI Agent Authorisation Guide and the Agentic AI Identity Guide.

Setting it up: a phased approach

Months 0 to 2, foundation: agree the three-layer model, draft the charter, choose principles, name the chair and secretariat, and get executive approval.
Months 2 to 3, pilot: run five to ten real cases from one business unit through the process with decisions recorded but advisory. Measure time to decision and evidence gaps.
Month 4, enforce: make a recorded decision a mandatory gate in the change and procurement processes for high-risk cases. Keep an emergency route (chair plus two members, ratified at the next meeting) so urgent fixes are not blocked.
Months 4 to 9, backlog: review live high-risk systems already in production, highest risk first, using the AI register.
Annually: review the charter, membership and metrics; publish a summary of activity internally, and externally if you have made public commitments.

If the gate causes unacceptable delay during rollout, fall back to advisory mode for medium-risk cases only, keep full enforcement for high risk, and fix the evidence templates that are causing deferrals.

Small versus large organisations: a small organisation can run one combined committee of four or five people (a senior sponsor, legal or privacy, security, a technical lead) that meets monthly, using external advisers for contested cases. A large or multinational organisation usually needs the full three-layer model, regional or divisional review committees with a common decision log, and a central secretariat to keep decisions consistent.

Measuring whether it works

Monitor the decision log, the AI register and the change process together. Useful metrics:

Coverage: share of high-risk register entries with a current committee decision (target 100%).
Bypass rate: high-risk systems discovered in production with no decision, per quarter (target zero; each one is investigated).
Time to decision: median working days from complete submission to decision (for example under 15).
Condition closure: share of conditions closed by their due date.
Decision mix: proportion of approve, conditions, defer and reject. A committee that approves everything as presented is probably not testing evidence; one that defers most cases has an intake problem.
Post-deployment findings: incidents or complaints on approved systems that the review should have caught.

Framework mapping

Framework	Reference	Relevance to the committee
NIST AI RMF 1.0	GOVERN 2.1, 2.3, 3.1, 4.1, 5.1; MAP 1.1, 3.5, 5.1	Roles, executive accountability, diverse decision-making, safety-first culture, external feedback, impact review
NIST CSF 2.0	GV.RR-01, GV.RR-02, GV.RM-01, GV.OV-01	Leadership accountability, roles and authorities, agreed risk objectives, review of strategy outcomes
NIST SP 800-53 Rev. 5	PM-9 Risk Management Strategy, PM-23 Data Governance Body, PM-28 Risk Framing, RA-3 Risk Assessment	Governance body and risk framing controls the committee operates within
ISO/IEC 42001:2023	AI management system requirements	Management system the committee sits inside
EU AI Act	Art. 4, Art. 26	AI literacy of members; deployer duties checked before go-live

Common failure patterns

The advisory-only board: no stop right, so launches proceed regardless and the board's minutes become evidence that risks were known and ignored.
The external panel announced before it was designed: Google announced its Advanced Technology External Advisory Council on 26 March 2019, with eight members and four meetings planned for that year, and ended it on 4 April 2019, saying it could not function as intended in the current environment. Vet members, define the role and agree how advice is used before going public.
The bottleneck: every AI use case goes to the full committee, queues grow, and teams relabel AI features to avoid review. Tiering and delegated review prevent this.
Review without evidence: decisions made from slide decks with no test results or impact assessment, so conditions cannot be checked later.
One-time approval: no expiry and no change trigger, so a system approved with one model and dataset runs years later on different ones.
Oversight that is not enforced: "human approval required" written in the decision, but the agent's identity holds direct write access and nothing in the authorisation layer requires that approval.

Practitioner checklist

Charter approved at executive or board level, with a stop right and an appeal route.
Three layers defined: executive board, review committee, optional external panel.
Seven to eleven voting members covering legal, privacy, security, data science, risk, HR and customer voice, with conflict rules.
Triage by risk tier from the AI register, with delegated review for medium risk.
Standard evidence pack and four recorded decision outcomes, with approval expiry.
Material-change triggers wired into change management.
Agent autonomy decisions implemented as authorisation policy on the agent's identity.
Members trained on the risk method, principles and regulatory map.
Quarterly metrics: coverage, bypass rate, time to decision, condition closure, decision mix.
Charter and membership reviewed annually and after significant incidents.

AI Ethics Board and AI Review Committee Guide: Charter, Membership and Decisions