Understanding AI Risk Taxonomy & Assessment

AI risk management begins with a clear vocabulary. Without precise language to describe the different categories of risk that AI systems introduce, organizations default to treating AI risk as a monolithic, undifferentiated threat: which makes it impossible to design proportionate controls, assign clear ownership, or compare risk levels across a portfolio of AI initiatives. A well-constructed AI risk taxonomy gives practitioners a shared language and a structured framework for identifying, classifying, measuring, and managing the distinct risk types that characterize AI systems.

The need for a dedicated AI risk taxonomy arises from the ways AI systems differ from traditional software. Conventional software fails in predictable ways: a bug in code produces a deterministic error that can be traced, reproduced, and fixed. AI systems, particularly machine learning models, fail in statistically distributed, context-dependent, and often opaque ways. A fraud detection model may perform with 99% accuracy overall but systematically misclassify transactions from a particular demographic segment. A language model may produce factually accurate outputs 95% of the time and confidently fabricate information the remaining 5%, with no reliable external signal distinguishing which is which. A computer vision system trained on high-quality images may degrade significantly when deployed in real-world lighting conditions that differ from its training environment. These failure modes are qualitatively different from traditional software defects and require a distinct analytical framework.

The AI risk taxonomy presented in this chapter organizes AI-specific risks into five primary categories: performance risk, data risk, model risk, deployment and operational risk, and ethical and societal risk. Each category contains distinct sub-types with characteristic causes, potential harms, measurement approaches, and mitigation strategies. Understanding this taxonomy in depth, not just as a list of labels, but as a structured understanding of how each risk type works and what makes it materially different from adjacent risk types, is foundational to effective AI risk management at the CAP Specialist level.

This chapter covers the full AI risk taxonomy, risk assessment methodology, risk scoring frameworks, and the practical workflow for conducting an AI risk assessment for a specific AI system or use case. By the end, you will be able to conduct a structured AI risk assessment, produce a risk register, and recommend proportionate mitigations for the risk profile identified.

Core Concepts

Five foundational concepts structure the entire field of AI risk assessment. Each concept is not merely a definition but a lens that shapes how practitioners identify and analyze risk.

The first core concept is risk as a function of probability and impact. Risk is not simply the existence of a potential negative outcome. It is the product of the likelihood that the negative outcome will occur and the severity of harm if it does. A risk that is highly probable but causes minor harm may warrant less investment in mitigation than a risk that is improbable but catastrophic. AI risk assessment applies this framework rigorously: for each identified risk, practitioners estimate both dimensions and prioritize mitigation resources accordingly. This prevents the common failure mode of treating all identified risks as equally important, which produces either over-investment in low-stakes risks or under-investment in high-stakes ones.

The second core concept is the distinction between inherent risk and residual risk. Inherent risk is the risk level that exists before any controls are in place, the raw risk of an AI use case given its nature. Residual risk is the risk level that remains after controls are implemented. The difference between inherent and residual risk represents the risk reduction achieved by the control portfolio. This distinction matters because it clarifies what risk management is actually accomplishing. An AI system with high inherent risk but strong controls may have lower residual risk than a system with moderate inherent risk but weak controls. The goal of risk management is to reduce residual risk to an acceptable level, not to eliminate inherent risk (which is often impossible) or to select only inherently low-risk use cases (which would foreclose many of the most valuable AI applications).

The third core concept is risk appetite and risk tolerance. Risk appetite is the board- or executive-level statement of how much overall risk the organization is willing to accept in pursuit of its strategic objectives. Risk tolerance is the operational-level expression of acceptable risk levels for specific risk categories, expressed in measurable terms. For AI, risk tolerance statements might specify: maximum acceptable false positive rates for a fraud detection model, maximum acceptable demographic performance disparities for an employment screening model, or maximum acceptable data breach probability for a customer-facing AI system. Effective AI risk assessment requires knowing the organization's risk tolerance thresholds so that the risk assessment produces a clear judgment about whether each identified risk is within tolerance or requires mitigation to reduce it to an acceptable level.

