AI Risk Is Not IT Risk: Why Your Existing Frameworks Are the Wrong Starting Point

When a board’s risk committee receives an AI risk update, it typically looks like an IT risk update with a new heading. Threat categories, control owners, residual risk ratings, escalation thresholds. The framework is familiar because it was borrowed from cybersecurity and data privacy, the last two major technology risk domains the business had to absorb.

The problem is that AI risk is structurally different from IT risk. Not more complex in a general sense — different in kind. The threat model is different, the failure modes are different, and the controls that work for one don’t work for the other. Running AI risk through an IT risk framework is like using a fire suppression system to manage flood risk. Both are disaster scenarios. The equipment doesn’t transfer.

Most organizations won’t discover this until something goes wrong. At that point, the questions — who was monitoring this, what controls were in place, who was accountable — will point back to a governance structure that was never designed for the problem it was supposed to prevent.

Why IT risk frameworks break on AI

IT risk is fundamentally binary. A system is breached or it isn’t. Data is exfiltrated or it isn’t. A control is working or it has failed. The threat model assumes a boundary — a perimeter — and the job is to defend it. When the perimeter is breached, you know. There’s an incident. Systems go down, alerts fire, logs show the intrusion.

AI risk doesn’t work that way.

The most dangerous AI failure modes are probabilistic and continuous. A model doesn’t fail — it drifts. Its performance degrades incrementally as the world changes and the training data becomes less representative. There’s no incident, no alert, no obvious moment when things stopped working. The model continues to produce outputs that look correct. Business processes continue to run on those outputs. Trust accumulates in a system that is quietly becoming less reliable.

This is the silent failure mode that IT risk frameworks have no vocabulary for. A cyberattack is visible by design — the attacker wants access. A degrading model is invisible by design — there’s nothing malicious, just a slow divergence between what the model learned and what the world currently looks like.

The second structural difference is the threat surface itself. IT risk focuses on external threat actors: attackers, phishing campaigns, vulnerability exploitation, insider threats. AI risk introduces an entirely different threat surface: data poisoning during training, adversarial inputs designed to manipulate model outputs, emergent behaviors that weren’t anticipated in testing, and feedback loops where a model’s outputs influence the data it will be trained on next.

These are not threats a penetration test catches. They’re not threats a SIEM detects. They require a different monitoring approach and a different set of controls.

The control gap

IT risk controls are designed around access, authentication, encryption, patching, and incident response. These are the right controls for IT risk. Most of them are irrelevant to AI risk or address a small subset of it.

The controls that actually matter for AI risk are:

Model monitoring. Tracking model performance over time against defined thresholds — not just system availability, but whether the model’s outputs remain accurate and calibrated. This requires ground truth data, a measurement cadence, and someone accountable for reviewing the results.

Data provenance and lineage. Understanding where training data came from, what transformations it went through, and whether those sources have changed. A model trained on data that has since changed in composition is a model with an unknown risk profile.

Input validation. Monitoring what the model is being asked to score in production, and detecting shifts in the input distribution that may indicate the model is being asked to operate outside its training domain. This is not the same as network traffic monitoring.

Explainability requirements. For consequential decisions — credit, insurance, hiring, medical — the ability to explain why the model produced a specific output for a specific input is both a regulatory requirement in many jurisdictions and a basic operational requirement for incident response.

Decommissioning criteria. A defined threshold at which a model is pulled from production, not left running after it has degraded past the point of reliability. Most IT governance has no equivalent because software doesn’t degrade the way models do.

None of these appear in a standard IT risk control library. They require a purpose-built AI risk framework or significant extension of existing frameworks — not a mapping exercise that tries to force AI risk into existing categories.

The accountability mismatch

IT risk has clear ownership because IT risk maps to IT infrastructure. The CISO owns the security controls. The CTO owns the infrastructure. Accountability lines are established.

AI risk doesn’t map to the same functions. The data science team that built the model may not have the operational accountability for what it does in production. The business unit that requested the model may not have the technical literacy to understand the risk it carries. The IT function that runs the infrastructure may have no visibility into whether the model is performing correctly.

The accountability gap in AI risk is not a people problem — it’s a design problem. The organization hasn’t defined who owns AI risk at the model level, and existing governance structures don’t force that definition because they weren’t built with AI in mind.

Good AI risk governance requires a named risk owner for each production model: someone accountable for monitoring its performance, escalating anomalies, and making the decommissioning call when thresholds are breached. That’s a different role from anything in a standard IT risk organization chart.

What the board’s AI risk conversation needs to cover

Most board-level AI risk conversations are about whether the organization has an AI risk policy. That’s the wrong question. The right questions are operational:

Which AI systems are currently making decisions that affect customers, employees, or revenue — and what is the monitoring status of each? What is the defined performance threshold below which each system would be paused or replaced? When did the board last receive an update on actual model performance, not just program status? What is the process for escalating an AI failure to board level, and has it ever been tested?

These are not technology questions. They’re governance questions that require technology inputs. The reason they’re not being asked is that the board’s risk framework doesn’t prompt them — because the framework was built for a different threat model.

The regulatory layer

The EU AI Act introduces a formal risk taxonomy for AI that is worth understanding even for organizations not primarily subject to EU law — because it’s the clearest articulation currently available of what AI-specific risk management looks like at a regulatory level.

The Act’s risk tiers map roughly to the severity and reversibility of consequences: prohibited uses (facial recognition in public spaces, social scoring), high-risk uses (credit, hiring, education, law enforcement support), and lower-risk uses with transparency requirements. High-risk systems require conformity assessments, ongoing monitoring, human oversight provisions, and auditability of training data.

Whether or not an organization is directly subject to the Act, those categories are a useful starting framework for internal AI risk classification. The question “would this qualify as high-risk under the EU AI Act?” is a reasonable first filter for deciding which AI systems need the most rigorous governance treatment.

Organizations in financial services and healthcare already have sector-specific AI risk guidance from their regulators — the EBA, PRA, FDA, and others have all issued guidance that is more detailed and more prescriptive than general enterprise risk frameworks. These are the relevant starting points for organizations in those sectors, not the enterprise risk framework that was designed before AI was a material concern.

Building an AI risk framework from scratch is a significant undertaking. Borrowing one from IT risk is the path of least resistance, and the path most likely to leave the organization exposed when something goes wrong. The frameworks aren’t interchangeable, and the gap between them is where most AI governance failures currently live.