AI governance and board accountability

The most common failure in AI governance is not a missing policy. It is a governance body that deliberates but does not decide, and accountability that is discovered during an incident rather than attached before one.

When a CISO asks me to help stand up AI governance, the first thing I say is: do not build a new programme. Your firm already has a board risk committee, an operational-risk function, a model-risk function, a third-line internal audit, and a named-accountability regime. Generative and agentic AI does not justify a parallel universe of governance. It justifies four targeted additions inside the structure you already have.

The failure mode I see most often is the standalone AI ethics committee that meets monthly, owns nothing the rest of the firm is bound by, and produces principles no engineer can act on. What boards and regulators need is an operating model that decides and is accountable, not one that deliberates.

The stake

In a regulated firm, accountability for a material AI failure does not land on “the company.” It lands on an identifiable senior individual. That is what makes financial services different from most other sectors, and it is why AI governance in a regulated firm has to be precise about accountability, not merely principled about ethics.

A board can answer four questions from standing artefacts, or it cannot. What AI do we run, and who owns each piece? What autonomy have we permitted, and against what appetite? Which named individual is accountable if it fails? And how do we evidence all of that to a supervisor? If your operating model cannot answer those four without convening a project, it is not yet operating.

Addition 1: an AI policy that draws the trust boundary

The policy is the artefact that turns controls into firm-binding rules. It needs to state, at minimum, three things.

What the firm permits and prohibits. Shadow copilots, unsanctioned model endpoints, ungoverned Model Context Protocol connectors. These are specific categories, not a general “follow best practice” line.

The mandatory controls every AI use case inherits. The gateway as the egress chokepoint, scoped workload identity, logging, guardrails. These are designed elsewhere; the policy references them, not restates them, and makes them non-optional for every use case.

The autonomy the firm will and will not grant without human oversight. This is the part most policies omit. An agent that acts autonomously in a money-movement or regulated-decision path is a materially different risk than one that drafts for human approval. The policy needs to say which autonomy levels require which oversight controls, in terms an engineer can check.

A policy that does not bind a build pipeline is decoration. Point it at the approval lifecycle as its enforcement mechanism.

Addition 2: named accountability that attaches before an incident

In a regulated firm, named accountability means specific things: every AI use case in the inventory has a named accountable owner; the governance forum has a named chair who is accountable for the forum’s decisions; and the mapping from AI risk to the firm’s senior-accountability regime is documented.

The design principle is simple and durable. No AI capability goes live without a named human who is accountable for it. This is not a principle about blame. It is a control that makes the accountability attachment visible to a supervisor during an inspection and to the board during a risk review.

I do not advise on what the regime requires in terms of statements of responsibility or specific function-holder designations. That is a matter for qualified counsel and for the obligations owned in the senior-accountability and EU AI Act regimes. What I do is design the operating model that makes the firm able to satisfy those obligations, by ensuring the attachment exists before it is asked for.

Addition 3: risk appetite in autonomy-spectrum terms

A generic “low appetite for AI risk” statement is unenforceable. A usable appetite statement says, for example, that the firm will not deploy an agent at act-autonomously in a money-movement or regulated-decision path; that explicit sign-off is required for any deployment touching cardholder or special-category data; and that aggregate AI spend and action-rate limits are board-visible.

I use four points on the autonomy spectrum to express appetite: suggest, draft-for-approval, act-with-guardrails, and act-autonomously. Each level carries a materially different blast radius. A suggestion-only copilot over public data is a different risk from an autonomous agent with write access to customer accounts. Expressing appetite in these terms makes it directly testable against a proposed use case, which is exactly what the tiering method in the next section consumes as its input.

Addition 4: a control mapping to recognised frameworks

Map your AI governance to the two frameworks a board and an auditor will recognise.

The NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023) organises AI risk management into four functions: Govern, Map, Measure, and Manage. Govern is the cross-cutting accountability function the rest depend on. Use it as the framework that structures your governance functions. It is voluntary guidance, not law, but it is the vocabulary a regulator will recognise.

ISO/IEC 42001:2023 specifies requirements for an AI management system. It is certifiable, in the same family as ISO/IEC 27001, and it is what an enterprise customer’s due-diligence questionnaire will increasingly ask for. Use it as the management-system skeleton your policy, roles, and lifecycle hang from.

The value of the mapping is legibility. When you can show that your AI policy, your accountable-owner model, your risk appetite, and your approval gates correspond to NIST AI RMF’s Govern and Map functions and to ISO/IEC 42001’s AIMS structure, you have a governance story a board recognises and an auditor can test.

The operational machinery: inventory, tiering, and the approval lifecycle

The operating model decides. The operational machinery is the process it runs. Three artefacts make the policy operational.

A live inventory keyed to the use case, not the model. The same foundation model can sit behind a low-risk drafting copilot and a money-movement agent. The risk lives in the deployment. For each use case, record the named owner, the models and topology, the data classes it touches, its position on the autonomy spectrum, the tools and connectors it can invoke, and its current tier and status.

A three-factor risk tiering method. Tier each use case on data sensitivity, autonomy level, and customer or market impact, then take the worst-case roll-up, not an average. A high score on any one factor pulls the use case up. A drafting copilot over public data with no autonomy is low tier. An agent with money-movement tools touching customer data near a regulated decision is top tier and inherits the heaviest gates.

An approval lifecycle whose gates make controls non-optional. Each gate is a checkpoint that consumes evidence the relevant control is in place before the use case advances. The tier determines how heavy each gate is and how high the approval escalates: low-tier use cases approved by the first-line owner under delegated authority; top-tier use cases escalated to the governance forum. The lifecycle stops when the controls are evidenced. Behaviour validation and drift monitoring are model risk management, which is a separate discipline.

What to do this week

1. Write down the four questions a board should be able to answer from standing artefacts. For each, note whether your current operating model can answer it without convening a project. The gaps are your workplan.
2. Check whether every AI use case in production has a named accountable owner documented somewhere. If not, start the inventory this week.
3. Take your current risk appetite statement for AI and ask whether it is testable against a specific proposed use case. If the answer is “not really,” express it in autonomy-spectrum terms instead.
4. Map one governance decision you made recently, for example approving a new AI copilot, to the lifecycle steps: intake, tiering, design gate, runtime gate, sign-off. Note where evidence was or was not produced at each gate.

For the question of whether to bring in a vCISO, fractional CISO, or BISO to own AI governance, and how those models differ in practice, see our pillar on vCISO vs fractional CISO vs BISO.