Most enterprises that introduce AI in 2026 already have an enterprise-risk function. The temptation is to bolt AI onto the existing register and move on. That works for procurement; it does not work for use. AI introduces categories of risk that traditional ERM doesn’t name — model drift, training-data provenance, emergent behaviour, third-party model risk — and a competent framework treats them explicitly.
Direct answer
An AI risk management framework is a structured set of practices for identifying, measuring, and controlling the risks an AI system introduces. The leading reference is the NIST AI Risk Management Framework 1.0, organised around four functions: Govern, Map, Measure, Manage. The leading certifiable management-system standard is ISO/IEC 42001:2023.
Key takeaways
- NIST AI RMF is the operating model; ISO/IEC 42001 is the certifiable wrapper.
- The four functions of NIST AI RMF are Govern, Map, Measure, and Manage.
- Govern is policy and ownership; Map is context and scope; Measure is metrics; Manage is controls and response.
- Effective programmes take 6–12 months to maturity, with inventory in the first 60 days.
- Frameworks fail when they live in policy and never reach the deploy pipeline.
The NIST AI Risk Management Framework
NIST released the AI RMF 1.0 in January 2023 and added a generative-AI profile (NIST AI 600-1) in July 2024. The framework is voluntary in the United States but is increasingly treated as the de-facto standard in enterprise procurement and federal contracting. It is organised around four core functions, each with subcategories and outcomes.
Govern
Govern is the policy and ownership layer. The framework asks organisations to establish AI policies, define roles and accountability, document risk tolerance, build the workforce, and create a culture in which risk gets surfaced rather than hidden. In practice, this means a named AI accountable executive, a cross-functional governance committee, and a written risk-tolerance statement that says what kinds of AI we will not deploy.
Map
Map is the context layer. Before measuring or managing anything, the framework asks operators to characterise the AI system in scope: the use case, the actors, the data sources, the third-party components, the stakeholders affected, and the legal and regulatory context. Skipping Map is the most common implementation mistake. Organisations jump to controls without naming what they are controlling, and the controls end up over- or under-fit to the actual risk.
Measure
Measure is the metrics and evaluation layer. The framework asks for quantitative and qualitative measurement of identified risks: validity and reliability of the model, fairness across affected groups, security against known adversarial patterns, privacy leakage, robustness to drift, and harms to third parties. Measure produces the evidence that feeds Manage.
Manage
Manage is the controls and response layer. It includes treatment of identified risks (accept, mitigate, transfer, refuse), incident response, decommissioning protocols, and ongoing monitoring. This is the layer where human-in-the-loop oversight lives, where refusal conditions get enforced, and where the connection to the rest of enterprise risk management is made.
ISO/IEC 42001 — the management-system standard
ISO/IEC 42001:2023 specifies requirements for an AI Management System (AIMS) — a certifiable set of management processes for the responsible development and use of AI. It uses the same Plan-Do-Check-Act structure as ISO 9001 (quality) and ISO 27001 (information security), which makes it familiar to organisations with existing certifications. The standard does not prescribe technical controls; it prescribes the management system that produces them.
| Dimension | NIST AI RMF | ISO/IEC 42001 |
|---|---|---|
| Type | Voluntary framework | Certifiable management-system standard |
| Structure | Functions, categories, outcomes | Clauses + Annex A controls |
| Certifiable | No | Yes (third-party audit) |
| Granularity | Practice-level | Process-level |
| Best used for | Operating model | Management-system wrapper |
The most defensible position is to adopt both. NIST AI RMF as the operating model, ISO/IEC 42001 as the certifiable wrapper that regulators and counterparties can accept as evidence of competence.
Other references worth knowing
- The EU AI Act — sets binding requirements for high-risk AI systems in the European market.
- The OECD AI Principles — high-level principles that several national frameworks descend from.
- Sector-specific guidance: e.g. the U.S. FDA on clinical decision-support software, financial-services rules on model-risk management.
A twelve-month enterprise rollout
Most enterprises do not need a custom framework. They need a sequenced rollout of the standard ones. The plan below is the version we apply when the engagement protocol reaches Deploy.
Phase 1 — Inventory (months 1–2)
Find every AI system in use. This is harder than it sounds. Shadow AI — generative tools adopted by individual employees, embedded features inside SaaS products, third-party model APIs called by engineering teams — accounts for most enterprise AI use in 2026 and almost none of it is on anyone’s register. The inventory captures: use case, owner, data flows, third parties, decision weight, and current oversight.
Phase 2 — Baseline measurement (months 3–4)
Pick the top five to ten systems by risk weight and run baseline Measure activities: documented evaluation results, fairness checks where applicable, security review, drift indicators. Output: a first-cut risk register specific to AI.
Phase 3 — Controls (months 5–8)
Build the binding parts. Policy, role definitions, gating workflows, HITL where required, refusal conditions, monitoring dashboards. Connect to existing change-management and incident-response processes. This is the most labour-intensive phase and the one most often underfunded.
Phase 4 — Audit (months 9–12)
Internal audit first. The internal audit team tests the controls against the risk register. Then external audit — for organisations pursuing ISO/IEC 42001 certification, this is the certification audit. For others, it is a third-party readiness review that satisfies counterparties and insurers.
How AI risk programmes fail
Three failure modes account for most poor outcomes.
- 01Policy without pipeline. The governance committee approves a policy that never reaches the deploy pipeline. Engineers ship without ever consulting it. The cure is to put policy assertions in code — automated checks at deploy time.
- 02Inventory drift. The inventory is accurate at week one and stale by month three. Without a recurring inventory ritual (quarterly, at minimum, with named owners), the programme controls only the systems it knew about at launch.
- 03Refusal absent. The programme is built entirely around mitigation. Nowhere does it say which AI uses the organisation will refuse — for any price, for any timeline. Without a refusal stance, the programme is a permission machine, not a risk machine.
Connecting the framework to decision systems
A risk framework is the surround; a decision system is one of its outputs. NIST AI RMF’s Manage function lists controls and response; in practice, the binding controls for high-stakes AI decisions are exactly the components of a decision system: authority check, evidence check, constraint gate, refusal contract, audit trail. The framework gives you the categories. The decision system gives you the enforcement.
Cube A Cloud designs the decision-system layer specifically. Where an enterprise risk function operates at the policy and reporting layer, our work sits at the deploy boundary — the moment an AI output becomes a commitment. If you are running a risk programme and the bottleneck is enforcement at deploy time, our contact page describes the engagement criteria.
Closing principle
A risk framework is not a binder. It is a working pipeline that turns AI use into accountable AI use. NIST AI RMF gives you the functions; ISO/IEC 42001 gives you the management system; sector regulators give you the constraints. The programme that succeeds is the one that connects all three to a refusal stance and a working decision system at deploy time.