AI Risk Taxonomy Every Board Needs Now

Generative AI creates risk categories your enterprise risk register was never built to catch. Here is the taxonomy boards need to govern it.

Your enterprise risk register has columns for operational risk and reputational risk. A board has typically reviewed it and signed off on the controls. None of work covers what happens when a generative AI model hallucinates a legal citation in a client-facing document, or when a training dataset turns out to contain personal data your company never had permission to use. These are not edge cases waiting to be slotted into existing categories. They are structurally new failure modes.

The gap is not a labeling problem

NIST AI 600-1, the federal government's generative AI risk profile published in 2024, identifies 12 distinct risk categories for generative systems. These include emergent behavior and data provenance failures alongside model misuse. None of these map cleanly onto the operational or compliance risk categories most enterprise risk registers use. The AIR 2024 preprint reviewed 8 government policies and 16 company policies worldwide and reached the same conclusion from a different direction: policymakers needed a shared AI risk language precisely because existing policy language did not cover the new territory.

Compel Framework authors argue for extending existing enterprise risk frameworks rather than replacing them, making a reasonable governance-design point. Boards already manage complex risk portfolios across multiple committees. Adding a parallel AI taxonomy creates coordination overhead. The concern is legitimate. The extension argument fails, though, because it assumes existing categories are broad enough to serve as containers for AI-specific risks. Ecosystem harm and emergent behavior do not have parent categories in a standard operational risk register. Existing buckets simply do not fit.

Four categories give boards a workable grip

The four-category structure below draws on NIST AI 600-1 and the AIR 2024 taxonomy work, supplemented by the Airia and Databricks framework sources. It is not a simplification of the 12 NIST categories — it is a translation into language a non-technical board member can own and act on.

Model risk covers failures originating in the AI model itself: hallucination and bias in outputs, plus behavior the model's designers did not anticipate. A board-level control here is requiring pre-deployment audits before any model goes into a customer-facing or decision-making context. The MIT AI Risk team names pre-deployment risk assessment as a practical mitigation, and it is the one control most organizations skip because it slows down deployment timelines.

Data risk covers the inputs train and feed AI systems. Training data containing personal data without consent and biased historical data encoding discriminatory patterns both belong here. This is distinct from traditional data governance risk because the harm is not a data breach — it is a model produces systematically wrong or illegal outputs because of what it learned.

Operational risk in the AI context is narrower and more specific than the operational risk category in a standard ERM register. Companies embed AI systems in business processes, and those systems fail or get used in ways they were not designed for. Autonomous agents executing multi-step workflows without human checkpoints are the sharpest example. The Compel Framework is right this is structurally new — autonomous action and multi-step execution have no real analogue in traditional process failure risk.

Reputational risk from AI is real but the board-level evidence for it is thinner than for the other three categories. Airia includes it alongside security and compliance groupings. NC State's ERM site frames it as a board-level concern. Reputational harm from AI failures is plausible and well-documented in news coverage, but hard data on board-level reputational exposure is not yet robust in the published research.

What a board-ready approach requires

Palo Alto Networks' AI risk guidance makes a point most governance frameworks bury: AI risk management needs leadership ownership across the full AI lifecycle, not a narrow cyber-only view handed to the security team. Boards need a named owner for each of the four categories above, not a committee reviewing a quarterly report.

NIST AI Risk Management Framework's Govern-Map-Measure-Manage structure from 2023 gives the board a process spine. Govern means setting policy and ownership. Map means identifying which AI systems the organization runs and which risk categories apply. Measure means defining what a failure looks like and how you would detect it. Manage means the controls and response plans. Most organizations are somewhere between Govern and Map. Almost none have reached Measure with any rigor.

One thing I find genuinely frustrating about how boards approach this: most AI risk conversations get handed to the CTO or CISO and treated as a technical briefing. The 12 NIST categories are not a technical specification. Ecosystem harm and model misuse are governance and ethics questions belong in the boardroom, not the server room. The board does not need to understand how a transformer model works. It needs to know which AI systems are making consequential decisions and who owns the risk when those decisions are wrong. The pre-deployment audit process must be settled before the next model goes live.