Building an AI governance policy for your board: a practical framework

Most organisations are already using AI faster than they are governing it. This guide sets out a seven-part framework for an AI governance policy that a board can actually approve, monitor and report against – including what belongs at board level and what should be delegated.

Why an AI policy is on the board agenda

There are two key reasons why an AI governance is now crucial to boards.

Firstly, many AI tools have arrived inside organisations through the side door – in productivity suites, CRM systems, recruitment platforms, contract review tools and, increasingly, in the board’s own software. Very few of these arrivals went through a formal approval process, because most were delivered as features of products the organisation had already bought.

Secondly, regulators, auditors and insurers have all begun asking a version of the same question: who decided this was safe, and how do you know it still is?

The current policy position

For UK boards, four developments frame the current position:

• The UK has no single AI statute: Regulation runs through existing law and existing regulators – the ICO on personal data, the FCA and PRA in financial services, the MHRA, Ofcom, the CMA and others in their own domains. The government reaffirmed this sector-led approach in the AI Opportunities Action Plan and the DSIT Blueprint, favouring targeted sandboxes over a comprehensive statute. In practice, this means your sector regulator’s guidance is your rulebook.
• The ICO is preparing a statutory code on the development and use of AI and automated decision-making, following the Data (Use and Access) Act 2025. When published, it will be the practical compliance manual for any AI system touching personal data in the UK.
• The EU AI Act applies to many UK organisations: Through EU subsidiaries, EU customers, or systems whose output is used in the EU. Its timetable was amended by the Digital Omnibus on AI in July 2026: the heaviest high-risk obligations for standalone Annex III systems now apply from December 2027, and for AI embedded in regulated products from August 2028. Crucially, the transparency obligations and the AI literacy duty were not deferred. Reading only the “the EU delayed the AI Act” headline is a mistake.
• Provision 29 of the UK Corporate Governance Code applies to financial years beginning on or after 1 January 2026, requiring boards of premium-listed companies to declare the effectiveness of material internal controls. Where AI is material to operations, it falls inside that declaration.

Underneath all of this sits the older and more durable point: a director’s duty under section 174 of the Companies Act 2006 to exercise reasonable care, skill and diligence does not pause because a technology is unfamiliar.

The framework: seven components

1. Scope and definitions

Start by defining what the policy covers, in language a non-technical director can apply. A workable scope covers any system that generates content, makes or materially influences a decision, or processes data in ways the organisation cannot fully explain – regardless of whether it was procured as “AI”.

State explicitly whether the policy covers: 

• AI embedded in third-party software
• AI used by suppliers acting on your behalf
• personal tools used by staff on work matters
• AI used by the board itself. 

The last of these is the most frequently omitted and the most sensitive.

2. Risk tiering

Not every use case warrants the same scrutiny. A three-tier model is usually enough and keeps the policy usable:

Tiering does the real work of a policy. It tells the organisation where to spend its limited assurance effort and gives the board a defensible basis for not scrutinising everything.

3. Accountability and decision rights

The most common failure in AI governance is diffusion – everyone is consulted and nobody is accountable. Set the allocation out explicitly:

A useful test: if a journalist asked tomorrow who approved a particular AI-driven decision, could you name a person and produce the paper? If not, the accountability structure is not yet real.

4. Permitted, restricted and prohibited uses

Boards often want to avoid a prohibited list on the basis that it dates quickly. In practice a short one is valuable, because it gives staff certainty. Common inclusions are: 

• no confidential board or personnel information into consumer AI tools
• no fully automated decisions about individuals without human review
• no AI-generated content published externally without named human sign-off
• no AI-generated legal, financial or regulatory advice relied upon without professional verification.

Pair this with an approved tools register – the list of what has been assessed and cleared, who owns each entry, and when it was last reviewed. The register is the single most useful artefact the policy produces, and the one auditors ask for first.

5. Data, confidentiality and intellectual property

Set out where organisational data may go, what contractual terms are required from suppliers (no training on your data, data residency, deletion rights, breach notification, sub-processor transparency), and how AI-generated material is treated for IP and record-keeping purposes.

For regulated firms and anyone holding significant personal data, tie this section directly to your existing data protection framework rather than building a parallel one. AI governance that does not connect to DPIAs, records of processing and retention schedules will duplicate work and eventually contradict itself.

6. Human oversight, transparency and challenge

Define what “human in the loop” means in operational terms, because it is a phrase that frequently means nothing. Specify: who reviews, what they see, what authority they have to override, and what evidence of review is retained. Oversight that consists of a busy person clicking “approve” is not oversight, and will not withstand scrutiny.

Alongside this, decide your disclosure position: when will you tell customers, employees or shareholders that AI was involved? Setting this in advance is considerably more comfortable than deciding it during an incident.

7. Monitoring, reporting and review

Agree what the board sees and how often. A realistic starting point is a short quarterly report covering: new high-tier use cases approved; changes to the register; incidents or near-misses; supplier changes; regulatory developments; and training completion. Add an annual policy review, and a trigger-based review for material regulatory change or a significant incident.

If you want an external reference point for the control set, ISO/IEC 42001 (AI management systems) and the NIST AI Risk Management Framework – organised around Govern, Map, Measure and Manage – are the two most widely used. Neither is mandatory in the UK. Both are useful for demonstrating that your framework was not invented from scratch.

The board’s own use of AI

This deserves a separate paragraph because boards routinely write policies for the organisation that they do not apply to themselves.

AI features now appear inside board management software: summarising papers, drafting minutes, answering questions across historical board material, transcribing meetings. These tools handle the most sensitive information the organisation holds – draft strategy, personnel matters, transactions, legal advice subject to privilege.

Before enabling any of it, the board should be able to answer: 

1. Where is this data processed and stored?
2. Is it used to train models?
3. Who can see AI-generated summaries and are they subject to the same access controls as the underlying papers?
4. What happens to meeting transcripts?
5. Is AI-drafted content clearly distinguished from approved minutes?
6. Can the feature be turned off for particular meetings or papers? 

These are reasonable questions to put to any provider, and a provider who cannot answer them clearly has told you something useful.

Five questions for the next board meeting

1. Do we have a complete register of where AI is used in this organisation, including in software we already owned?
2. Which uses could materially affect an individual’s rights, and who signed those off?
3. What contractual protections do we have from our AI suppliers on data use and training?
4. If an AI-driven decision caused harm tomorrow, who is accountable and what evidence of oversight could we produce?
5. Does this policy apply to the board’s own tools — and have we checked?