What belongs in an AI risk register?

Thesis

An AI risk register is most useful when it records context, evidence, owners, and residual risk rather than reducing governance to a model score. The practical test is not whether an organization can point to a policy or standard, but whether it can show repeatable decisions, accountable ownership, and evidence from the systems actually in use.

Market context

A practical way to turn the NIST AI Risk Management Framework into owned, reviewable enterprise work. That distinction matters because ai governance programs often begin as technology purchases and only later encounter questions of ownership, exceptions, evidence, and change control. Feature lists do not reveal whether a control survives a new release, supplier change, unusual workload, or incident. The relevant unit of analysis is the operating system around the technology: who decides, what is measured, which dependencies are in scope, and how a failed assumption is detected.

Standards give customers, suppliers, engineers, auditors, and executives a shared vocabulary. They also create a familiar trap: treating conformance language as evidence that every deployment is controlled. The same capability can produce different risk depending on configuration, data sensitivity, users, integrations, and consequences of failure. A useful program translates source material into service-level requirements and records where local judgment begins. This makes disagreement visible before procurement or release, when alternatives remain affordable.

AI RMF 1.0 has four functions: Govern, Map, Measure, and Manage. The market incentive is to promise a simple outcome—portability, trust, security, compliance, or control—from a complex mechanism. A durable buying posture separates mechanism from outcome. Teams should ask what it proves directly, what it merely makes observable, and what remains dependent on governance or another system. That separation supports realistic contracts: unresolved dependencies can be priced and assigned rather than hidden inside a transformation label.

Evidence

• NIST organizes AI risk management around Govern, Map, Measure, and Manage. Its framework treats governance as a cross-cutting function and asks organizations to establish accountability, document intended use, measure identified risks, and prioritize responses. That structure supports a living register linked to decisions, not a one-time compliance checklist. This is the strongest foundation for the brief's thesis because it describes the mechanism or responsibility in the primary source's own scope. For implementation, the statement should become a control objective with an owner, an observable result, a review cadence, and a defined failure response. Merely naming the source in a policy does not establish that the objective is operating. Evidence should be associated with the relevant product, environment, release, or decision so reviewers can distinguish current assurance from historical intent.
• NIST's Generative AI Profile adds risks specific to generative systems, including confabulation, information integrity, privacy, and information security. A practical register should therefore distinguish the base model, application, data flows, users, safeguards, evaluation evidence, incident signals, and accepted residual risk. The operational consequence is that assurance must follow the boundary described by the standard rather than the boundary suggested by a vendor category. Teams should document inputs, outputs, identities, configurations, and external dependencies at that boundary. They should also preserve enough context to reproduce a decision after personnel or tooling changes. This is especially important when an exception is approved: the record needs the reason, compensating controls, expiry condition, and accountable approver, not simply a pass-or-fail field.
• Read together, the sources support a layered control model. The technical specification or framework establishes common semantics, while local policy determines risk tolerance and the evidence needed for a particular use. That division is valuable rather than defective: a universal document cannot know an organization's architecture or consequence model. The mistake is leaving the local layer implicit. A control map should identify which requirements are inherited, which are configured by the customer, which are shared with suppliers, and which depend on human review. Tests can then target each layer without claiming that one successful check proves the whole system.
• Evidence quality depends on freshness and traceability. A questionnaire or annual certification may establish that a capability existed, but not that it governed the release under review. Stronger evidence is generated near execution and tied to versions, artifacts, policy revisions, resources, identities, and timestamps. Sample judgment-heavy processes, but automate deterministic checks where feasible. The record should let incident teams distinguish failure in policy, implementation, data, or an accepted exception.

Competing viewpoints

One viewpoint favors standardization first. On this account, the fastest route to lower risk and lower integration cost is to adopt the primary framework closely, minimize local extensions, and require suppliers to produce compatible evidence. Common terminology reduces translation work, supports automation, and gives procurement a defensible minimum. This view is strongest where many teams or vendors must interoperate and where bespoke controls would fragment assurance. It also cautions against waiting for a perfect enterprise model: a well-scoped baseline can expose gaps immediately and improve through measured revisions.

A competing viewpoint emphasizes context and warns that formal alignment can create false confidence. A standard may describe interfaces, practices, or outcomes without validating a particular implementation, business decision, or threat model. From this perspective, the organization should start with failure scenarios and consequence, then use the standard selectively as a toolkit. That approach can produce better-targeted controls, but it costs more to govern and may reduce comparability. The sensible synthesis is a common baseline plus explicit, evidence-backed deviations—not blind conformance and not unstructured local invention.

Implications

• Assign a named owner and review trigger to every material risk.
• Link each mitigation to test evidence, deployment context, and an escalation path.
• Reassess entries when models, prompts, data sources, or user populations change.
• Budget for evidence collection, exception handling, and periodic retesting; these are continuing operating costs, not one-time implementation tasks.
• Use procurement and architecture review to expose dependencies early, because a technically valid control can still fail when ownership or supplier obligations are ambiguous.

Actionable takeaways

• Write a one-page scope statement naming the covered systems, data, users, environments, and explicit exclusions. Give the scope an owner and review date.
• Convert each cited principle into a testable requirement with an evidence source, pass condition, collection cadence, and escalation route.
• Run one representative end-to-end test, including an adverse or exception case, and retain the configuration, inputs, outputs, and decision record.
• Add relevant requirements to supplier evaluation and contracts. Ask for product-specific evidence and change notification rather than provider-wide assurances.
• Review the control after material releases, architecture changes, incidents, and supplier changes; close expired exceptions or renew them with fresh evidence.

Limitations and risks

The NIST framework is voluntary and outcome-oriented; it does not prescribe a universal scoring method or determine which legal obligations apply in a jurisdiction. The primary sources define mechanisms, practices, or reference models; they do not measure this organization's implementation or guarantee an outcome. This is not a product comparison, legal opinion, penetration test, or audit conclusion. Applicability changes with architecture, versions, contracts, jurisdiction, threats, and data sensitivity. Validate assumptions against current source editions and product documentation, test representative failures, and obtain specialist advice for regulated or high-consequence decisions.

Sources and citations

1. Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST, accessed 2026-10-07
2. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST, accessed 2026-10-07

Related briefs