An AI risk register should lead to a decision someone can make

NIST’s voluntary frameworks become useful when a team connects risks to owners, test evidence and concrete responses.

A risk register can contain careful language and still leave a team unsure what to do when a model fails. The useful version connects each concern to a particular task, evidence and someone able to intervene. It should make a decision easier: proceed within a limit, change the design, investigate a result or stop the affected feature. Governance becomes practical at that point.

NIST’s [AI Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) was released in January 2023 for voluntary use. Its [generative-AI profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), published in July 2024, addresses issues associated with generative systems. The [resource collection](https://www.nist.gov/itl/ai-risk-management-framework/ai-risk-management-framework-resources) supports implementation. These are dated reference materials, not certification of a product. Readers should check NIST’s current publications before assuming the historical versions are the only applicable guidance.

An original illustrative organisation uses AI to draft answers from a public handbook. Its register identifies unsupported statements as a risk because users may act on incorrect instructions. The entry names the knowledge owner, the approved handbook version and the test that checks source support. It also says what happens if the model cannot find an answer: provide a clear limitation and a contact route.

That entry is more useful than a broad statement that hallucinations are possible. It identifies how the failure reaches a person and which control can interrupt it. The team can test whether the control works with missing sections, contradictory guidance and questions outside the handbook. A model that produces plausible text despite those gaps should not pass merely because its response is well written.

Consequences vary by task. A poor summary of an internal meeting may create correction work. An incorrect public deadline may cause someone to miss an opportunity. The same model can therefore require different boundaries in different services. Risk review should examine the whole workflow, including the authority given to the output and the way people see it.

Owners need actual authority. If a knowledge manager cannot update the source collection or suspend a stale answer, assigning them responsibility is incomplete. The register should identify who approves changes and who handles incidents. A small team can combine roles where appropriate, but the duties and escalation route must remain clear enough to survive staff turnover.

Evidence has a lifecycle too. Keep the tested configuration, prompt, permitted sources and evaluation cases together. When the supplier changes the model, decide which tests need to run again. A result from an earlier version cannot automatically establish the behaviour of the replacement. The team should be able to explain why a change was accepted, with unresolved issues visible.

Metrics need to reflect the intended service. Count source-supported answers, appropriate uncertainty, unsafe overconfidence and review effort. Include how often people reach the correct next step after an error. A lower average error rate is useful, but it may conceal a recurring failure for one language or an important class of requests.

Operational controls should complement model tests. Limit permissions to the task. Keep sensitive data out when it is unnecessary. Provide a safe fallback during outages. A model evaluation cannot establish that an application prevents duplicate submissions or protects a private attachment. Those are properties of the wider service and need their own evidence.

The potential benefit of the framework is a disciplined way to organise those responsibilities. The failure is treating a completed worksheet as proof of safety. A risk entry should identify what was observed, what is inferred and what remains unknown. If the evidence is weak, the decision should retain that uncertainty rather than convert it into a confident green status.

NIST’s historical materials provide a common starting vocabulary. The organisation supplies the task-specific judgment and the working response. A useful review asks for one difficult case and traces it from user request to evidence, decision and recovery. If the team can explain that chain, the register has begun to support real governance.

A periodic rehearsal can test the people as well as the software. Present a fictional stale-answer incident and ask the designated owner to locate the version, notify the right reviewer and disable the affected answer. Missing steps become concrete improvements before an actual user encounters the same failure.