Build an AI Risk Register With the NIST AI RMF in 2026

Teams often discuss AI risk as a vague list of worries. Without an owner, a trigger and evidence, the list cannot guide a launch decision or show whether a control is working.

This guide is designed for product owners, operations teams and responsible-AI leads. It turns the topic into a reviewable sequence rather than asking readers to trust a provider label, a detector score or a fluent model answer.

Before you start

Write down the exact task, accountable owner, approved data, affected people and the result that would be unacceptable. Use safe representative examples during the first pass. Where health, legal, employment, financial, safety or regulatory obligations may apply, involve a qualified professional and follow the rules that govern your organization.

1. Map the use case before the model

Describe the decision or action the system supports, the people affected, the data it receives and the systems it can change. A model name alone does not describe operational risk.

Document the decision made during “Map the use case before the model”, the evidence consulted and the person responsible for the next action. That short record helps product owners, operations teams and responsible-AI leads distinguish a repeatable control from an informal habit.

2. Write observable risk statements

Use a cause-event-impact structure. For example: outdated source material may produce an unsupported answer that causes a support agent to give the wrong policy advice.

Test “Write observable risk statements” with a normal case and a deliberately difficult case. Record what passed, what required correction and which condition should trigger a human review for product owners, operations teams and responsible-AI leads.

3. Score likelihood and impact separately

Use a small consistent scale and record the reasoning. Add exposure, reversibility and number of affected users where they materially change the priority.

Assign an owner and completion criterion for “Score likelihood and impact separately”. If the evidence is missing or contradictory, pause the workflow instead of allowing speed or model confidence to become the approval rule.

4. Attach controls and evidence

Link every high-priority risk to a preventive or detective control, an owner and proof such as an eval result, access review, incident ticket or approval log.

Keep the input, output version and reviewer note associated with “Attach controls and evidence” where policy permits. This makes later corrections traceable without retaining unnecessary sensitive data.

5. Set review triggers

Review after model, prompt, data-source, permission or policy changes. A calendar review alone can miss a material change made between meetings.

Review this step after material changes to the model, provider, prompt, data source or connected system. A control that worked in one configuration should not be assumed to cover the next one.

Common failure modes and controls

The following table is a pre-launch challenge list. Teams should adapt it to the systems, people and permissions in their real deployment.

What to measure

Do not optimize a single headline number. Measure useful outcomes together with correction effort, critical failures and the human work needed to make the result acceptable.

• percentage of high risks with an ownerDefine the numerator, denominator, owner and review period for percentage of high risks with an owner; compare like-for-like workflow versions.
• percentage of controls with current evidenceTrack percentage of controls with current evidence beside correction effort and serious exceptions so a faster result does not hide weaker quality.
• overdue review countSample overdue review count by risk level and user group; investigate material changes instead of relying on one aggregate percentage.
• residual risk accepted by a named approverSet a baseline for residual risk accepted by a named approver, record the intervention and review whether the change remained useful after human verification.

Final review checklist

• The business action is described
• Affected people and data are identified
• Risk statements are observable
• Each high risk has an owner
• Control evidence is linked
• Review triggers are scheduled