AI risk gaps your board register is missing

AI systems fail differently than software. Here's a practical risk taxonomy covering model, data, operational, and reputational risk for board-level oversight.

Your enterprise risk register probably has a row for "technology risk" and another for "cybersecurity." Neither one captures what happens when an AI system starts producing wrong outputs because the world changed and the model did not. That is not a cybersecurity incident. It is not a software bug. Your existing register has no name for it.

The extension argument sounds reasonable until you test it

Palo Alto Networks and Valuementor both argue that boards do not need a new AI risk taxonomy. Extend ISO 31000, add AI-specific sub-categories to your operational risk register, and you get the same coverage without standing up a parallel governance structure. This is a coherent position. Governance fatigue is real, and two overlapping registers that produce conflicting risk ratings for the same AI deployment would be worse than one imperfect register.

The problem is that the extension argument assumes existing GRC categories are structurally capable of capturing AI failure modes. NIST's 2023 Appendix B on how AI risks differ from traditional software risks says they are not. AI outputs change without reprogramming. AI behavior depends on training data the operator does not fully control. AI systems fail in ways neither the operator nor the vendor predicted. These are not sub-types of "IT risk." They are structurally different failure modes that require different named categories to even appear on a risk register.

What the four categories actually cover

Model risk is the failure mode NIST Appendix B is describing: the model drifts, degrades, or produces outputs that were never tested because the deployment context changed after training. No one reprogrammed anything. The system just stopped working correctly, and no existing IT control caught it because IT controls look for unauthorized changes, not behavioral drift in systems that are behaving exactly as designed.

Data risk sits one layer below model risk. The model performs exactly as trained. The training data was biased, incomplete, or legally problematic. The EU AI Act's four-tier harm classification — unacceptable, high-risk, limited risk, minimal risk — is organized by what the AI does to people, not by what technical category the system falls into. A board using a system-type register will never generate the harm-level classification the EU Act requires without rebuilding the register from a different organizing principle.

Operational risk in an AI context means third-party dependency on vendors whose model updates you do not control, and on data pipelines that can fail silently. Ajit Jaokar's 2026 commentary on enterprise AI risk identifies scale asymmetry as a specific problem here: a single AI system deployed across thousands of decisions per day amplifies a control failure faster than any human process would. Standard operational risk controls assume a human somewhere in the loop who notices something is wrong. Many AI deployments do not have that.

Reputational risk is the one boards tend to underestimate until it happens. An AI hiring tool that produces discriminatory recommendations, a customer-facing chatbot that gives dangerous advice, a fraud detection model that disproportionately flags one demographic — none of these require a data breach or a regulatory fine to damage the organization. The harm is the output itself.

What a board-ready approach actually requires

MIT's AI Risk taxonomy names four mitigation buckets: governance and oversight, technical controls, operational process controls, and transparency and accountability controls. None of these map cleanly onto a standard GRC register. Transparency and accountability, for instance, requires the board to ask what the AI does to people — not how it works. That is a different question than any IT audit currently asks.

NIST AI RMF 1.0 requires governance, measurement, and monitoring mapped across the full AI lifecycle, not point-in-time controls. The practical implication for a board risk committee is that AI risk reporting cannot be a quarterly snapshot. A model that passed validation in January may be producing degraded outputs by March because the underlying data distribution shifted. The board needs a named owner, a monitoring cadence, and a threshold for escalation — for each deployed AI system, not for "AI" as a single register entry.

I have sat through risk committee presentations where the CISO presented AI risk as a subset of the cybersecurity update. The slide was titled "Emerging Technology Risks." Model drift was not on it.