The fourth core concept is the cascading nature of AI risk. AI systems rarely fail in isolation. A data quality failure upstream in the data pipeline causes model performance failures downstream. A model performance failure in a high-stakes decision context causes harm to affected individuals. The harm to affected individuals triggers regulatory scrutiny, litigation, and reputational damage. This cascading pattern, in which a technical failure at one layer of the AI system produces organizational consequences several layers removed, means that AI risk cannot be assessed only at the model layer. Effective AI risk assessment traces risk from its root causes (often in data or model development) through its potential manifestations (deployment failures) to its ultimate consequences (business and reputational impact).

The fifth core concept is the dynamic nature of AI risk. Unlike static software systems, AI systems operate in dynamic environments: input data distributions shift as real-world behavior changes, model performance degrades as the world diverges from the training distribution, regulatory requirements evolve as policymakers respond to emerging AI risks, and adversarial actors learn to exploit AI system vulnerabilities. This means that AI risk assessment is not a one-time exercise but a continuous process. A risk assessment conducted at deployment time will be partially obsolete six months later as the operational environment changes. CAP Specialists must design risk assessment processes that are revisited on a regular schedule and triggered by significant changes in the model, its data, its deployment context, or the regulatory landscape.

Practical Frameworks

The Five-Category AI Risk Taxonomy

The five-category AI risk taxonomy provides a comprehensive map of AI-specific risk types. Each category contains distinct sub-types that practitioners must be able to identify and distinguish in practice.

Category 1: Performance Risk encompasses the risks that an AI model will not perform adequately for its intended purpose. The sub-types include accuracy risk (the model produces incorrect outputs at an unacceptable rate), calibration risk (the model's confidence scores do not accurately reflect actual probability of correctness, leading to over- or under-reliance), distributional shift risk (the model performs well on training and test data but degrades on production data as real-world patterns diverge from the training distribution), adversarial robustness risk (the model's outputs can be manipulated by adversarially crafted inputs), and edge case risk (the model fails on rare but important inputs that are underrepresented in training data). Performance risk is the category most familiar to data scientists but is often assessed too narrowly, evaluating only overall accuracy rather than performance across deployment-relevant subgroups and conditions.

Category 2: Data Risk encompasses the risks arising from the data used to train, validate, and operate AI systems. Sub-types include training data quality risk (the training data contains errors, missing values, or artifacts that produce a model that learns incorrect patterns), training data representativeness risk (the training data does not adequately represent the population to which the model will be applied, producing a model that performs well for some groups but poorly for others), data lineage risk (the provenance of training data is unclear or undocumented, making it impossible to verify that data use is legally authorized and ethically appropriate), data poisoning risk (adversarial actors have injected malicious data into training data to cause the model to learn incorrect or harmful patterns), and data privacy risk (the training or operational data contains sensitive personal information that creates regulatory exposure or could be extracted from the model by adversarial probing).

Category 3: Model Risk encompasses the risks arising from the model itself: its architecture, its training process, and its operational characteristics. Sub-types include overfitting risk (the model has learned patterns specific to training data rather than generalizable patterns, producing a model that performs well in testing but degrades in production), underfitting risk (the model is too simple to capture relevant patterns, producing persistently poor performance), opacity risk (the model's decision process cannot be explained in terms that allow human review, oversight, or debugging), extrapolation risk (the model makes confident predictions for inputs that fall outside the range of its training data, without signaling that it is operating outside its reliable range), and model staleness risk (the model was trained on historical data and has not been updated to reflect current conditions, making its outputs increasingly unreliable as the world changes).

Category 4: Deployment and Operational Risk encompasses the risks that arise when an AI system is integrated into real-world operational processes. Sub-types include integration risk (the AI system does not integrate reliably with the systems and processes that consume its outputs), infrastructure risk (the infrastructure supporting the AI system, compute, storage, APIs, is subject to failures that affect AI availability or performance), misuse risk (the AI system is used for purposes or in contexts for which it was not designed, producing unreliable outputs in the unanticipated deployment context), automation bias risk (human overseers systematically defer to AI outputs rather than exercising independent judgment, removing the safeguard function that human oversight is intended to provide), and vendor dependency risk (the AI system relies on third-party models, APIs, or infrastructure that the organization does not control and that may change, degrade, or become unavailable).

Category 5: Ethical and Societal Risk encompasses the risks that AI systems produce outcomes that cause harm to individuals, communities, or society, harms that may not constitute regulatory violations but are inconsistent with the organization's ethical commitments. Sub-types include fairness and bias risk (the AI system produces systematically different outcomes for different demographic groups in ways that are unjustified and harmful), privacy risk (the AI system collects, uses, or exposes personal information in ways that individuals would not reasonably expect or consent to), autonomy risk (the AI system influences individual decisions or behaviors in ways that undermine individual agency or informed decision-making), accountability risk (the AI system's decision process cannot be effectively audited or contested by affected individuals), and societal impact risk (the AI system, if widely deployed, produces systemic effects on labor markets, social structures, or public discourse that are harmful at scale).

