An operating model for accountable AI governance

Start with the framework, not a certification claim

NIST AI RMF 1.0 is voluntary risk-management guidance. Its four functions—Govern, Map, Measure and Manage—provide a way to organize work across the AI lifecycle. Govern is cross-cutting, not a phase to complete and forget. NIST explicitly does not present the framework as a fixed checklist or ordered sequence. Following it does not by itself establish legal compliance or certify that a system is safe.

For executives, the useful question is how each function becomes an observable management practice. Map means understanding the system’s intended use, affected people and operating context. Measure means evaluating relevant risks and limitations. Manage means making treatment decisions and following through. Govern supplies the accountability, policy and review arrangements that make those activities repeatable. The operating model below is our practical interpretation, not a NIST-prescribed organizational chart.

Assign ownership before approving deployment

Every material AI use should have a named business owner responsible for the outcome and an identified technical owner responsible for configuration and operation. Procurement should not become the default risk owner simply because it signed the contract. A purchased product still needs local decisions about permitted data, users, workflows and actions.

The governance forum should coordinate legal, privacy, security, risk and technology input, while leaving business accountability explicit. Define who can approve a use, accept an exception, restrict access and stop operation. Where independent assurance is needed, do not ask the same delivery team to be the sole judge of its own control effectiveness.

Use decision gates proportionate to consequences

A low-impact drafting assistant and an agent that can alter a financial record should not pass through an identical approval path. Classify the use by consequences, data sensitivity, exposure to people and degree of autonomy. This is an internal management classification; do not confuse it with a legal high-risk classification under a specific regulation.

Before launch, ask for evidence covering expected performance, failure modes, permissions, escalation and recovery. Conditional approval can restrict users, transactions or operational scope while uncertainty remains. Record the accepted limitation, its owner, the remediation date and what would trigger a pause. A missed control is easier to manage when the exception is visible rather than buried in a project document.

Hypothetical example: a procurement agent

Imagine a procurement agent that compares supplier bids and drafts a recommendation. The first authorization permits recommendations only. A business owner validates quality on representative bids; security checks that access is limited to relevant documents; procurement specialists review conflict and confidentiality risks. The example is illustrative, not a client case study.

If the team later requests authority to place orders, the risk changes. The review should address spending authorization, supplier changes, duplicate actions and recovery from tool failure. Approval limits should be enforced by the connected system, not just by instructions in the agent’s prompt. The expansion in autonomy is a new decision requiring evidence, even if the earlier pilot performed well.

Make board reporting decision-oriented

A board pack should expose material changes in the AI portfolio, consequential deployments, significant incidents, open exceptions and remediation progress. Pair business value with risk indicators: an increase in automated work is not an unqualified success if harmful errors or unresolved control gaps also increase. Distinguish evidence-based assurance from management confidence.

In the next management cycle, reconcile the inventory, assign missing owners and select the most consequential systems for a control review. Use a governance diagnostic to organize the discussion, then validate responses with records and responsible teams. The diagnostic is self-reported; it is not independent assurance. Escalate unresolved gaps with a decision request rather than a generic status update.

• Which material systems still lack an accountable owner?
• Which controls have been tested, rather than merely documented?
• What changed since approval, and does authorization still hold?
• Who can stop each consequential workflow today?