For small organizations
Build an AI risk register before you deploy the tool
A lightweight worksheet and weekly practice based on NIST's Govern, Map, Measure, and Manage functions.
A risk register is a working list of what can go wrong, who owns the response, how the team will detect the problem, and what happens next. It is useful only when tied to an actual system and reviewed often enough to change decisions.
01
What we know now
- 01
The NIST AI Risk Management Framework is voluntary and intended for varied organizational contexts.
- 02
NIST treats risk across the AI lifecycle rather than only at model selection.
- 03
The Generative AI Profile adds actions for risks specific to generative systems and should be adapted to the organization's priorities.
02
Why this matters for Armenia
A small Armenian organization may not have a dedicated AI governance team. A concise, owned register can make routine use visible without creating a process too heavy to maintain.
03
own
scope, policy, owner, stop authorityunderstand
use, people, data, dependenciestest
failures, uncertainty, control evidenceact
reduce, monitor, pause, correct, retireThe functions reinforce one another; the register is a record of the loop, not a one-time form.
04
Define one system and one accountable owner
Do not begin with “our AI risk.” Name the exact use: for example, drafting routine support replies from an approved knowledge base. Record the users, affected people, data, model and provider, version, endpoint, deployment path, tools, outputs, and release point. A change in any of those may create a new risk profile.
Assign an owner who can pause the workflow and obtain a correction. Ownership is not blame. It is the authority and duty to keep the entry current, collect evidence, and escalate when the stop rule is met.
- System and version
- Intended use and explicit exclusions
- Users and affected people
- Data and external dependencies
- Owner and stop authority
05
Give every risk an observable form
Write a risk as a cause, event, and consequence. “The model may be wrong” is too broad. “A stale source leads the drafting system to state an expired deadline, causing a reader to miss the current application window” can be tested and controlled.
For each entry, record existing controls, a likelihood band, an impact band, detection evidence, response, owner, review date, and status. Use simple scales with written definitions. The objective is consistent decisions, not decorative precision.
- Cause, event, and consequence
- Affected people or process
- Existing prevention and detection controls
- Likelihood and impact with definitions
- Response, owner, status, and next review
06
Ask ten questions before launch
The questions below turn Govern, Map, Measure, and Manage into a small-team review. A weak or unknown answer is not automatically a ban. It is evidence that the team needs a control, a narrower scope, a test, or a stop.
Generative systems deserve special attention to unsupported content, privacy, harmful or degrading output, unclear provenance, information security, and over-reliance. The NIST Generative AI Profile provides a wider catalog; choose what matches the actual use.
- What exact use is allowed, and what is excluded?
- Who could be affected by a wrong, missing, or delayed output?
- Which data enters the system, and where does it travel?
- Which source or test can reveal an unsupported claim?
- Can a user tell when AI materially shaped the result?
- What happens when the model, prompt, source, or dependency changes?
- What is the worst plausible repeated failure?
- Can the action be reversed, corrected, and traced?
- Who is notified of an incident, and who may stop operation?
- What evidence will retire, reduce, or reopen this risk?
07
Review weekly and use a simple stop rule
For a new routine system, review the register weekly. Examine failed samples, user corrections, source freshness, model or prompt changes, incidents, and any control that did not operate. Close an entry only when evidence supports the change, and preserve the history.
For this register, a critical failure means a high-impact failure that lacks an effective control. A practical stop rule is: pause the affected output whenever such a failure is credibly reported and unresolved, the system exceeds its approved scope, required evidence is missing, or a control cannot be shown to have run. Restart only on a new version with the failed condition addressed and checked.
- New evidence updates likelihood or impact.
- A system change reopens related entries.
- A high-impact failure without an effective control pauses the affected workflow.
- Restart requires a versioned fix and fresh verification.
08
Download and use the template
The CSV opens in common spreadsheet tools and contains no macros or external connections.
- 01
Create one row for each distinct cause-event-consequence chain.
- 02
Use defined low, medium, and high bands plus the critical stop threshold above rather than invented percentages.
- 03
Link each control to evidence that it actually ran.
- 04
Assign an owner and next review date before launch.
- 05
Preserve closed entries so repeated failures remain visible.
09
Limits of this edition
A generic register does not replace task-specific evaluation or the obligations that apply to an organization.
Risk bands are prioritization aids, not measured probabilities unless supported by data.
NIST is revising AI RMF 1.0, so the source set should be checked before major process changes.
SRC
Source desk
Direct links to the material behind this selection. Seeing the source matters as much as reading the synthesis.