The NIST AI Risk Management Framework

The NIST AI Risk Management Framework (AI RMF), published in January 2023, provides a voluntary, flexible, non-sector-specific framework for managing AI risks. For CAP Specialists, the AI RMF provides both a conceptual vocabulary and a practical process structure for AI risk management that is gaining broad adoption as an industry standard.

The AI RMF is organized around four core functions: Govern, Map, Measure, and Manage. These four functions are not sequential stages but ongoing, interrelated activities that together constitute a continuous AI risk management process.

Govern establishes the organizational structures, policies, processes, roles, and culture that enable effective AI risk management. Govern activities include: establishing AI risk governance policies (who is accountable for AI risk, what decisions require escalation, what documentation is required); defining organizational AI risk tolerance; creating organizational roles with AI risk responsibilities (AI risk owner, model risk manager, AI ethics committee); and building organizational AI risk management capability through training and tooling. Without the Govern function, the other three functions cannot operate consistently or at scale: risk mapping, measurement, and management become ad hoc activities dependent on individual champions rather than systematic organizational capabilities.

Map establishes a comprehensive inventory of AI systems and the context-specific risks associated with each. Mapping activities include: identifying and cataloging all AI systems in use or under development; characterizing each AI system by use case, affected populations, data used, and deployment context; identifying the specific risks relevant to each AI system by applying the AI risk taxonomy; and establishing the risk ownership assignments that determine who is responsible for managing each identified risk. The Map function transforms the organization's AI portfolio from an opaque collection of individual projects into a structured risk landscape that can be governed and managed.

Measure develops and applies methods for quantifying AI risk levels and evaluating the effectiveness of risk controls. Measurement activities include: designing bias tests and performance evaluations appropriate to each AI system's risk profile; monitoring production AI systems for performance degradation, fairness metric drift, and anomalous behavior; conducting security assessments of AI systems for adversarial vulnerabilities; and tracking the residual risk level of each AI system over time. The Measure function provides the empirical foundation that distinguishes risk management from risk theater, the difference between claiming controls are in place and demonstrating that those controls are actually producing the intended risk reduction.

Manage implements risk response strategies for identified and measured AI risks. Management activities include: selecting and implementing risk controls (risk avoidance, risk mitigation, risk transfer, risk acceptance); maintaining risk registers that track identified risks, their current measured levels, assigned owners, and control status; responding to AI incidents when controls fail; and continuously improving the risk management program based on experience. The Manage function is where risk management produces actual risk reduction, the previous three functions are preparation for the action that happens in Manage.

The AI Risk Assessment Matrix

The AI Risk Assessment Matrix is the practical tool that translates the AI risk taxonomy and the NIST AI RMF into actionable risk scores for specific AI systems. The matrix structures the risk assessment process and ensures that all relevant risk dimensions are addressed systematically rather than selectively.

The matrix has two axes: likelihood (the probability that the risk event will materialize) and impact (the severity of harm if the risk event occurs). Each axis uses a five-point scale: likelihood ranges from Rare (less than 10% probability in the next 12 months) through Unlikely, Possible, Likely, to Almost Certain (greater than 80% probability). Impact ranges from Negligible (minimal harm, easily remediated) through Minor, Moderate, Significant, to Severe (catastrophic harm, irreversible consequences).

