Most organisations can name the team that wants an AI system. Fewer can name the person who answers for it when the system misbehaves, when a vendor fails, or when it should be switched off. That gap is the whole subject of this memo.

The NIST AI Risk Management Framework (AI RMF 1.0, 2023) is a voluntary framework intended to help organisations incorporate trustworthiness considerations into the design, development, use and evaluation of AI products, services and systems. Its core is organised into four functions: govern, map, measure and manage. NIST describes the core as outcomes and actions, explicitly not a checklist and not necessarily an ordered set of steps. A revised version of the framework is in progress, so treat subcategory wording as current-but-moving. The framework itself is not a legal requirement.

This memo concentrates on the govern function, because NIST describes govern as cross-cutting: it enables the other three functions, and aspects of it — especially those related to compliance and evaluation — should be integrated into each of them. If govern is thin, map, measure and manage have no one to anchor to.

The accountability question

NIST frames govern as cultivating and implementing a culture of risk management, outlining the processes and organisational schemes that anticipate, identify and manage the risks a system can pose, and connecting technical design decisions to organisational values. It also states plainly that senior leadership sets the tone for risk management within an organisation, and that management aligns the technical aspects of AI risk management to policies and operations.

That is a chain of attribution, not a job title. The useful executive question is not "does someone own AI?" but "for this specific system, who is accountable for the risk decision, who acts on it, and who is told about it?"

If you are assembling that answer for a board or leadership group, the private board brief builder is a structured place to record it. For the strategic context behind it, see NovCog.

Roles and lines of communication

Govern 2.1 in the framework's core calls for roles and responsibilities and lines of communication related to mapping, measuring and managing AI risks to be documented and clear to individuals and teams throughout the organisation. Two details in that sentence do most of the work: documented, and throughout the organisation.

A verbal understanding held by one director does not satisfy either. Nor does an unreadable RACI buried in a shared drive. Documentation matters because it makes accountability transferable — when a person leaves, the role and the reasoning survive. Communication lines matter because the person who first notices a problem is rarely the person who owns the decision; if there is no defined route upward, the signal dies where it lands.

Govern 2.2 adds that personnel and partners should receive AI risk management training to perform their duties consistent with related policies, procedures and agreements. Training is part of the ownership structure: an accountable person who cannot evaluate the risk is a name, not a control.

Executive responsibility for risk decisions

The sharpest clause in the framework for this discussion is Govern 2.3: executive leadership of the organisation takes responsibility for decisions about risks associated with AI system development and deployment.

Read that carefully. It does not say executive leadership is briefed, sponsors the programme, or is informed of outcomes. It assigns responsibility for the risk decisions themselves to executive leadership. In practice, organisations satisfy this by making the decision points explicit and assigning them to named executive roles — and by ensuring those executives see the material needed to decide.

NIST also notes that an initial go/no-go decision about whether to design, develop or deploy an AI system is informed by the map function, and that map's outcomes become the basis for measure and manage. So the executive decision is not made in a vacuum: it rests on documented context, intended purpose and risk tolerance. The pattern is decision-first, then engineering.

A worked illustration (hypothetical)

The following is a constructed example, not a case study or a reported result.

A mid-sized insurer wants an AI system to triage incoming claims. The temptation is to let the operations director own it, because operations will use it and has the strongest appetite. Under a Govern 2.3 reading, the accountable executive would instead be the one who can accept the risk of an automated decision affecting a customer — and that person needs to see the mapping work before saying yes.

Suppose the team documents the system's intended purpose and its context-specific legal expectations (Map 1.1), the business value it is meant to deliver (Map 1.4), and the organisation's stated risk tolerance (Map 1.5). The executive then makes a go/no-go decision against that record. If the answer is go, the decision is traceable; if the answer is later revisited, the original reasoning is still legible. That is what documentation buys — not compliance theatre, but a decision that can be audited and re-made.

Keeping the decision alive after launch

AI risk management, as NIST describes it, should be continuous, timely and performed throughout the AI system lifecycle, reflecting diverse and multidisciplinary perspectives. Ownership therefore cannot end at launch.

Govern 1.5 calls for ongoing monitoring and periodic review of the risk management process and its outcomes, with organisational roles and responsibilities clearly defined — including the frequency of review. Note the second half: review without an assigned owner and a set cadence tends to become a line in a slide that nobody reopens. Govern 1.6 calls for mechanisms to inventory AI systems, resourced according to organisational risk priorities. An inventory is a governance artefact: it tells you what you own.

Cross-referencing helps here. Map 2.2 asks organisations to document how system output may be used and overseen by humans, and the system's knowledge limits. Map 3.5 asks for human oversight processes to be defined, assessed and documented in line with govern policies. Those are decisions about who watches the output, made explicit rather than assumed.

Third-party and supply-chain ownership

Buying a system does not outsource accountability. The framework's govern function explicitly addresses the full product lifecycle and associated processes, including legal and other issues concerning third-party software or hardware systems and data.

Govern 6.1 calls for policies and procedures addressing AI risks associated with third-party entities, including infringement of a third party's intellectual property or other rights. Govern 6.2 calls for contingency processes to handle failures or incidents in third-party data or AI systems deemed high-risk.

The contingency point deserves attention in contract negotiations. A vendor outage, a data-source failure or a rights dispute is not merely an IT incident; it triggers a defined organisational response. If no such process exists before the incident, the organisation improvises during it — usually badly, and always under pressure.

Decommissioning as an owned decision

Govern 1.7 calls for processes and procedures for decommissioning and phasing out AI systems safely, in a manner that does not increase risks or decrease the organisation's trustworthiness. Switching a system off is a decision like any other, and it needs an owner. Too often the shutdown authority sits with whoever happens to hold the admin account. A documented decommissioning process — including who approves it, what data is retained, and what replaces the function — closes a gap that appears only when you need it most.

Mapping to ISO/IEC 23894

Organisations already using ISO/IEC 23894:2023 for AI risk management can align the two without duplicating effort. NIST publishes a crosswalk mapping the AI RMF 1.0 functions to ISO/IEC 23894:2023 clauses. The crosswalk maps GOVERN to the standard's leadership and commitment clause (5.2), its integration clause (5.3), and its design clauses (5.4) — including 5.4.3, assigning organisational roles, authorities, responsibilities and accountabilities, and 5.4.5, establishing communication and consultation.

Note two caveats from the crosswalk itself. ISO/IEC 23894 is tailored guidance for AI systems built on the general risk management guidance in ISO 31000, and its structure mirrors ISO 31000. And the crosswalk lists ISO/IEC 23894 clauses that do not map to the AI RMF — for example, 6.2 Communication and consultation. The practical implication: if your organisation treats ISO 31000 as the spine, the AI RMF gives you AI-specific language for outcomes, while ISO/IEC 23894 gives you the risk-process scaffolding. Neither replaces the other.

What to do next

Pick one live AI system — ideally one with a real customer or financial consequence. Write down, in one page: what it is for, who is accountable for the risk decision, who monitors it and how often, who is trained on it, who handles a third-party failure, and who can switch it off. If any line is blank, that is your governance gap.

That one-page record is also the core of a defensible board brief. The board brief builder and the companion memos on the first 90 days and choosing a pilot cover the adjacent decisions. For a working session on your own accountability structure, NovCog can be reached at novcog.com. Framework citations are listed on the sources page.