- Your existing risk management process — identify, assess, mitigate, monitor — still works. What changes for AI projects is the taxonomy of risks you need to identify, the way likelihood works at scale, and the fact that the register doesn’t close when you deploy. EU AI Act Article 9 defines risk management for high-risk AI as a continuous process throughout the lifecycle.
- NIST AI RMF identifies seven risk categories that don’t appear on a standard IT risk register: bias and fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, and environmental impact. If your identification exercise doesn’t systematically work through all seven, you have gaps.
- A 1% error rate isn’t a rare event at scale — it’s a predictable volume of harm. EU AI Act Article 9(2)(b) requires risk assessment to cover reasonably foreseeable misuse, not only intended use. Both frequency at scale and misuse scenarios need to be in your likelihood assessment.
- The risk register needs to stay active after deployment. NIST AI RMF MEASURE 3.1 requires tracking existing, unanticipated, and emergent AI risks based on actual performance in production. Risks that weren’t visible during development routinely surface after go-live — that’s not a planning failure, it’s the nature of AI systems in the real world.
Project managers know risk registers. Identify risks, assess likelihood and impact, plan responses, monitor throughout the project. Those mechanics do not change for AI projects — but the risks do, and so does the time horizon over which you have to manage them.
AI systems introduce risk categories that do not appear on traditional IT projects. They also behave differently over time: AI risks can emerge after deployment, change as the data environment shifts, and manifest in ways that are difficult to predict or measure in advance. A risk register that was adequate for your last software project is not adequate for an AI project without extension.
What Makes AI Risks Different
Traditional software risks are largely about whether the system works as designed. AI risks include that question — and add several that have no equivalent in conventional software. The behavior of an AI system is not fully determined by code you can inspect: it is shaped by training data you may not fully control, by distributional assumptions that may not hold over time, and by interactions with a real-world environment that is more complex than the test environment.
| Traditional Software Risks | AI-Specific Additions |
|---|---|
| Does the system function correctly? | Does it function fairly, and for all affected groups? |
| Is it secure from external attacks? | Is it also robust to adversarial inputs, data poisoning, and model extraction? |
| Does it meet the specified requirements? | Do the requirements account for all affected parties, including those not represented in the design process? |
| Is data protected from unauthorized access? | Is training data appropriate, representative, and free of encodings of historical discrimination? |
| Behavior is static after deployment | Performance can degrade or drift as the world changes, even without code changes. |
| Failures are typically deterministic and reproducible | Failures can be probabilistic, context-dependent, and disproportionate across subgroups. |
The Seven AI Risk Categories
NIST AI RMF 1.0 maps out seven trustworthiness characteristics that translate directly into risk categories for your register. Work through all seven — systematically, at project initiation. Empty categories don’t mean clean categories; they mean that area wasn’t examined.
1. Bias and Fairness
The system may produce different outcomes for different groups in ways that are unfair, discriminatory, or disproportionate. NIST identifies three kinds of AI bias: systemic bias (embedded in datasets or organizational culture), computational bias (from non-representative training data or flawed algorithms), and human-cognitive bias (from how people interpret and act on AI outputs). None of these require anyone to have bad intentions.
Example risks: model performs worse for groups underrepresented in training data; proxy variables introduce discrimination even without protected attribute inputs; historical bias in training data is encoded and amplified; human reviewers selectively override the system in ways that reintroduce bias the model had partially corrected.
The NIST framing is important: systems in which harmful biases are mitigated are not necessarily fair. Balanced accuracy across demographic groups does not resolve accessibility barriers, digital divide effects, or systemic disadvantages that pre-exist the AI system.
2. Safety and Reliability
The system may produce outputs that cause harm, or fail to perform when needed. EU AI Act Article 15 requires that high-risk AI systems achieve an appropriate level of accuracy and reliability and perform consistently throughout their lifecycle — including under errors, faults, or inconsistencies arising from interaction with people or other systems.
Example risks: system fails silently without alerting operators; edge cases produce dangerous or inappropriate recommendations; system performs well on held-out test data but poorly in production where the input distribution differs; feedback loops cause biased outputs to influence future training data. NIST MEASURE 2.6 requires that the AI system be demonstrated safe and that residual negative risk does not exceed the risk tolerance before deployment.
3. Privacy
The system may expose, infer, or misuse personal information. AI systems can present privacy risks that go beyond conventional data protection: they can infer information that was never explicitly provided, and training data can become embedded in model weights in ways that are difficult or impossible to remove after training.
Example risks: training dataset contains personally identifiable information that a subject did not consent to include in AI training; model outputs enable inference of sensitive attributes from inputs that do not contain those attributes directly; membership inference attacks allow adversaries to determine whether a specific individual’s data was in the training set. NIST MEASURE 2.10 requires that privacy risk be examined and documented.
4. Security and Robustness
The system may be vulnerable to manipulation or adversarial attack. AI systems have attack surfaces that traditional software does not: the training data, the model weights, and the inference process are all potential vectors.
Example risks: adversarial inputs cause the system to misclassify in ways an attacker can exploit; data poisoning corrupts training data to introduce systematic errors or backdoors; model extraction allows a competitor or adversary to replicate a proprietary model through repeated queries; model inversion allows an attacker to reconstruct sensitive training data from model outputs. EU AI Act Article 15(5) requires that high-risk AI systems be resilient against attempts by unauthorized third parties to alter their use, outputs, or performance. NIST MEASURE 2.7 requires that security and resilience be evaluated and documented.
5. Transparency and Explainability
The system may make decisions that cannot be understood, explained, or audited. The risk is not that the model is opaque internally; it is that opacity prevents the downstream consequences that depend on explainability: meaningful human oversight, right-to-explanation obligations, operator understanding of unexpected behavior, and audit.
Example risks: the system cannot produce an explanation of individual decisions that would satisfy a right-to-explanation request; operators cannot understand why the system is behaving unexpectedly and therefore cannot determine whether to override it; post-incident investigation is blocked by inability to trace a decision back to an interpretable cause. NIST MEASURE 2.8 and 2.9 require that risks associated with transparency and accountability be examined, documented, and validated.
6. Accountability
It may be unclear who is responsible for the system’s decisions and their consequences. In complex AI deployments — especially those involving third-party models, multi-step pipelines, or agentic systems — accountability can be distributed across providers, deployers, and operators in ways that leave no single party clearly responsible for any given outcome.
Example risks: when the system produces a harmful output, no party in the supply chain accepts responsibility; a third-party model provider’s risk profile is unknown to the deploying organization; the system is redeployed in a context its provider did not intend, and neither party has addressed the resulting risks; incident response is delayed because it is unclear which party has authority to intervene.
7. Environmental and Societal Impact
The system may produce harms at a scale or in dimensions that conventional project risk assessment does not address. NIST AI RMF 1.0 frames potential AI harms across three categories: harm to people (including individual civil liberties, group discrimination, and societal effects), harm to organizations (including operations, finances, and reputation), and harm to ecosystems (including interconnected systems, natural resources, and the environment). NIST MEASURE 2.12 requires that environmental impact and sustainability be assessed and documented.
Example risks: the system encodes and amplifies existing societal disparities at scale; the system produces homogenized outputs across a population in ways that reduce diversity of outcomes; energy consumption during training or inference is disproportionate relative to the system’s value.
Assessing AI Risks: Likelihood, Scale, and Impact
Likelihood Is Not Just Event Probability
The standard risk formula applies: Risk = Likelihood × Impact. For AI systems, the likelihood component requires additional dimensions that do not arise in conventional project risk.
Frequency at scale. A model with 1% error rate produces errors continuously during operation. At 100,000 inferences per day, that is 1,000 errors per day — not a rare event but a predictable daily volume of harm. Likelihood assessment must account for how often an error category will occur in production volume, not only whether it can occur.
Distributional specificity. Risks may be near-certain for specific subgroups, inputs, or contexts even where they are rare in aggregate. NIST MEASURE 2.11 requires that fairness and bias evaluations be documented with disaggregated results precisely because aggregate metrics conceal subgroup-level risks.
Misuse conditions. EU AI Act Article 9(2)(b) requires that risk assessment cover risks arising under conditions of reasonably foreseeable misuse, not only intended use. What happens when a deployer uses the system beyond its intended scope? When an adversary probes for weaknesses? These conditions must be assessed, not excluded.
Detectability. Some AI failures are not immediately observable. A model may be producing systematically biased outputs for weeks or months before the pattern is large enough to detect. “Will we know when this is happening?” is a risk assessment question that must be answered in the register for every identified AI risk.
Impact Across Three Harm Dimensions
NIST AI RMF 1.0 frames AI harm across three categories. Your impact assessment should use this structure to avoid the common failure of scoring only organizational impact while leaving person-level and ecosystem-level harms unweighted.
| Harm Dimension | Questions to Ask During Impact Assessment |
|---|---|
| Harm to people — individual | Who could be harmed by an incorrect output? How severely? Is the harm reversible? Does the harm affect a right (employment, credit, healthcare, liberty, fundamental rights under EU law)? |
| Harm to people — group and community | Could certain demographic groups be disproportionately affected? Is this a consequence of the model’s training data or its deployment context? Does disproportionate impact constitute discrimination under applicable law? |
| Harm to people — societal | At scale, does the system erode democratic participation, reduce educational access, or concentrate economic opportunity in ways that affect people who never interact with it? |
| Harm to the organization | What are the regulatory consequences of a failure? What is the litigation exposure? What reputational damage could result? What operational disruption would follow an emergency shutdown? |
| Harm to ecosystems | Does the system interact with other AI systems in ways that could produce cascading failures? Does it affect natural resources or produce environmental costs disproportionate to its benefit? |
Severity Classification: Some Risks Are Not Acceptable at Any Probability
EU AI Act Article 9(5) requires that the residual risk associated with each identified hazard, and the overall residual risk of the high-risk AI system, be judged acceptable. Your risk register should reflect this with a severity classification that distinguishes between risks that can be mitigated to an acceptable residual level and risks that require fundamental redesign or a no-go decision.
| Classification | Definition and Response |
|---|---|
| Prohibitive | Residual risk cannot be reduced to acceptable levels through available mitigation measures. Requires fundamental system redesign, scope change, or a no-go deployment decision. EU AI Act Article 9(5) implies this category exists: some residual risks are not acceptable regardless of probability. |
| Major | Significant risk requiring substantial mitigation before deployment is authorized. Must appear in the risk register with specific, resourced mitigation actions and residual risk assessment. |
| Moderate | Risk requiring monitoring and contingency plans. Acceptable to deploy with monitoring in place and a defined response plan. Must appear in the post-deployment risk tracking process. |
| Minor | Risk acknowledged and accepted with minimal mitigation. Should still be logged so that changes in deployment scale or context can trigger reassessment. |
Risk Register Structure for AI Projects
Extend your standard risk register with AI-specific fields. The fields that matter most for AI — and that typically do not appear in conventional IT risk registers — are detection method, review trigger, and post-deployment monitoring. These fields exist because AI risks change: they evolve with the data environment, with deployment scale, and with real-world operational experience.
| Field | Purpose and AI-Specific Guidance |
|---|---|
| Risk ID | Standard identifier. Use a consistent taxonomy prefix that reflects AI risk category (e.g. BIAS-001, SEC-004) to enable category-level reporting and filtering. |
| Category | AI risk category from the seven domains above. A risk can span categories — log it under the primary category and cross-reference. |
| Description | What could happen, stated in terms of the outcome rather than the mechanism. “Model produces discriminatory credit decisions for applicants with non-standard income sources” is more useful than “model bias risk.” |
| Affected parties | Who would experience harm if this risk materialises. Use NIST’s three-tier framework: individuals, groups/communities, organizations, ecosystems. |
| Likelihood | Probability of occurrence — but also: frequency at production scale, distributional specificity by subgroup, and whether misuse conditions are included. EU AI Act Article 9(2)(b) requires reasonably foreseeable misuse to be assessed. |
| Impact | Severity if it occurs, scored across harm dimensions. Do not score only organizational impact. A risk that carries low organizational impact but high individual or group harm should carry a high overall impact score. |
| Risk score | Likelihood × Impact. Document the scoring methodology so that scores are comparable across entries and reviewers. |
| Detection method | How would the organization know this risk has materialised? If there is no detection method, that is itself a major risk — the system could be failing without anyone knowing. |
| Response strategy | Avoid, mitigate, transfer, or accept. For AI risks, “accept” should be rare for high-severity categories. EU AI Act Article 9(5) sets a standard of acceptable residual risk — but acceptance must be conscious and documented. |
| Mitigation actions | Specific, resourced steps to reduce the risk. Who does what, by when? Mitigations should be concrete enough to be tracked to completion and verified as effective. |
| Residual risk | Risk remaining after mitigation. EU AI Act Article 9(5) requires that residual risk be judged acceptable. NIST MANAGE 1.4 requires that residual risks be documented and disclosed to downstream actors. |
| Owner | Named individual responsible for this risk entry. Not a role or a team — a person. Vacant ownership is the most common cause of unmonitored AI risk. |
| Monitoring approach | How will this risk be tracked in production? What metrics, thresholds, and review processes? NIST MEASURE 3.1 requires approaches and personnel to regularly identify and track existing, unanticipated, and emergent risks based on actual deployed-context performance. |
| Review trigger | What events should prompt reassessment of this risk entry? Candidates: model retraining, change in input data sources, significant change in deployment scale, incident involving this risk category, new regulatory guidance, post-market monitoring findings. |
The Register Doesn’t Close at Deployment
A traditional project risk register closes when the project does. An AI risk register doesn’t. It stays active and is updated throughout the entire time the system is running. For high-risk AI systems, this is a legal requirement. EU AI Act Article 9 defines risk management as a continuous iterative process throughout the system’s lifecycle. Article 72 requires providers to actively collect, document, and analyze performance data throughout the system’s lifetime.
NIST AI RMF MEASURE 3.1 requires tracking existing, new, and emerging risks based on actual production performance — not what you projected during testing. Production behavior is what matters.
- Define the review cadence before go-live. Who reviews the risk register, how often, and against what data? Monthly performance reports, quarterly full reviews, and event-triggered reassessment are a reasonable baseline. This must be specified in the operational handoff documentation and resourced accordingly.
- Connect risk monitoring to system monitoring. Performance monitoring metrics — accuracy drift, subgroup performance trends, input distribution shifts, override rates — should be linked to specific risk register entries. When a monitoring metric crosses a threshold, it should trigger a defined risk register review.
- Assign post-deployment risk ownership at project close. Risk entries with vacant post-deployment owners are not monitored in practice. Transfer of risk ownership must be an explicit deliverable of the deployment phase, not an assumption.
- Log incidents against risk register entries. When an AI system incident occurs, trace it back to the risk register. Did the register contain this risk category? Was the detection method adequate? Was the mitigation effective? A risk register that does not incorporate operational experience is progressively disconnected from the system it is supposed to govern.
- Define the events that trigger reassessment. Model retraining, changes in input data sources, deployment scale changes, new regulatory guidance, supply chain changes, significant organizational changes — each should be a defined review trigger. EU AI Act Article 9(2)(c) explicitly requires that risks be evaluated based on data gathered from the post-market monitoring system.
A risk register that only shows current assessments loses its governance value over time. Include fields for initial assessment date, most recent assessment date, a summary of what changed and why, and the events that triggered reassessment. This creates an audit trail that demonstrates that risk management is a continuous practice — which is what regulators reviewing EU AI Act compliance will want to see.
Right-Sizing for Your Situation
The depth of your AI risk register should match the risk classification of the system and your organization’s governance maturity. A proof-of-concept system used internally by a small team needs a lighter-weight register than a system making consequential decisions about individuals at scale. But all AI risk registers share the same structural requirements: coverage of all seven risk categories, assessment that includes harm to people and not only harm to the organization, a detection method for every significant risk, and a post-deployment monitoring plan.
Work through all seven risk categories even if you conclude most are low-severity for your system — the discipline of examining each one is the point. For lower-risk systems, you don’t need all 14 fields fully populated for every entry, but three fields are non-negotiable regardless of risk level: description (outcome-focused, not just a category name), detection method (how will you know if this materializes?), and owner (a named person, not a team). A register where those three fields are empty for any entry isn’t a risk register — it’s a list.
The highest-value standardization at this stage is the likelihood scoring methodology — specifically, building scale effects and misuse scenarios into the scoring criteria so that every risk is assessed consistently across projects. Write it down before projects start, not during risk identification when each team will improvise their own interpretation. The second priority is the review trigger list: define organization-wide triggers (model retraining, new regulatory guidance, supply chain changes) that apply to every AI risk register, then let projects add system-specific triggers on top.
At this level the risk register is an input to enterprise risk reporting and regulatory evidence. EU AI Act Article 9 compliance requires demonstrating that risk management is a continuous iterative process — which means the register needs a version history, a formal review cadence with documented outcomes, and a traceable link between post-market monitoring findings and register updates. If your enterprise risk framework doesn’t currently accommodate the person-level and ecosystem-level harm dimensions in NIST’s AI harm taxonomy, that’s the gap to close before a regulatory audit surfaces it.
The AI Governance Advisor can help you work through AI risk identification for your specific system type, deployment context, and regulatory environment — and generate a risk register pre-populated with relevant risk entries across all seven categories.
AIPMO’s AI Risk Register template is a structured, fillable PDF built around the 14-field register format and seven risk categories described in this article. It includes pre-populated example entries across bias, safety, privacy, security, transparency, accountability, and environmental domains — with likelihood scoring guidance that accounts for scale effects and misuse conditions. Download free and adapt to your project, or use the AI Governance Advisor to generate a version pre-populated for your system type, methodology, and deployment context.
Framework References
EU AI Act (Regulation (EU) 2024/1689) — Article 9 (risk management as a continuous iterative process throughout the AI lifecycle; regular review and updating required), Article 9(2)(b) (reasonably foreseeable misuse must be assessed), Article 9(5) (acceptable residual risk standard), Article 15(5) (resilience against adversarial manipulation for high-risk AI), Article 72 (post-market monitoring and performance data collection).
NIST AI Risk Management Framework 1.0 (NIST AI 100-1, 2023) — MAP 1.1 (structured harm identification across people, organizations, and ecosystems), MEASURE 2.6 (safety demonstration before deployment), MEASURE 2.7 (security and resilience evaluation), MEASURE 2.8 and 2.9 (transparency and explainability documentation), MEASURE 2.10 (privacy risk examination), MEASURE 2.11 (bias and fairness evaluation with disaggregated results), MEASURE 2.12 (environmental impact assessment), MEASURE 3.1 (tracking emergent risks in deployed systems), MANAGE 1.4 (residual risk documentation and disclosure), MANAGE 2.2 (treatment and response plans for identified AI risks).
NIST AI RMF Playbook (NIST, 2023, online) — MAP and MEASURE suggested actions for identifying and documenting AI-specific risk categories across all seven trustworthiness domains.
PMI CPMAI Guide (2025) — Risk register as a living document across all six phases; post-deployment risk as a standing operational requirement rather than a project closeout deliverable.
This article is part of AIPMO’s PM Practice series. See also: The AI Project Charter | AI Impact Assessments | The PM’s Guide to NIST AI RMF | AI Risk Classification