For each identified risk, the assessor assigns a likelihood score and an impact score. The product (or a weighted combination) produces a risk score that places each risk into one of four quadrants: Low risk (accept with monitoring), Medium risk (implement standard controls), High risk (implement enhanced controls and escalate to risk ownership), and Critical risk (implement immediate remediation or consider whether the use case should proceed). This prioritization ensures that mitigation resources are directed to the highest-risk items rather than distributed evenly across all identified risks.

The matrix must be applied separately for each deployment context. The same AI model may have a Low risk score when used internally by expert analysts and a High risk score when deployed directly to consumers, because the impact of errors differs dramatically between contexts where human experts provide a final review layer and contexts where AI outputs drive direct actions. This context-sensitivity is a critical feature of effective AI risk assessment and is frequently overlooked by organizations that assess risk at the model level without considering the deployment context.

Implementation Guidance

Step 1: Define Scope and Assemble the Assessment Team

A rigorous AI risk assessment begins with clear scope definition and an appropriate team. Scope definition specifies the exact AI system to be assessed (including model version, deployment context, affected user populations, and data inputs) and the regulatory and policy requirements against which the system will be assessed. Scope ambiguity is a leading cause of incomplete assessments, if the scope does not specify the deployment context, assessors may evaluate the model in isolation and miss the deployment-specific risks that represent the most significant exposure.

The assessment team should include at minimum: a data scientist or ML engineer with detailed technical knowledge of the model (architecture, training data, performance characteristics, known failure modes); a domain expert with deep knowledge of the business process the AI will support (who can evaluate whether AI outputs are plausible and whether edge cases the model might mishandle are consequential); a risk professional who can structure the assessment process and facilitate the risk scoring discussions; and a legal or compliance representative who can map identified risks to applicable regulatory requirements. For high-risk AI systems, the team should additionally include a data privacy expert, a security engineer, and where the system affects specific demographic groups, a representative from or expert on those affected communities.

The assessment kickoff meeting should establish: the assessment timeline, the roles and responsibilities of each team member, the documentation format for the risk register, and the escalation path for risks identified as critical. Setting these parameters in advance prevents the assessment from stalling at ambiguous decision points and ensures that the output is in a format that the organization can act on.

Step 2: Systematic Risk Identification Using the Taxonomy

Risk identification is the most consequential step in the risk assessment process. Risks that are not identified cannot be mitigated. The five-category AI risk taxonomy provides the structure to ensure systematic coverage, the assessment team works through each of the five categories and identifies the specific risk sub-types that are relevant to the system being assessed.

For each sub-type in the taxonomy, the team asks: Is this risk type potentially present in this AI system, given its architecture, training data, deployment context, and use case? If yes, what is the specific manifestation? For example, for a loan underwriting AI: Category 1 (Performance Risk), accuracy risk is present because loan approval decisions are consequential; distributional shift risk is present because economic conditions that affect creditworthiness change over time. Category 2 (Data Risk), training data representativeness risk is highly relevant because historical lending data reflects past discriminatory practices that may have underrepresented minority borrowers in the approved loans category, biasing the model toward denial for these groups. Category 5 (Ethical and Societal Risk), fairness and bias risk is among the highest-priority risks because disparate impact in lending has direct regulatory consequences under the Equal Credit Opportunity Act and Fair Housing Act.

The output of this step is a comprehensive risk register with an entry for each identified risk, including: risk category and sub-type, specific manifestation in this AI system, potential harm if the risk materializes, affected populations, and any existing controls. Risk identification should err on the side of comprehensiveness at this stage, risks can be deprioritized in the scoring step if they turn out to be low-likelihood and low-impact.

Step 3: Risk Scoring and Prioritization

With the risk register populated, the team applies the AI Risk Assessment Matrix to score each identified risk on likelihood and impact dimensions. This scoring step requires the most analytical judgment and benefits most from team diversity: the domain expert contributes knowledge of how consequential different types of errors are in the specific business context, the data scientist contributes knowledge of how likely specific model failures are given the model's architecture and training data, and the risk professional facilitates the discussion and ensures that assessments are calibrated consistently.

