AI belongs on the board agenda when it affects strategy, customers, employees, operations, capital, regulation, or resilience. The board does not need to tune models or approve prompts. It does need enough visibility and evidence to set risk appetite, allocate accountability, challenge management, and decide whether the organisation can safely operate and recover from its AI-enabled services.
As at 31 July 2026, the UK does not have cross-sector legislation governing AI as a technology. The House of Commons Library’s June 2026 briefing describes a context-led landscape: existing legal frameworks, sector regulators, targeted legislation, and non-statutory principles. “No UK AI Act” is not “no obligations.” Data protection, equality, consumer, employment, safety, product, financial-services, professional, competition, intellectual-property, contract, and directors’ duties can all apply.
This article is an operating model, not legal advice. Listed companies applying the UK Corporate Governance Code, regulated firms, public bodies, and groups operating in the EU or other jurisdictions need tailored overlays.
Put every AI system on an inventory
Governance starts with knowing what exists. Include:
- internally developed models and applications;
- purchased AI services and embedded vendor features;
- generative assistants and meeting tools;
- traditional machine-learning scoring and forecasting;
- agentic workflows and automated actions;
- AI inside security, HR, CRM, finance, and productivity platforms;
- pilots, sandboxes, and shadow AI used without approval; and
- retired systems whose outputs or records remain in use.
An inventory entry should record purpose, business owner, technical owner, users, affected people, data, model and provider, locations, integrations, actions, risk tier, approvals, assessments, metrics, incidents, review date, contract, exit route, and status. Inventory the complete system, not only the foundation model.
Management should reconcile the declared inventory against procurement, identity, API, browser, expense, network, and vendor records. A policy survey alone will miss embedded and unsanctioned use.
Tier systems by consequence and capability
Risk depends on context. A public-text drafting aid and an agent that changes supplier bank details need different controls even if they use the same model. Score consequence, exposure, autonomy, reversibility, data sensitivity, scale, affected groups, legal significance, security access, and supplier dependence.
| Tier | Example | Approval and oversight |
|---|---|---|
| Low | Drafting from public material | Team owner, usage rules, sample review |
| Moderate | Internal knowledge search | Data owner, permission tests, quality monitoring |
| High | Customer recommendation or employee support | Executive risk owner, impact assessment, independent assurance |
| Critical | Safety, rights, money, or material autonomous action | Board risk appetite, specialist approval, strict human control or prohibition |
Set prohibited uses and escalation triggers. Risk appetite should state which outcomes cannot be tolerated, which require a person, maximum transaction or exposure limits, and which evidence is required before expansion. Avoid a generic “responsible AI” statement that gives delivery teams no decision rule.
Assign decisions across three lines
The board approves strategy and appetite and receives assurance. An accountable executive owns the portfolio and ensures resources. Business owners own outcomes for each deployed system. Technology, data, security, legal, privacy, risk, compliance, procurement, HR, and operations provide controls within their remits.
A practical allocation is:
- First line: product and operational owners design, operate, monitor, correct, and evidence the service.
- Second line: risk, compliance, privacy, security, legal, and relevant specialists set policy, challenge assessments, and monitor exceptions.
- Third line: internal audit provides independent assurance over governance, design, and operating effectiveness.
Committees can coordinate but should not absorb accountability. Every material incident, exception, and control has a named person with authority and budget. Suppliers do not take away the company’s responsibility for its use.
Section 172 of the Companies Act 2006 requires directors to act in good faith to promote the company’s success while considering long-term consequences, employees, business relationships, community and environment, reputation, and fairness between members. Section 174 sets the duty of reasonable care, skill, and diligence. AI oversight should support those duties with decision-relevant evidence, not technology theatre.
Build material controls around the lifecycle
For each tier, require evidence at intake, design, procurement, pre-release, operation, change, incident, and retirement.
Core controls include:
- defined purpose, owner, users, and success measures;
- documented legal, rights, equality, privacy, safety, and security screening;
- source-data quality, lineage, permissions, retention, and deletion;
- representative evaluation and consequence-weighted thresholds;
- human review, correction, contestability, and redress;
- least-privilege integrations and deterministic action limits;
- supplier due diligence, audit evidence, notification, and exit terms;
- versioned releases and regression testing for material changes;
- outcome, incident, exception, and override monitoring;
- continuity, manual fallback, rollback, and retirement; and
- records that show the control operated, not merely that a policy exists.
The DSIT AI Management Essentials guidance, updated in February 2026, groups its self-assessment around internal processes, risk management, and communication. It is a useful baseline, not a certification or substitute for sector obligations.
Connect AI to the internal-control framework
The FRC’s UK Corporate Governance Code 2024 applies on a comply-or-explain basis to companies within its scope. Most of the Code applied from 1 January 2025; Provision 29 applies for financial years beginning on or after 1 January 2026.
Provision 29 asks the board to monitor and review the risk-management and internal-control framework, covering material financial, operational, reporting, and compliance controls. The annual report includes how the board monitored and reviewed effectiveness, a declaration on effectiveness of material controls as at the balance-sheet date, and disclosure of material controls that did not operate effectively plus action taken or proposed.
Not every AI control is material. The board determines materiality in its company context. A model affecting financial reporting, operational continuity, regulatory decisions, or a major customer channel may sit within material controls; a low-risk drafting assistant may not. Finance, audit, risk, and AI owners should map the relationship rather than create a parallel “AI compliance” universe.
Evidence of operating effectiveness could include access reviews, evaluated thresholds, sampled human reviews, reconciled transactions, incident exercises, supplier monitoring, and change-control records. A signed policy or model card alone does not show a control operated throughout the period.
Report outcomes and limits to the board
Board packs should be concise enough to prompt decisions and detailed enough to expose deterioration. Include:
- inventory count and risk-tier movement;
- material use cases launched, paused, or retired;
- value delivered against baseline, net of review and remediation;
- customer, employee, safety, financial, and service outcomes;
- critical control performance and failed tests;
- incidents, near misses, complaints, corrections, and affected scope;
- open exceptions, age, owner, and expiry;
- override and human-review capacity;
- supplier concentration, service changes, and exit readiness;
- regulatory and legal developments; and
- decisions or resources required from the board.
Avoid “accuracy 94%” without task, denominator, severity, subgroup, threshold, and consequence. The board needs to know whether critical errors are within appetite and whether management can detect and contain them.
Use leading indicators—unreviewed changes, overdue assessments, reviewer backlog, expiring contracts—beside lagging outcomes such as complaints and losses.
Govern data protection and affected people
Where personal data is processed, the ICO’s AI accountability guidance makes the organisation responsible for compliance and demonstrating it, including through DPIAs where required. That guidance is under review after the Data (Use and Access) Act, so boards should track the ICO’s current notices and final updates.
Require management to answer:
- who is affected and how;
- whether processing is lawful, fair, transparent, and necessary;
- what data is inferred as well as collected;
- how inaccurate personal data and outcomes are corrected;
- whether automated decisions or profiling receive the required safeguards;
- how vulnerable or underrepresented groups are tested;
- how people can reach a competent human; and
- whether retention, sharing, and international transfers remain justified.
Engage workforce representatives, customers, domain experts, and affected groups proportionately. Formal sign-off without operational feedback can miss harms that metrics do not yet show.
Treat AI as a cyber and supplier risk
AI systems add models, data pipelines, connectors, new identities, prompts, retrieval stores, and dependencies. They can expose confidential data, amplify phishing or fraud, ingest hostile content, or perform an authorised action for an unauthorised purpose.
The NCSC Cyber Governance Code of Practice sets board actions around risk management, strategy, people, incident response and recovery, and assurance. Use the same discipline for AI-enabled cyber risk. The NCSC secure AI guidelines cover secure design, development, deployment, operation, and supply-chain responsibilities.
Boards should challenge:
- privileged system and data access;
- model and software supply-chain provenance;
- prompt injection and poisoned data;
- secrets, logs, and derived data;
- vendor model, term, and subprocessor changes;
- concentration and service outage;
- verified backup, fallback, and exit;
- incident ownership and reporting; and
- whether assurance is independent of the team rewarded for launch.
Run exercises involving a provider outage, cross-tenant leak, manipulated model, illegal agent action, and loss of the review queue.
Control exceptions and change
An exception should identify the unmet control, justification, affected scope, compensating control, risk owner, approval, expiry, and closure evidence. Do not let pilots remain permanently outside policy or renew exceptions automatically.
Define “material change” before deployment. Triggers may include a new model or provider, different purpose, new data class, new affected group, higher autonomy, larger limit, additional integration, changed retention, or a substantial performance shift. Material changes return to the appropriate assessment and approval gate.
Retirement matters too. Revoke identities, remove connectors, dispose of data and embeddings, preserve required records, update customer and staff communication, and confirm that downstream decisions do not continue using stale output.
Deliver a 90-day governance reset
Days 1–30: discover. Appoint the executive owner, issue an inventory call, reconcile procurement and identity evidence, define taxonomy and tiers, identify prohibited use, and map applicable obligations. Select the five highest-consequence systems for immediate review.
Days 31–60: decide. Approve risk appetite, owners, lifecycle gates, exception rules, incident severity, and board metrics. Close urgent permission or data gaps. Test one high-risk system’s evaluation, review, supplier, and fallback evidence.
Days 61–90: operate. Hold the first portfolio review, exercise an incident and manual fallback, run independent assurance on selected controls, age and close exceptions, and present the board with outcomes, unresolved exposure, and explicit investment or pause decisions.
Do not wait for a perfect inventory before containing a material risk. Mark uncertain entries and improve them through reconciliation.
Set board-level pause gates
Pause a system or capability when:
- a material legal, rights, safety, financial, or security threshold is breached;
- no accountable owner can evidence control;
- inventory, data lineage, or committed actions cannot be reconstructed;
- human review is ineffective or overloaded;
- material performance differs across an affected group without mitigation;
- a supplier change invalidates the approved assessment;
- an exception expires or a critical action remains overdue;
- continuity or exit cannot protect essential operations; or
- a material control fails and exposure cannot be contained.
The decision to resume should state cause, affected population and period, corrective action, validation, residual risk, accountable approver, and monitoring.
Link portfolio oversight to specialist controls
The UK AI privacy and compliance guide supports data-protection oversight. The cybersecurity and AI defence guide helps align operational monitoring with the cyber framework. For systems that can act, use the agentic workflow guide.
Decision
Effective board governance makes AI legible as a portfolio of business systems, obligations, owners, controls, outcomes, incidents, and dependencies. It does not promise that models are risk-free. It ensures that the company knows where material exposure sits, has evidence that controls operate, and can pause, correct, and exit before a small failure becomes an enterprise event.
Primary sources
- House of Commons Library: AI regulation in the UK, June 2026
- Financial Reporting Council: UK Corporate Governance Code 2024
- Companies Act 2006, section 172
- DSIT: AI Management Essentials guidance, February 2026
- ICO: AI accountability and governance
- NCSC: Cyber Governance Code of Practice
- NCSC: Guidelines for secure AI system development



