Executive summary
An effective AI risk register connects a specific system and operating context to plausible risk scenarios, affected people and objectives, accountable owners, current controls, response plans, residual exposure, evidence, monitoring, and decisions.
“Bias” or “privacy” is a topic. A useful entry explains the cause, uncertain event, and consequence in a defined context.
Implemented controls inform current residual risk. Planned actions remain plans until completed, tested, and evidenced.
Each material risk needs one accountable owner with authority to coordinate treatment, escalate barriers, and seek a decision.
Monitoring, incidents, complaints, system changes, deadlines, and new evidence must update the record and sometimes trigger reassessment.
Build it now: the free AI Risk Register Generator supports owners, eight categories, a 5×5 matrix, inherent and residual ratings, treatment, deadlines, evidence, filters, local saving, CSV, JSON, and print-ready reporting.
What is an AI risk register?
An AI risk register is a structured, living record used to identify, analyze, prioritize, respond to, monitor, communicate, and review risks connected to AI systems. It gives decision-makers a consistent view of what might happen, why it might happen, who or what could be affected, how serious it could be, what controls exist, what additional response is planned, who owns the risk, and whether the remaining exposure is acceptable.
The register may cover one system, a business function, a portfolio, or the enterprise. The right level depends on the decisions it must support. A product team may need detailed case-level entries about retrieval permissions, hallucinated output, subgroup performance, human review, and agent tool access. Senior leadership may need a smaller enterprise view that aggregates material exposure, deadlines, trends, systemic dependencies, and decisions without hiding the underlying records.
AI risk is rarely created by the model alone. Entries should cover the complete socio-technical system: purpose, data, model, prompts, retrieval, tools, integrations, vendor, users, affected people, interface, incentives, human review, policies, deployment environment, monitoring, and change process. A model that performs well in a benchmark can still create material risk through excessive permissions, misleading interface design, inaccessible challenge, poor workflow fit, automation bias, vendor change, or weak fallback.
What a register is not
- It is not a one-time spreadsheet completed after the purchase or deployment decision.
- It is not proof that a system is compliant, safe, fair, secure, accurate, or appropriate.
- It is not a replacement for an AI impact assessment, DPIA, legal review, security threat model, safety analysis, vendor review, audit, or domain validation.
- It is not useful if risk owners cannot change the design, allocate resources, escalate exposure, or stop unsafe work.
- It should not contain unnecessary personal, confidential, classified, privileged, or exploitable security information.
The objective is decision quality: a beautiful register with vague entries, false precision, missing owners, or permanently overdue actions creates an appearance of control without reliable risk management.
How the risk register connects to other records
A register is the coordination layer between discovery, specialist analysis, action, monitoring, and decision. It should reference—not copy in full—the evidence maintained by other processes.
| Record or process | Primary purpose | What flows into the register | What flows back |
|---|---|---|---|
| AI inventory | Know which systems exist, where they operate, and who owns them. | System ID, purpose, stage, vendor, business owner, data and integration context. | Material risk level, review priority, status, and restrictions. |
| AI impact assessment | Identify affected people, benefits, harms, controls, and decision gates. | Specific impact scenarios, stakeholders, inherent exposure, missing controls, mitigations, and monitoring needs. | Action status, residual decisions, incidents, and new evidence for reassessment. |
| DPIA or privacy review | Assess personal-data processing and risks to rights and freedoms. | Privacy scenarios, legal or policy dependencies, data controls, decisions, and unresolved exposure. | Implementation status, evidence, changes, incidents, and review triggers. |
| Security threat model | Identify assets, actors, trust boundaries, attack paths, and safeguards. | Threat scenarios, severity, likelihood, owners, controls, testing, and response actions. | Treatment status, accepted exposure, operational indicators, and incidents. |
| Vendor assessment | Determine whether supplier evidence, controls, contract, and operations support requirements. | Third-party dependencies, evidence gaps, contract actions, change risk, continuity, and exit exposure. | Conditions, deadlines, acceptance, monitoring, and escalation. |
| Issue or action tracker | Manage specific tasks, defects, or control implementation work. | Completion status, blockers, test results, cost, and dates. | Priority, risk context, success criteria, and escalation requirement. |
| Incident and complaint records | Respond to realized events and affected-person signals. | Actual harm, near misses, root causes, control failures, frequency, and consequence evidence. | Known scenarios, owners, escalation, corrective action, and reassessment triggers. |
A risk is an uncertain event or condition that may affect objectives or people. An issue is a problem that already exists. An incident is an event that has occurred and requires response. An action is work intended to change exposure. These items should be linked, but converting every risk into a task or every incident into a risk without context makes reporting confusing.
Step 1: Set governance, scope, and decision rights
Before adding rows, decide what the register covers and who uses it. Define whether the register is system-level, product-level, business-unit, or enterprise. Identify the authoritative copy, tool owner, review forum, contributors, approval rights, retention, access controls, and links to inventory, impact, vendor, privacy, security, incident, and action records.
Define entry and escalation rules
Not every minor defect deserves enterprise-level treatment, but material exposure must not disappear into team notes. Establish criteria for creating an entry. Triggers may include consequential decisions, personal or sensitive data, vulnerable people, physical or psychological safety, public-facing output, surveillance or profiling, essential services, autonomous tool use, broad scale, untested technology, vendor dependency, legal uncertainty, material complaints, incidents, or a control that fails.
Define escalation separately from numeric scoring. A threshold such as 15 on a 25-point matrix may flag very high risk, but certain conditions may require review regardless of score: a plausible critical safety outcome; interference with rights; unlawful processing; missing human authority in a consequential workflow; known security exploitability; use involving children or other vulnerable groups; inability to provide challenge or remedy; or a required assessment that has not been completed.
Maintains the register design, definitions, access, quality rules, reporting cycle, and archive.
Owns one exposure, coordinates response, monitors status, escalates barriers, and seeks the residual decision.
Completes a specific control, test, contract, training, or process task by the agreed date.
Accepts, conditions, pauses, redirects, or stops exposure within a defined mandate and tolerance.
Challenges assumptions, ratings, control evidence, conflicts, and closure in higher-impact contexts.
Feeds complaints, appeals, accessibility barriers, outcomes, and lived impact into review and response.
Step 2: Define the register fields
Use enough structure to support comparison and accountability without turning every update into an administrative project. Make controlled fields—category, status, treatment, rating, system, business unit—consistent. Allow narrative where context matters. Link to evidence instead of stuffing complete reports into cells.
| Field group | Recommended fields | Why it matters |
|---|---|---|
| Identity | Stable risk ID, title, system or portfolio ID, version, source, date identified | Enables linking, traceability, change history, and reliable reporting. |
| Scenario | Cause, uncertain event, consequence, context, affected people, assets, objectives | Turns a broad concern into an assessable and actionable statement. |
| Classification | Category, lifecycle stage, business unit, vendor, data or authority flags | Supports filtering, aggregation, systemic analysis, and assignment. |
| Inherent rating | Severity, likelihood, score or band, rationale, uncertainty, assumptions | Shows plausible exposure before relying on controls and prevents action from hiding seriousness. |
| Current controls | Preventive, detective, corrective, human, technical, organizational, and contractual controls | Explains what changes likelihood or consequence now. |
| Control evidence | Design, implementation, operating, test, monitoring, audit, or contract evidence | Separates claimed safeguards from safeguards that exist and work in context. |
| Response | Mitigate, avoid, transfer or share, accept; action plan; cost; dependency; success criteria | Records the treatment choice and how the organization expects exposure to change. |
| Accountability | Risk owner, action assignees, decision authority, target date, escalation path | Makes responsibility and decision rights visible. |
| Residual rating | Severity, likelihood, score or band, rationale, tolerance comparison, acceptance conditions | Records what remains after implemented controls and whether it can proceed. |
| Lifecycle | Status, last review, next review, KRI or threshold, change triggers, closure evidence | Keeps the entry alive as system behavior and context change. |
Add fields only when someone uses them to decide, act, monitor, communicate, or demonstrate an evidence chain. A field that is always blank or copied mechanically probably needs clearer ownership, automation, or removal.
Step 3: Write useful AI risk statements
The risk statement is the center of the register. Weak entries use single words such as “bias,” “hallucination,” “privacy,” “cybersecurity,” or “vendor risk.” Those labels do not reveal which system behavior matters, what creates it, who may be affected, or what control would change it.
A practical example is: “Because the recruitment model was trained and evaluated on data that may not represent qualified applicants, it may rank relevant groups less favorably, causing unequal access, poor hiring decisions, complaints, and legal exposure.” This statement supports questions about data, features, evaluation, groups, consequence, human decision authority, review, appeal, and monitoring.
Improve the statement with context
- Name the AI-enabled workflow, decision, output, integration, or agent action.
- Describe the condition: data limitation, model uncertainty, human factor, vendor dependency, unsafe permission, weak process, or change.
- State what may happen without pretending that uncertainty is certainty.
- Name affected people, groups, assets, services, rights, safety, operations, or strategic objectives.
- Describe plausible consequence, scale, duration, reversibility, concentration, and remedy.
- Record assumptions and uncertainty that materially affect the rating.
“The chatbot may create privacy risk.”
“Because support transcripts include account data, retrieval or generated output may expose information to an unauthorized user, causing privacy, contractual, security, and trust impacts.”
“The model will discriminate against older applicants.”
“Because training and test data may underrepresent qualified older applicants, ranking may produce lower selection rates or error differences, affecting fair access and hiring quality.”
Risk statement workshop prompts
Step 4: Use practical AI risk categories
Categories help teams search, route, aggregate, and report. They should not become silos: one scenario may affect privacy, safety, rights, operations, and reputation at the same time. Choose one primary category for routing and use tags or linked entries for material secondary dimensions.
Autonomy, dignity, access, due process, notice, explanation, challenge, remedy, labor, vulnerable people, and community effects.
Necessity, lawful basis, minimization, provenance, quality, sensitive data, leakage, retention, rights, and surveillance.
Fitness for purpose, error, subgroup outcomes, representation, drift, calibration, robustness, and discriminatory effects.
Physical or psychological harm, misuse, prompt injection, excessive agency, access, supply chain, resilience, and recovery.
Availability, latency, integration, fallback, capacity, human workload, exception handling, monitoring, and continuity.
Applicable law, sector duties, contracts, intellectual property, records, disclosure, accessibility, and required assessment.
Evidence, subprocessors, model change, contract, audit rights, incident support, dependency, portability, and exit.
Cost, fraud, revenue, liability, remediation, customer trust, workforce trust, public confidence, and strategic fit.
Use organizational taxonomy where one already exists. AI risk should connect to enterprise risk management instead of creating an isolated universe with incompatible definitions. Add AI-specific detail inside the established structure where practical.
Step 5: Rate inherent severity and likelihood
Inherent risk describes plausible exposure before relying on controls. It helps leaders see the seriousness of the underlying activity and prevents a long control list from hiding the consequence of failure. Define your organization’s criteria before scoring and use the same definitions consistently.
| Level | Severity guide | Likelihood guide |
|---|---|---|
| 1 | Negligible, localized, short-lived, easily detected and corrected, with no meaningful rights or safety effect. | Rare under expected conditions; exceptional combination required. |
| 2 | Minor burden, delay, rework, service degradation, or limited impact that can be corrected quickly. | Unlikely but credible; has occurred in comparable settings or edge cases. |
| 3 | Material effect on people, quality, privacy, operations, cost, access, or trust; meaningful remediation required. | Possible during normal use; evidence or uncertainty does not make it remote. |
| 4 | Serious or widespread harm, prolonged exclusion, major breach, significant service disruption, or difficult recovery. | Likely in the intended environment without strong controls. |
| 5 | Critical or potentially irreversible effect involving life, safety, fundamental rights, severe exploitation, or organizational survival. | Almost certain or repeatedly observed under expected exposure. |
| Likelihood ↓ / Severity → | 1 Negligible | 2 Minor | 3 Moderate | 4 Serious | 5 Critical |
|---|---|---|---|---|---|
| 5 Almost certain | 5 | 10 | 15 | 20 | 25 |
| 4 Likely | 4 | 8 | 12 | 16 | 20 |
| 3 Possible | 3 | 6 | 9 | 12 | 15 |
| 2 Unlikely | 2 | 4 | 6 | 8 | 10 |
| 1 Rare | 1 | 2 | 3 | 4 | 5 |
In this example, 1–4 is Low, 5–9 Moderate, 10–14 High, 15–19 Very High, and 20–25 Critical. These bands are a planning choice, not a universal standard. Calibrate them to domain consequences, risk appetite, legal and policy duties, existing enterprise scales, and the people who may be affected.
Record the rationale, evidence, assumptions, and uncertainty. “Likelihood 3” without explanation cannot be challenged or updated. Avoid averaging away critical scenarios. A low-frequency catastrophic safety outcome, rights violation, or security failure may need a hard gate even when the arithmetic score is not the highest row.
Step 6: Record controls and evidence separately
A control changes the likelihood, consequence, detection, response, or recovery of a risk. “We use a trusted vendor,” “a human is involved,” or “the model is accurate” is not sufficient control evidence. Describe the control, its owner, scope, implementation, operating condition, limitation, test, and evidence.
Purpose limits, data minimization, prohibited uses, access, least privilege, allowlists, design constraints, and training.
Logging, sampling, subgroup metrics, drift indicators, anomaly detection, complaints, security alerts, and audits.
Override, rollback, correction, notification, appeal, remedy, incident response, fallback, and recovery.
Meaningful review, competence, time, information, authority, escalation, separation of duties, and bias safeguards.
Data use, security, change notice, audit, incident cooperation, performance, liability, continuity, portability, and exit.
Policy, inventory, impact assessment, approval, monitoring, documentation, training, accountability, review, and decommissioning.
| Control state | What it means | How it affects current residual risk |
|---|---|---|
| Verified operating | Implemented in the relevant scope, tested in representative conditions, owned, monitored, and supported by current evidence. | May reduce current residual likelihood or consequence, subject to limitations. |
| Implemented, not verified | The control exists, but operating effectiveness or representative coverage is uncertain. | Use conservative credit and record the validation action. |
| Partial | Implemented for some users, groups, data, environments, failure modes, or integrations. | Credit only the protected scope; do not generalize. |
| Planned | Approved or intended but not yet implemented and evidenced. | Does not reduce current residual risk; it is a treatment action and condition. |
| Missing or failed | Absent, ineffective, bypassed, out of date, or unsupported by evidence. | No risk reduction; may trigger escalation, pause, redesign, or stop. |
Link evidence at the correct level: a test report, monitoring dashboard, audit result, ticket, policy, architecture record, model evaluation, contract clause, approval record, training completion, incident exercise, or accessibility review. Do not put secrets, exploit details, or unnecessary personal information into a widely accessible register.
Step 7: Select and document the risk response
The NIST AI RMF Manage Playbook describes response options that include mitigating, transferring, avoiding, or accepting AI risk. The wording may vary across organizations, but the decision should be explicit.
| Response | Meaning | AI example | Required record |
|---|---|---|---|
| Mitigate | Reduce likelihood, consequence, exposure, detection time, or recovery difficulty through additional controls. | Limit agent permissions, require approval for transactions, validate retrieval access, add subgroup testing, or improve review. | Actions, owner, resources, target, success criteria, evidence, and expected residual change. |
| Avoid | Do not begin or continue the activity that creates unacceptable exposure. | Remove biometric inference, prohibit autonomous rejection, eliminate sensitive retrieval, or stop deployment in a high-impact use. | Decision authority, scope, effective date, alternatives, and verification that the exposure ended. |
| Transfer or share | Allocate part of the financial, operational, or control responsibility through contract, service, insurance, or partnership. | Vendor indemnity, incident support, managed monitoring, warranty, or shared control responsibility. | Contract and responsibility evidence plus the exposure that remains with the organization. |
| Accept | Make an informed, authorized decision to retain residual exposure within defined tolerance and conditions. | Continue a bounded low-impact pilot with monitoring, human review, limited users, expiry, and reassessment triggers. | Authority, rationale, duration, conditions, KRI, review date, and escalation or revocation trigger. |
Transfer does not erase accountability to affected people, customers, workers, regulators, or the organization’s own objectives. Acceptance is not “do nothing.” It is an explicit decision about residual exposure, made by someone with the correct authority, for a defined period and scope, with monitoring and conditions.
Never use the score to force acceptance: if the necessary control cannot be built, verified, or sustained, redesign, narrow, delay, or avoid the use. A risk register should make “do not deploy” visible as a legitimate management response.
Step 8: Assign owners, actions, resources, and dates
Assign one risk owner who can understand the exposure, coordinate across functions, obtain resources, monitor the rating, and escalate a decision. The owner may not personally implement every action. Separate the risk owner from action assignees so accountability does not disappear across a long task list.
Every treatment action should name a deliverable, assignee, target date, dependency, resource assumption, completion condition, and evidence. “Improve security” cannot be managed. “Security Engineering will enforce deterministic authorization outside the model for all payment actions, test bypass scenarios, and attach the approved report before the August launch gate” can be managed.
Use dates that drive decisions
- Set action deadlines before the decision or exposure they are meant to control.
- Flag overdue actions and require the owner to update the rating, plan, or launch condition.
- Give acceptance an expiry or review date; avoid indefinite acceptance by silence.
- Use material-change and incident triggers in addition to calendar review.
- Track estimated response cost and capacity when resource tradeoffs affect treatment.
When a deadline slips, do not simply change the date. Record why, whether exposure has changed, which interim control applies, who approved the change, and what escalation is required. Repeated date movement without a risk decision is a governance warning.
Step 9: Re-rate and decide on residual risk
Residual risk is the exposure remaining after current controls are considered. Reassess severity and likelihood using evidence from representative tests and operating conditions. A control may reduce likelihood without changing maximum consequence; another may improve detection or remedy rather than prevent the event. Explain which dimension changes and why.
Do not reduce residual risk because a control is planned, a policy exists on paper, a vendor promises a feature, or a human is nominally present. Confirm implementation and operating effectiveness. Human review requires enough time, skill, context, information, authority, interface support, and ability to disagree. Otherwise “human in the loop” may produce automation bias instead of control.
Residual exposure is within tolerance; required controls are operating and evidence supports the intended scope.
Use is bounded by users, data, permissions, volume, geography, time, monitoring, approval, or another enforceable condition.
Evidence, validation, ownership, control, consultation, contract, or response capability is not adequate for the decision.
Purpose, authority, data, workflow, vendor, or system design creates exposure that cannot be reduced or justified.
Record who made the residual decision, the authority used, date, scope, rationale, dissent or conditions, expiry, monitoring thresholds, next review, and events that reopen the decision. Higher-impact acceptance may require senior, legal, safety, privacy, security, ethics, worker, public, or independent participation depending on context.
Step 10: Monitor, review, and reassess
AI systems and context change after approval. Models, prompts, knowledge sources, user behavior, affected populations, vendors, laws, integrations, permissions, scale, and business incentives evolve. A current rating can become obsolete even when no formal project change is announced.
| Monitoring signal | Example KRI or evidence | Example trigger | Required response |
|---|---|---|---|
| Quality and reliability | Critical error rate, correction rate, exception rate, fallback use, drift, latency, failure by case type | Critical error exceeds threshold or a segment deteriorates materially | Pause affected path, analyze cases, update control and rating, revalidate. |
| Fairness and access | Outcome and error differences, abandonment, accessibility failures, complaint themes, appeal outcomes | Material disparity, new affected group, or barrier appears | Investigate cause, engage affected people, mitigate, reassess scope and decision. |
| Privacy and security | Leakage tests, unauthorized access, prompt injection, sensitive output, anomalous tool calls, incident indicators | Confirmed disclosure, privilege bypass, or critical control failure | Contain, investigate, notify as required, stop unsafe capability, reassess. |
| Human oversight | Review time, override rate, missed critical errors, reviewer agreement, escalation, automation reliance | Reviewers cannot detect or correct material failures | Redesign workflow, interface, training, authority, sampling, or system boundary. |
| Vendor and change | Model version, release notice, subprocessor, terms, control report, outage, performance change | Material change or missing notice invalidates prior evidence | Run regression gates, review contract, update rating, restrict or roll back. |
| Business and impact | Benefit, rework, cost, harm, complaints, adoption, excluded cases, unintended use, reputational signal | Benefits do not justify exposure or use expands beyond approval | Narrow, redesign, reapprove, or decommission. |
Set a review cadence proportional to exposure and change. A weekly pilot review may become monthly in stable bounded operation; a low-impact internal assistant may be quarterly. Calendar review is not enough. Material purpose, model, data, authority, user, affected-group, vendor, integration, performance, law, incident, complaint, control, or operating-context change should trigger reassessment.
Step 11: Report, aggregate, and learn
Leaders need a portfolio view, but aggregation can hide concentrated harm and incompatible scales. Preserve the detailed risk record while reporting a small number of decision-relevant indicators: total active risks, residual distribution, above-tolerance entries, overdue actions, unowned risks, accepted risks nearing expiry, trend, incidents, control failures, top dependencies, and material changes.
Group entries by system, business unit, category, vendor, lifecycle stage, affected population, control dependency, and decision status. Look for systemic patterns: multiple products relying on the same model provider; repeated lack of subgroup data; missing challenge routes; broad agent permissions; the same monitoring gap; or one team owning too many critical actions.
Questions for the review forum
- Which residual risks are above tolerance or require an independent gate?
- Which actions are overdue, blocked, underfunded, or unsupported by evidence?
- Which ratings changed and what new evidence caused the change?
- Which risks are accepted, by whom, until when, under which conditions?
- Which incidents, complaints, near misses, changes, or monitoring signals reveal new scenarios?
- Where are benefits not appearing, making the remaining exposure harder to justify?
- Which common controls or vendor dependencies create portfolio concentration?
- Which systems need expansion, restriction, redesign, pause, rollback, or decommissioning?
Maintain an audit trail of material changes without turning the register into an immutable archive of every typo. Keep who changed the risk, when, why, the previous and new rating, the evidence, decision, and linked action or incident.
Worked example: an AI support agent with tool access
Consider a customer-support agent that retrieves account knowledge, drafts answers, and can prepare account changes for human approval. The impact assessment identifies privacy, security, quality, oversight, and vendor-change concerns. One register entry focuses on unauthorized action through prompt injection.
| Field | Example record |
|---|---|
| Risk ID and title | AIR-014 — Prompt injection triggers an unauthorized account action |
| Risk statement | Because untrusted customer content can enter the agent context, an attacker may manipulate instructions or tool parameters, causing unauthorized account change, data disclosure, fraud, or service disruption. |
| Affected scope | Customers, account data, transaction integrity, support operations, regulatory duties, and trust. |
| Category and source | Safety and security; system impact assessment and threat model. |
| Inherent rating | Severity 5 × likelihood 4 = 20, Critical. The agent processes untrusted text and can prepare high-impact actions at scale. |
| Current controls | Role-based access, allowlisted tools, parameter validation, approval for account change, logging, rate limits, and incident route. |
| Control evidence | Architecture review confirms authorization outside the model; adversarial suite tests indirect and direct injection; logs show approval and tool parameters. |
| Response | Mitigate. Enforce deterministic authorization, isolate untrusted content, minimize permissions, verify approval binding, red-team bypass, and test kill switch. |
| Owner and date | Security Engineering Director; treatment due before production gate; Product Security and Support Platform own actions. |
| Residual rating | Severity 4 × likelihood 2 = 8, Moderate, because controls reduce successful execution but a serious consequence remains plausible. |
| Decision | Proceed only with bounded tools, enforced external authorization, completed critical tests, monitored anomalies, trained approvers, and immediate rollback. |
| KRI and triggers | Unauthorized tool-call attempts, approval bypass findings, anomalous parameters, sensitive output, critical red-team result, vendor model change, or tool expansion. |
The entry does not replace the threat model or test report. It summarizes the decision-relevant exposure and links those records. If testing discovers a bypass, the issue and incident processes manage the event and work, while the register updates likelihood, control effectiveness, status, decision, and escalation.
Copy-ready AI risk register template
Use this record for one risk. Adapt the fields, scales, approval rights, categories, and evidence expectations to your organization. Keep sensitive detail in controlled linked records.
Complete AI risk record
Common mistakes and governance red flags
| Mistake or red flag | Why it fails | Better approach |
|---|---|---|
| Entries are single-word topics. | Labels such as bias, privacy, or hallucination cannot be rated, owned, or treated consistently. | Write a cause–event–consequence statement in the actual context. |
| The register contains only technical model risk. | Workflow, interface, data, people, vendor, authority, incentives, and remedy may create the material exposure. | Assess the complete socio-technical system. |
| Planned controls reduce the current score. | A future action does not currently prevent, detect, correct, or remedy harm. | Keep it as treatment until implemented, tested, and evidenced. |
| “Human in the loop” is accepted without design evidence. | Reviewers may lack time, context, skill, authority, or ability to resist automation bias. | Test oversight as an operational control. |
| Every risk is jointly owned by a committee. | Shared interest without one accountable owner produces drift and delayed escalation. | Name one owner and separate action assignees and decision authority. |
| Overdue dates are repeatedly moved. | The register hides increasing exposure and weak resource decisions. | Record the delay, interim controls, new rating, approver, and escalation. |
| Risk acceptance has no expiry or authority. | Exposure becomes silently permanent and conditions are forgotten. | Record authority, rationale, conditions, KRI, expiry, and revocation trigger. |
| Average scores override critical gates. | Low-frequency severe rights, safety, legal, or security scenarios can disappear in portfolio arithmetic. | Keep independent stop, specialist, and escalation gates. |
| The register is updated only before audit. | It no longer represents operating reality or supports decisions. | Connect actions, monitoring, incidents, complaints, change, and reviews to the record. |
| Sensitive evidence is copied into every row. | Broad access can create privacy, privilege, confidentiality, or security exposure. | Store minimal summaries and link controlled evidence repositories. |
Frequently asked questions
Methodology and primary sources
This guide combines AI risk management and enterprise risk register practices from current public NIST resources. Laws, standards, and official guidance change; verify current applicability for your organization, sector, system, and jurisdiction.
- NIST AI Risk Management Framework — Govern, Map, Measure, and Manage functions for trustworthy and responsible AI risk management.
- NIST AI RMF Manage Playbook — prioritizing, responding to, documenting, monitoring, and managing AI risks; response options include mitigation, transfer, avoidance, and acceptance.
- NIST AI RMF Govern Playbook — accountability, policies, roles, risk tolerance, documentation, participation, and lifecycle governance.
- NIST AI RMF Map Playbook — context, affected people, impacts, risk identification, human oversight, and assessment scales.
- NIST AI RMF Measure Playbook — metrics, representative evaluation, uncertainty, limits, and monitoring evidence.
- NIST IR 8286A Rev. 1 — identifying and estimating scenarios, likelihood, and impact for risk register and enterprise risk use.
- NIST IR 8286B — adding risk priority and response information to a risk register in support of enterprise risk management.
Important: this article is general educational material. It is not legal advice, a compliance determination, an audit, a safety or security certification, an official risk assessment, or authorization to purchase or deploy an AI system.