Likelihood scoring for AI risks requires considering both the base rate of the failure mode and the specific characteristics of this system that affect the probability. For training data representativeness risk, the likelihood depends on whether the training data has been audited for demographic coverage and whether bias testing has been conducted, a system with no bias testing has higher likelihood of this risk materializing undetected than one with comprehensive bias testing integrated into the CI/CD pipeline. For distributional shift risk, the likelihood depends on the volatility of the domain: a customer churn model in a stable industry faces lower distributional shift risk than a fraud detection model in a domain where fraudsters continuously adapt their tactics.

Impact scoring for AI risks requires considering both the direct harm to affected individuals and the organizational consequences (regulatory penalties, litigation, reputational damage). For fairness and bias risk in a loan underwriting context, the impact is Severe: denied loans to creditworthy individuals cause concrete financial harm, potential regulatory violations under multiple federal statutes carry significant penalties, and litigation exposure from discrimination claims can be substantial. For model staleness risk in a low-stakes internal recommendation use case, the impact may be only Minor, outdated recommendations reduce efficiency but do not cause significant harm.

After scoring, the risk register should be sorted by composite risk score to produce a prioritized list. The top 10-15 risks by score represent the critical risk management priorities. The organization should ensure that each of these has an assigned owner and a documented mitigation plan before the AI system is approved for deployment.

Step 4: Control Design and Residual Risk Assessment

For each risk requiring mitigation, the assessment team designs the control or set of controls that will reduce the risk to an acceptable level. Controls for AI risk fall into four categories: preventive controls (designed to prevent the risk from materializing, e.g., data quality checks that catch training data problems before model training), detective controls (designed to identify when a risk has materialized, e.g., monitoring systems that detect model performance degradation), corrective controls (designed to restore acceptable performance after a risk event, e.g., model retraining procedures), and compensating controls (designed to provide backup risk reduction when primary controls are insufficient, e.g., human review of AI outputs in high-stakes decisions).

After controls are designed and implemented, the team conducts a residual risk assessment: given the controls in place, what is the revised likelihood and impact for each risk? If the residual risk level is within the organization's risk tolerance, the risk is accepted with the controls in place. If the residual risk level remains above tolerance even with all feasible controls, the organization faces a decision: invest in additional controls, accept the excess risk with explicit approval from an appropriate risk authority, or modify or abandon the AI use case. This three-option decision framework prevents the implicit assumption that all AI use cases should proceed regardless of residual risk.

The residual risk assessment should be documented in the risk register alongside the initial risk assessment. This documentation creates an evidence base for regulatory examination (demonstrating that the organization conducted a thorough risk assessment and implemented appropriate controls), for governance oversight (enabling risk committees to verify that residual risks are within tolerance), and for post-incident review (enabling the organization to assess whether the incident resulted from control failure or from a risk that was identified and accepted).

Frequently Asked Questions

What is the difference between AI risk and traditional IT risk?

Traditional IT risk is primarily about system availability, data integrity, and security: risks that arise from deliberate attacks, infrastructure failures, or software defects. AI risk encompasses these traditional IT risk categories but adds a layer of risk that is specific to the statistical and learned nature of AI systems: performance risk (the model is not reliable enough for the use case), data risk (the training data does not support a model that will work as intended), model risk (the model's architecture or training produced problematic behavior), fairness risk (the model treats different groups differently in harmful ways), and opacity risk (the model's decisions cannot be explained or audited). The key practical difference is that AI risks often involve probabilistic failures, the model is sometimes wrong rather than always wrong, and distributed failures, the model fails more for some users or inputs than others, which makes them harder to detect and remediate than binary IT failures.

How do I handle AI risks that are difficult to quantify, like societal impact risk?

Hard-to-quantify risks require a combination of qualitative assessment, external benchmarking, and explicit assumption documentation. For societal impact risk, the assessment should describe the specific mechanism through which the AI system could produce societal harm (e.g., large-scale deployment could reduce employment in a specific occupation, or could concentrate economic opportunity among already-advantaged groups). Qualitative scoring (High/Medium/Low rather than numerical) is appropriate for risks where numerical precision is false precision. Benchmarking against similar AI deployments in peer organizations or in published case studies provides reference points for impact estimation. Documenting the assumptions behind the assessment enables future reviewers to update the assessment as evidence accumulates about actual societal impacts.

