An AI risk appetite statement tells executives which AI risks the board will accept, reduce, transfer or refuse. It should name prohibited uses, approval thresholds, evidence requirements, escalation triggers and review cadence, so teams can innovate inside boundaries the board has actually approved.
The document is not a slogan about being "careful with AI". It is the board's operating boundary for adoption. It belongs inside the wider board accountability model, sits above the AI risk register, informs the questions directors ask, and gives management a test for whether a use case can proceed, must be redesigned, or needs board approval before money is spent.
Key takeaways
- A board appetite statement should define what the organisation will not use AI for, which use cases need approval, what evidence is required, and when a decision must return to the board.
- The UK's regulator-led approach means appetite must map to real duties, including the five DSIT principles, UK GDPR accountability, sector rules and directors' duties.
- The ICO says a zero-tolerance approach to all risks to rights and freedoms is unrealistic; the board's job is to identify, manage, mitigate and document the residual risk it accepts.
- NIST AI RMF profiles are specific to an application setting, requirements, risk tolerance and resources, so one generic appetite line cannot govern every model, supplier feature and automated decision.
- The test is evidence: if an executive cannot show the control, threshold, owner and dated record behind a risk boundary, the appetite has not reached the system.
Who this applies to
This applies to boards and audit, risk or technology committees that already have AI in use, whether bought, built or embedded inside products they license. It is especially relevant where AI touches personal data, informs decisions about people, generates regulated advice, automates customer interactions, screens applications, drafts board material, or changes operational controls.
For UK companies, the appetite decision also sits inside ordinary board duties. Section 172 of the Companies Act 2006 requires directors to consider long-term consequences, employees, customer and supplier relationships, community and environmental impact, reputation for high standards of conduct, and fairness between members. AI adoption can touch several of those factors at once.
For listed companies using the UK Corporate Governance Code, the FRC's code guidance says risk appetite differs by company and sector, and that boards must decide what information they need to monitor material controls. Even where the Code does not apply, that is a useful governance test: do we know the risks we are willing to take, and can we show the controls working?
What the board needs to decide
The board does not need to approve every prompt, model or supplier feature. It does need to set the boundary within which those decisions are made. Five decisions matter.
- Which AI uses are prohibited. Examples might include final decisions about employment, housing, eligibility, safeguarding or credit without a meaningful human review route, or uploading confidential client data to unmanaged public tools.
- Which uses need board or committee approval. High-impact uses involving people, safety, regulated advice, financial reporting, legal rights or public-service allocation should not be approved by a project team alone.
- Which residual risks can be accepted. The ICO's AI accountability guidance says AI risk decisions depend on the nature, scope, context and purpose of processing, and that the DPIA should record residual risk after mitigation.
- What evidence management must produce. A verbal assurance is not enough. The board should require a dated system register, DPIA or impact assessment where personal data is involved, risk-register entry, approval record, testing result, supplier due diligence record, incident log and named owner.
- When the appetite is reviewed. The NIST AI Risk Management Framework describes profiles as specific to a sector, organisation or application context, based on requirements, risk tolerance and resources. Review should be triggered by new AI systems, model changes, incidents, material supplier changes, regulatory updates and assurance findings, not only by the annual policy cycle.
The practical output is a set of thresholds. Below threshold, management can proceed inside policy. At threshold, the use case must be assessed and recorded. Above threshold, it comes to the board or committee. Outside appetite, it does not proceed until redesigned. Those thresholds should then appear in the AI approval paper and the standing board report, so directors can see when appetite is being tested.
What an AI risk appetite statement should contain
A useful statement has six parts. Short is acceptable; vague is not.
| Component | Board decision | Evidence the board should expect |
|---|---|---|
| Purpose | Why the organisation uses AI, and which strategic goals it may support | Approved AI position or strategy, minuted at board level |
| Prohibitions | Uses the organisation will not allow | Policy clauses, staff guidance and supplier restrictions |
| Approval thresholds | Use cases that need executive, committee or full-board sign-off | Approval matrix, terms of reference and decision records |
| Risk tolerances | The residual risk levels accepted for defined categories | Risk-register scoring method, DPIA conclusions and owner sign-off |
| Control requirements | Minimum controls before deployment | Testing records, human review process, disclosure text, audit trail and security assessment |
| Review triggers | Events that force reassessment | Change log, incident log, model-update record and scheduled review dates |
Two distinctions keep the document usable. First, separate prohibited use from controlled use. A board may prohibit AI from making a final dismissal recommendation, while allowing AI to summarise policy documents for a trained HR adviser. Second, separate enterprise AI from shadow AI. Staff use of unmanaged tools needs its own boundary, because the control issue is data handling and evidence, not model risk alone. That is why an appetite statement should link directly to a shadow AI policy or acceptable-use rule, not sit apart from it.
The statement should also connect to the register. If an AI use falls inside appetite, the register still records the risk, control, owner and date. If it falls outside appetite, the register records either the rejection or the redesign condition. Our AI Risk Register Generator is a practical way to turn the statement into rows with owners and evidence.
Controls and evidence
The board should test the appetite by asking what control makes each boundary real. The answer should be a record, not a sentence.
| Appetite boundary | Control | Evidence | Owner |
|---|---|---|---|
| No final AI decision about a person without review | Human review route with authority to change the outcome | Review log showing accept, amend and overturn decisions | Accountable executive and process owner |
| No personal data in unmanaged public tools | Approved-tool list, access controls and staff attestations | Policy communication, training record and exception log | Data protection lead and IT owner |
| No high-impact AI deployment without assessment | DPIA or equivalent impact assessment before go-live | Completed assessment, residual risk decision and DPO advice where relevant | System owner and DPO |
| No supplier AI feature without due diligence | Procurement questions on data use, model updates, security and audit rights | Supplier register entry and signed contract clauses | Procurement lead and risk owner |
| No live model change without reassessment | Change trigger tied to testing and risk-register update | Model-version log, test result and updated residual rating | Product or technology owner |
| No AI system without security review | AI-specific threat model and secure deployment checklist | Security assessment, logging plan and incident route | Security lead |
This is where the appetite statement becomes useful to management. It tells a project sponsor what to gather before asking for approval. It tells a risk owner what to monitor after launch. It tells internal audit what evidence should exist if the control is real.
The ICO guidance makes this concrete for personal data. Senior management cannot delegate AI data-protection issues to data scientists or engineering teams; they remain accountable for understanding and addressing them. The same guidance says DPIAs should record whether risks are eliminated, reduced or accepted, and that the DPIA should be treated as a live document when processing or risk changes. Those are appetite mechanics, not paperwork preferences.
Framework mapping and common mistakes
The appetite statement should not attempt to reproduce every framework. It should translate them into the board's decisions.
| Framework or source | What it contributes | Board test |
|---|---|---|
| DSIT five principles | Safety, transparency, fairness, accountability and contestability as the UK cross-sector frame | Which control and evidence artefact sits behind each principle? |
| ICO AI guidance | Accountability, DPIAs, residual risk, meaningful risk appetite and live reassessment for personal data | Can we show why this AI use is necessary, proportionate and within accepted residual risk? |
| NIST AI RMF | Govern, Map, Measure, Manage, plus contextual risk tolerance | Is the tolerance set by use case, and does the register measure it over time? |
| ISO/IEC 42001 | Management-system discipline for policies, objectives, processes and continual improvement | Does the appetite link to policy, operation, performance evaluation and improvement? |
| FRC guidance | Board focus on principal and emerging risks, material controls and evidence for effectiveness | Which AI controls are material, and what evidence supports the board's view? |
| EU AI Act Article 9 | Continuous risk management for high-risk systems, with residual risk judged acceptable | If EU exposure exists, have we tested against predefined metrics and thresholds? |
| NCSC secure AI guidelines | Secure design, development, deployment, operation and maintenance | Have AI-specific security risks been assessed, not just ordinary IT risks? |
Common mistakes follow a pattern.
Mistake 1: a single traffic-light appetite. "Low appetite for AI risk" tells nobody what to do. It does not distinguish a staff drafting tool from an automated decision about a vulnerable person. Use cases need categories and thresholds.
Mistake 2: zero tolerance for every risk. The ICO is explicit that zero tolerance is unrealistic for risks to rights and freedoms. The board should be strict about prohibited uses and high-impact decisions, but honest that some residual risk will be accepted after controls.
Mistake 3: treating suppliers as outside scope. A supplier feature still needs data-use terms, model-change triggers, security evidence and exit rights. If the supplier cannot answer, that is a risk decision.
Mistake 4: no link to the register. An appetite statement without register rows is a board paper. A register without appetite is a list of worries. They should be the same system viewed at different levels.
Mistake 5: no review trigger. AI behaviour changes, regulation changes and usage changes. A statement reviewed only once a year will miss the moments when appetite is actually tested.
Next step
Start with one board workshop, not a policy rewrite. Take the highest-impact AI systems already in use and sort each into four categories: prohibited, board-approved, management-approved with controls, or routine use inside policy. Then record each decision in the risk register with a named owner and evidence requirement.
If you need the baseline first, use the Board AI Scorecard. If you already know the systems and need a register, use the AI Risk Register Generator. If the board needs the appetite, controls and evidence mapped into a sequenced programme, the GovernIQ diagnostic is the paid next step.
Do not wait for the perfect framework. The first useful appetite statement can fit on two pages. Its value is not length; it is that the next AI proposal has somewhere to land, and the board has a standard by which to accept, challenge or refuse it.
Last reviewed: 17 June 2026.
Sources checked: FRC Corporate Governance Code guidance; DSIT AI regulation government response; ICO AI accountability and governance guidance; NIST AI Risk Management Framework; ISO/IEC 42001:2023; NCSC secure AI system development guidelines; European Commission AI Act Article 9 text; Companies Act 2006 section 172
