AI governance committee terms of reference should define the board mandate, delegated authority, membership, reporting cycle, risk appetite, decision rights and evidence pack for AI oversight. The aim is not a new talking shop; it is a route from AI use to board accountability.
Use a dedicated AI committee only where AI has become material enough to need focused board time. For many UK organisations, the better answer is amended audit and risk committee terms. The FRC's 2024 Corporate Governance Code guidance is clear that board committee terms should set out responsibilities, delegated authority and how committees complement one another. That is the discipline AI oversight needs.
Link the mandate to the board accountability hub: appetite sets the boundary, approval papers handle material decisions, and the standing AI report shows whether controls operated between meetings.
Key takeaways
- Do not create an AI committee because AI is fashionable. Create or amend a committee mandate because named AI decisions now need board-level ownership.
- The terms should specify the committee's authority, membership, evidence pack, reporting route, escalation triggers and relationship with audit, risk, technology, people and data protection governance.
- The committee should govern from artefacts: the AI inventory, risk register, DPIAs, supplier reviews, incident logs, human-review evidence, testing results and minutes.
- Framework mapping matters because UK boards face overlapping expectations: the government's five AI principles, ICO accountability, NIST AI RMF, ISO/IEC 42001, cyber guidance and, for listed companies, FRC internal-control reporting.
- The next step is to baseline current AI use before writing the mandate, then use the terms of reference to close the gaps that baseline exposes.
Who this applies to
This article is for boards, company secretaries, committee chairs, general counsel, chief risk officers and governance leads in UK organisations where AI is already used in decisions, operations, customer service, professional advice, content, analytics or supplier tooling.
It applies most directly where AI touches people, money, legal obligations, regulated services, material reporting, cyber risk or reputation. In those settings, a board should not rely on occasional management updates. It needs a defined forum that can request evidence, challenge risk appetite and escalate unresolved decisions to the full board.
The forum does not have to be a new committee. The FRC guidance says board committees should have proper terms of reference and should explain how their work complements other committees. For AI, that often means audit and risk owns the core oversight, with clear input from data protection, cyber security, people, procurement and technology leads. A separate AI committee makes sense only where the volume, novelty or materiality of AI decisions would overload existing committees.
The board should also remember the wider governance frame. The 2024 UK Corporate Governance Code operates on a comply-or-explain basis for listed companies and now puts more pressure on boards to report outcomes and material internal controls. Even outside listed-company scope, the logic is useful: AI oversight is credible only when the board can show what it reviewed, what it decided and what changed.
What AI governance committee terms of reference must cover
The terms should be short enough to use, but precise enough to prevent drift. The table below gives the minimum operating clauses.
| Clause | Board decision | Evidence the committee should receive | Usual owner |
|---|---|---|---|
| Purpose and authority | Is this a full board committee, a subcommittee of audit and risk, or an executive forum reporting to the board? | Board minute approving the mandate and delegated authority | Chair and company secretary |
| Scope | Which AI systems, suppliers and use cases are in scope, including embedded vendor AI and staff-used tools? | Current AI inventory, with owner, purpose, data use and status | Accountable AI owner |
| Risk appetite | What AI uses are approved, restricted or prohibited? | Board-approved AI risk appetite and policy exceptions log | Board, advised by risk lead |
| Approvals | Which AI deployments need committee review before go-live? | Approval papers, risk assessments, testing records and unresolved concerns | Executive sponsor |
| Data protection | Which systems process personal data and need a DPIA or reassessment? | DPIAs, lawful-basis analysis, processor mapping and human-review route | DPO or privacy lead |
| Supplier oversight | Which suppliers provide AI capability, and what do contracts say about data, model changes and audit rights? | Supplier due diligence, contract clauses and change notices | Procurement and legal |
| Controls and incidents | What controls operate, and what is escalated immediately? | AI risk register, incidents, near misses, redress requests and control exceptions | Risk and operational owners |
| Reporting | What does the committee report to the board, and how often? | Committee minutes, dashboard, decisions, escalations and action tracker | Committee chair |
This table deliberately starts with purpose and authority. A committee without delegated authority can receive papers but cannot govern. It also ends with reporting, because the committee is not a substitute for the board. It is the board's working mechanism for informed oversight.
The standing evidence pack should include at least five artefacts: the AI inventory, the live AI risk register, a data protection assessment pack, supplier review records and an action tracker. Where the committee cannot obtain those artefacts, the absence is itself a finding. Our article on twenty AI questions UK boards should ask uses the same test: a good answer produces a dated document, not a verbal assurance.
What the board needs to decide
Before the company secretary drafts the mandate, the board should decide five things.
- Where the work sits. AI oversight can sit with audit and risk, a technology or transformation committee, a temporary board committee, or the full board. The decision should follow the risk, not the org chart.
- What authority is delegated. The terms should say whether the committee can approve AI deployments, pause them, require remediation, commission assurance or only recommend action to the board.
- Who must attend. The FRC guidance reserves committee membership for board members, but attendees can include the accountable executive, DPO, CISO, general counsel, internal audit, procurement and external advisers by invitation.
- Which decisions must be escalated. Escalation triggers should include high residual risk, significant automated decisions about people, personal-data processing without a completed DPIA, material supplier changes, serious incidents, and any use that falls outside risk appetite.
- What evidence is enough. A committee that receives narrative updates will become a briefing forum. The board should specify the artefacts required for a decision: risk assessment, control evidence, supplier assurance, human-review design, testing results and legal sign-off where relevant.
Those decisions are not technical. They are governance decisions. The committee can ask specialists to explain model behaviour, cyber controls and data flows, but the board retains the judgement about appetite, accountability and evidence.
Framework mapping for the committee
The committee should not invent a private AI governance language. It should map its terms to frameworks and regulators that already shape board scrutiny.
| Framework or source | What it asks the committee to cover | ToR implication |
|---|---|---|
| UK AI principles | The government response to the AI regulation consultation confirmed five principles for regulators: safety, transparency, fairness, accountability and contestability. | Add a standing principle-to-control review for each material AI system. |
| ICO accountability | The ICO's AI guidance says organisations using AI with personal data are responsible for complying with data protection law and demonstrating that compliance. | Require DPIAs, controller or processor mapping, human-review evidence and privacy-risk actions. |
| NIST AI RMF | The NIST AI RMF Core is organised around Govern, Map, Measure and Manage, with governance feeding the other functions. | Structure reports around governance, system context, measurement and risk treatment. |
| ISO/IEC 42001 | ISO/IEC 42001 specifies requirements for an AI management system and covers policies, objectives, processes, risk and improvement. | Make the committee the review route for the AI management system, not just individual projects. |
| FRC internal controls | The 2024 Code asks boards to report more clearly on material internal controls, with Provision 29 applying for financial years beginning on or after 1 January 2026. | Treat AI controls as part of the material-control conversation where AI affects reporting, operations or compliance. |
| Cyber security | The NCSC secure AI guidance and the DSIT AI Cyber Security Code of Practice both point boards towards ownership, logging, monitoring, update management and baseline AI security principles. | Add AI-specific cyber questions to the evidence pack, not only ordinary IT-security reporting. |
This mapping also keeps the committee from becoming a parallel bureaucracy. The committee asks for evidence that the existing management system is working. It does not rewrite every policy itself.
For EU exposure, the terms should require a dated scoping view rather than a standing assumption. A UK organisation may still need to consider the EU AI Act where its AI system or output reaches the EU market. Our EU AI Act guide for UK organisations sets out that scoping logic in more detail.
Common mistakes
Creating a committee with no authority. A board can discuss AI every quarter and still have no governance if the committee cannot require evidence, send work back, commission assurance or escalate unresolved risk.
Putting every AI question in one forum. AI touches risk, cyber, data protection, procurement, workforce and strategy. The terms should say which committee owns which part and how papers move between them. The FRC guidance makes that complementarity an explicit committee-design issue.
Treating the risk register as an annual appendix. AI risk changes when a new tool is adopted, a supplier changes its model, a use case moves from pilot to live, an incident occurs or a regulator updates guidance. A register reviewed once a year will not show that. The committee should receive a live register with changes since the last meeting, open actions and overdue owners.
Confusing attendance with accountability. Inviting the CISO, DPO or CTO does not make those roles accountable for the board's decision. The terms should name the executive owner of AI governance and the committee chair responsible for reporting to the board.
Letting suppliers define the evidence. Vendor assurance is useful, but it is not the board's whole evidence base. The committee needs its own view of purpose, data use, risk, controls, testing, contractual protections and the ability to stop or change use.
Writing a mandate before taking a baseline. Boards often start with a ToR template because it feels concrete. Start instead with a list of AI systems and gaps. Our UK AI governance framework explains why inventory, policy, controls, evidence and assurance need to connect.
Next step
Before drafting the terms, run a short baseline. Identify the AI systems already in use, the decisions they influence, the data they process, the suppliers involved and the artefacts you can produce today. Then ask whether the board can see enough to govern them.
For a quick board baseline, take the Board AI Scorecard. For an operating risk artefact, build an initial AI risk register and bring it to the committee-design discussion. If the gap is broader than one document, the GovernIQ diagnostic maps AI use, controls, evidence and assurance into a sequenced board plan.
The terms of reference should be the record of those decisions, not the first attempt to understand the problem.
Last reviewed: 17 June 2026.
Sources: FRC Corporate Governance Code Guidance; FRC UK Corporate Governance Code 2024; DSIT government response to AI regulation; ICO AI accountability guidance; NIST AI RMF Core; ISO/IEC 42001; NCSC secure AI system development guidance; DSIT AI Cyber Security Code of Practice.