Should every AI system go through a formal risk assessment process?

No. A tiered approach is appropriate: the thoroughness of the risk assessment should be proportionate to the risk level of the AI use case. A rapid, lightweight risk assessment (15-30 minutes) using a pre-built risk checklist is appropriate for low-risk AI use cases (internal productivity tools, low-stakes recommendation systems, AI that assists but does not determine decisions). A standard risk assessment (several hours, using the full AI risk taxonomy) is appropriate for medium-risk AI use cases (customer-facing applications, systems that affect allocation of resources, systems involving personal data). A comprehensive risk assessment (days to weeks, involving a cross-functional team, external validation, and regulatory legal analysis) is appropriate for high-risk AI use cases (credit and insurance underwriting, employment screening, healthcare clinical decision support, criminal justice applications). The tiering threshold criteria should be defined in the organization's AI governance policy.

How often should AI risk assessments be refreshed?

At minimum, AI risk assessments should be refreshed at each of the following triggers: major model update (model retrained on new data, significant architecture change, significant prompt change for generative AI); significant change in deployment context (new user population, new use case, new geographic market, new integration with other systems); significant regulatory development (new regulation or regulatory guidance affecting the AI use case); post-incident analysis (following any AI incident, the risk assessment should be reviewed to determine whether the incident resulted from a risk that was identified and inadequately controlled or from a risk that was not identified); and periodic review on a schedule appropriate to the risk level (annually for medium-risk systems, semi-annually for high-risk systems).

What tools are available to support AI risk assessment?

Several categories of tools support different aspects of AI risk assessment. Bias testing libraries (IBM AI Fairness 360, Microsoft Fairlearn, Google's What-If Tool) provide implementations of fairness metrics and statistical tests for identifying demographic performance disparities. Model explainability tools (SHAP, LIME, InterpretML) provide methods for understanding what features drive model predictions, supporting assessment of opacity risk and enabling post-hoc explanation for affected individuals. AI governance platforms (Credo AI, Holistic AI, Monitaur) provide workflow management for the risk assessment process, model registry, and risk register functionality. NIST's AI Risk Management Framework companion playbook provides detailed guidance for implementing the four core functions. The EU AI Act's conformity assessment documentation requirements provide a compliance-oriented checklist that is useful for structured risk documentation regardless of whether the organization is in scope of the Act.

How do I handle conflicting risk assessments from different team members?

Conflicting risk assessments are a feature, not a bug. They surface genuine uncertainty and disagreement about risk levels that should be resolved explicitly rather than averaged away. The recommended approach is structured discussion: ask each party to articulate the specific assumptions and evidence underlying their assessment. Often, conflicting assessments resolve to different assumptions about the deployment context (the technical expert is assessing the model in isolation; the domain expert is assessing the model in a specific high-stakes deployment context) or different interpretations of impact severity (the data scientist is assessing impact in terms of model error rates; the compliance officer is assessing impact in terms of regulatory consequences). Making these assumption differences explicit usually leads to agreement. Where genuine uncertainty remains after discussion, the risk register should document the range of assessments and the assumptions behind each, and the risk should be scored at the conservative (higher) end of the range until evidence resolves the uncertainty.

What is the relationship between AI risk assessment and the EU AI Act's risk classification?

The EU AI Act classifies AI systems into four risk tiers: unacceptable risk (prohibited), high risk (subject to mandatory conformity assessment), limited risk (subject to transparency obligations), and minimal risk (no mandatory requirements). This regulatory classification is a specific, jurisdiction-specific framework that uses legal categories (prohibited, high-risk, etc.) for regulatory compliance purposes. The five-category AI risk taxonomy used in this chapter is a broader, non-regulatory framework that characterizes the specific types of risk present in any AI system, a system that falls in the EU AI Act's minimal risk category may still have significant performance risk or data quality risk that requires management. CAP Specialists should understand both frameworks and their relationship: the EU AI Act classification determines regulatory compliance obligations; the broader AI risk taxonomy determines what risk management activities are appropriate regardless of regulatory classification.