Enterprise risk management has always evolved alongside the technologies that create new exposure. Cloud computing forced a rethink of perimeter security. Algorithmic trading required new frameworks for model risk. Mobile and SaaS changed third-party vendor oversight entirely.
AI adoption is doing something different in kind, not just degree. It is not just adding new categories of risk to the existing framework - it is changing the nature of risk itself. The speed of exposure, the invisibility of failure, the scale at which a single model decision propagates across operations: these are not risks that slot neatly into a quarterly review cycle or a static risk register, and they are what make enterprise risk management for AI a structurally different discipline from what came before.
This article is about that transformation. Not the regulations that govern it - we have covered those. Not the governance programs that manage it - we have covered those too. This is about what happens to the discipline of enterprise risk management when AI becomes both a business tool and a risk source simultaneously. What has to change, structurally, in how organisations identify, assess, and respond to risk.
The Risk Profession Is Being Asked a Question It Was Not Built to Answer
Traditional enterprise risk management is built on a core assumption: that risk can be identified before it materialises, assessed with reasonable confidence, and mitigated through controls that hold over time. That assumption has always been imperfect, but it was workable. AI undermines each part of it.
Consider identification. A risk you cannot see is a risk you cannot manage. In prior technology eras, the systems creating risk were discrete, IT-approved, and visible to the organisation that deployed them. In the AI era, a SaaS platform can embed a generative AI feature in a product update overnight. An employee can connect a third-party AI tool to enterprise data without procurement involvement. A vendor's model can be silently retrained on new data that shifts its behavior. The perimeter of what constitutes 'your AI estate' is no longer something an organisation controls by default - it requires active, continuous AI governance to maintain visibility across it.
88% | 40% | 233 |
Consider assessment. Risk quantification assumes you can model the probability and impact of a failure event. AI models produce probabilistic outputs, not deterministic ones. Their behavior changes as input data shifts, a phenomenon called model drift - which means a model that passes a risk assessment in January may behave materially differently by June without any human intervention. The standard risk assessment toolkit, built for stable, bounded systems, has no native mechanism for this.
Consider controls. A control is effective if it holds over time and across conditions. AI-specific controls, human oversight mechanisms, output filters, confidence thresholds - are not static. They must be tuned as models evolve, as use cases expand, and as adversarial pressure tests them. An organisation that approved a model's output filter at deployment and never reviewed it again does not have a control. It has a false assurance.
The Structural Gap |
Risk management as a profession was designed for a world where the thing being assessed was stable enough to assess. AI has introduced a class of systems that change between assessments, make decisions faster than humans can review them, and fail in ways that are difficult to observe until the failure has propagated. The frameworks have not caught up. That is the core challenge. |
Four Ways AI Adoption Is Actively Reshaping the Risk Function
1. The Risk Register Is No Longer Fit for Purpose
The risk register - the central artifact of enterprise risk management, was designed to catalogue known, bounded risks. It is a static document, updated periodically, reflecting the organisation's view of its exposure at a point in time.
AI makes risk registers structurally inadequate in three ways. First, the population of risks changes faster than any periodic update cycle can track. A new AI tool adopted by one business unit this week creates exposures that will not appear in the next quarterly register update. Second, AI risks are contextual - the same tool creates different risk profiles depending on how it is deployed, what data it processes, and who uses it. A flat register entry cannot capture this. Third, the interdependencies between AI systems, where one model's output becomes another's input - create cascading failure paths that linear risk registers were not designed to represent.
What replaces it is not a better register. It is a live risk inventory - one that is continuously updated as the AI estate changes, that captures risk at the use-case level rather than the tool level, and that maps interdependencies across systems. This is the enterprise risk management operating model that AI demands, not an upgrade of the existing one.
2. Risk Velocity Has Changed - and Most Organisations Have Not
Risk velocity, the speed at which a risk event manifests and propagates - has accelerated dramatically with AI adoption. A traditional operational risk event, say, a process failure in a manual workflow, typically has human-speed propagation: someone notices something is wrong, escalates, and containment begins. An AI failure at inference speed can process hundreds of thousands of decisions incorrectly before any human is aware something has gone wrong.
The data makes this concrete. According to Aon's 2026 AI Risk analysis, AI-crafted phishing emails now show click-through rates up to double those of manually written attacks, and the mean time between an AI model failure and its detection in production environments remains measured in weeks, not hours, for most enterprises.
Risk functions built around weekly reporting cycles and quarterly reviews are operating at a cadence that is structurally mismatched with the speed of AI-driven exposure. The implication is not that risk teams need to work harder - it is that the monitoring infrastructure needs to work continuously, and escalation thresholds need to be defined at the system level, not the human review level.
What this means for risk teams |
The question is not whether your organisation can respond to an AI risk event quickly. It is whether your detection mechanisms can surface the event before it has already propagated at scale. Detection latency - not response speed, is the primary AI compliance challenge in AI-heavy environments. |
What Montro finds in Risk-aware Organisations |
The finding that creates the most concern in risk-aware financial firms is not the number of ungoverned AI tools; it is how long they had been running before anyone in the risk team knew they existed. The article explains risk velocity as the speed at which a failure propagates once it starts. The discovery gap is the other dimension of the same problem, the period between when an AI tool enters the environment and when the risk function becomes aware of it. In the firms Montro has worked with, this gap was consistently measured in months. A tool the credit analysis team adopted in February was discovered in September. The risk register did not capture the exposure for seven months, the third-party risk assessment did not cover it, and the quarterly review cycle did not surface it. The velocity of the failure is one risk, and the invisibility of the exposure before a failure is another. Most risk frameworks are built to cover the first. Almost none are built to close the second. |
3. The Third-Party Risk Model Is Being Rebuilt From the Outside In
Third-party risk management has always required organisations to assess the risks introduced by vendors and partners. The assessment model was bilateral: you review the vendor, you set contractual controls, you conduct periodic audits.
AI has made this model insufficient in a specific and important way: the third-party risk now travels inside your own products. When a SaaS vendor embeds an AI feature in a platform your operations team uses daily, the AI is running inside your environment, on your data, influencing your processes, but it was never assessed by your third-party risk function because it was not a new vendor relationship. It was a product update.
Traditional Third-Party Risk Model | AI-Era Third-Party Risk Reality |
Triggered by a new vendor contract or onboarding | Triggered continuously - AI enters via product updates, API changes, embedded features, not just new vendors |
Assessment is point-in-time at procurement | Assessment must be continuous - vendor AI models are retrained, updated, and changed post-contract |
Scope is the vendor's systems and data practices | Scope extends to every AI feature embedded in every tool in the SaaS stack, regardless of when it appeared |
Contractual controls are set at signing | Contractual controls must include audit rights over AI model changes, retraining schedules, and output monitoring |
The practical implication is that third-party risk now requires the same continuous discovery capability as internal AI governance. You cannot conduct third-party AI risk assessments if you do not know which third-party AI systems are active in your environment at this moment, which is why security governance across the SaaS stack requires the same continuous discovery capability as internal AI governance.
4. Risk Ownership Is Becoming Ambiguous, and That Ambiguity Is a Risk in Itself
In traditional enterprise risk management, ownership is relatively clear: operational risks sit with operations, financial risks with finance, IT risks with IT and the CISO. The function that creates the exposure owns the risk.
AI breaks this model because AI systems create exposure that spans functional boundaries simultaneously. A generative AI tool used by the marketing team may expose the organisation to data privacy risk (GDPR), reputational risk if outputs are inaccurate or biased, cybersecurity risk if it connects to internal data sources, and regulatory risk if outputs are used in regulated communications. No single function owns all of those exposures. And in most enterprises, no single function is responsible for the AI tool itself - it was adopted by a business unit, connected by IT, and is now monitored by no one consistently.
Stanford's 2026 AI Index found that 62% of organisations cite security and risk as the primary blocker to scaling agentic AI - outranking technical limitations, regulatory uncertainty, and gaps in responsible AI tooling.
The risk management response to this is not to reorganise functional ownership, it is to establish a cross-functional AI risk accountability structure that cuts across traditional silos. This means a designated AI risk function, or a named owner within the existing risk function, with a mandate that spans IT, legal, operations, and business - and with the tooling to maintain visibility across all of them.
What the Numbers Say About Where Enterprise Risk Programs Actually Stand
The gap between where AI risk management needs to be and where most organisations currently operate is significant, and measurable.
The AI model risk management market tells a parallel story. It is projected to grow from $7.17 billion in 2025 to $15 billion by 2030, driven not by organisations that have solved the problem but by organisations recognising they have not, and investing to close the gap. The market is growing because the gap is growing.
The readiness breakdown follows a consistent pattern across industries. Organisations tend to overestimate their coverage because they measure governance inputs - policies published, committees formed, training completed - rather than governance outcomes: how many AI systems are actively monitored, how quickly anomalies are detected, how accurately risk classifications reflect actual deployment context.
The Risk Framework Adaptations That Are Actually Working
Across the organisations that have made meaningful progress in AI risk management, a set of structural adaptations appears consistently. These are not technology choices - they are operating model changes.
Shifting from periodic assessment to continuous risk intelligence
The single most impactful change is moving from quarterly or annual AI risk assessments to continuous monitoring with defined alert thresholds. This does not require replacing existing risk governance structures, it requires adding a real-time data layer beneath them. Risk committees still meet. But they review live dashboards, not retrospective reports, and escalation is triggered by system behavior, not by calendar cycles. That shift is what compliance automation looks like in an AI risk context.
Separating inherent risk from residual risk in AI contexts
In traditional risk management, inherent risk is assessed before controls, and residual risk after. AI requires a third category: dynamic risk, the exposure that emerges as a model drifts from its assessed baseline over time, independent of whether controls have changed. Organisations that are managing AI risk effectively have built monitoring specifically for this: tracking model behavior against the baseline established at assessment, and triggering re-assessment automatically when drift crosses defined thresholds.
Building AI risk into the change management process
One of the most effective adaptations is treating AI model updates, including vendor-side updates to embedded AI features - as change events that trigger risk review. This is straightforward in principle and operationally demanding in practice: it requires the kind of continuous AI estate visibility that most organisations do not yet have. But for those that do, it converts enterprise risk management from a reactive discipline into a proactive one, and it is the adaptation that most clearly separates mature AI governance programmes from ones that are still catching up.
Redefining 'material' for AI-specific incidents
What constitutes a material AI incident, one that requires escalation, documentation, and potentially regulatory notification - is still being defined by most organisations. The enterprises managing this most effectively have pre-defined materiality thresholds specific to AI: accuracy degradation beyond a set percentage, bias metrics crossing a fairness threshold, anomalous output patterns above a defined volume. Without pre-defined thresholds, 'material' defaults to 'whatever someone noticed', which is not a risk management standard.
The Risk Function of 2026 Looks Different - and That Is the Point
The organisations that are managing AI risk effectively in 2026 have not patched their existing frameworks. They have recognised that the risk function itself needs to evolve, in its operating cadence, its tooling, its ownership model, and its definition of what constitutes adequate control.
That evolution has three visible characteristics.
Risk intelligence is live, not quarterly. Monitoring happens at machine speed because the exposure moves at machine speed. Human review is reserved for escalations and decisions, not data collection. Risk is assessed at the use-case level, not 'we use an AI HR tool' but 'this specific AI tool, used in this way, by these users, on this data, creates this specific exposure profile.' And AI risk does not belong to IT, legal, or the business alone, it belongs to a cross-functional accountability structure with the mandate and visibility to govern across all three.
This is not a vision of where risk management is heading. It is a description of what the most effective risk programs look like today, and the distance between that and the median enterprise is the competitive and compliance gap that will define the next two years.
Frequently Asked Questions
How is AI risk different from the technology risks enterprises have managed before?
Previous technology risks - cloud security, model risk in trading, third-party vendor exposure, were bounded. The systems creating risk were discrete, IT-approved, and visible. AI introduces risk that expands dynamically in ways traditional governance models were not built for. The AI estate is not fixed, a vendor can add an AI feature to an existing product overnight, expanding the risk perimeter without any procurement decision. The behaviour of AI systems is not stable, model drift means a system that was assessed as acceptable in January may produce materially different outputs by June. And AI systems can operate at a scale and speed where failures propagate faster than traditional oversight processes were designed to detect. These are not incremental changes to the risk profile. They are changes to the nature of the risk itself.
What does "model drift" mean in practice for a risk function?
Model drift is the gradual change in a model's behaviour as the data it processes changes over time, without any deliberate modification to the model itself. A credit scoring model trained on 2023 data may produce systematically different outputs when applied to 2025 applicant profiles, because the underlying patterns in the data have shifted. The risk management implication is significant: a model that passed a point-in-time risk assessment at deployment may no longer represent the risk profile the assessment captured. For risk functions accustomed to assessing systems at procurement and reviewing them annually, model drift creates a category of exposure that sits entirely outside the assessment cycle. Effective AI risk management requires monitoring for behavioural deviation from the assessed baseline continuously, not periodically.
Who should own AI risk in an organisation where AI spans multiple functions?
This is one of the hardest structural questions in AI governance, and most organisations have not resolved it cleanly. A generative AI tool used by the marketing team can simultaneously create data privacy exposure under GDPR, reputational risk from inaccurate outputs, cybersecurity risk from its data connections, and regulatory risk if its outputs feed into regulated communications. No single function owns all of those exposures. The response that holds most consistently is a designated AI risk function, or a named owner within the existing risk function, with a cross-functional mandate that spans IT, legal, operations, and the business. Without that mandate, AI compliance ownership defaults to whoever notices the problem last, which is rarely the right person at the right time, and which is the accountability gap that security governance structures are specifically designed to close.
How should a risk function approach the third-party AI risk created by vendor product updates?
The traditional third-party risk model was triggered by new vendor relationships - a new contract, a new onboarding, a new assessment. AI has broken this model because third-party AI now enters the environment through product updates to existing tools, not through new vendor relationships. When a SaaS vendor embeds an AI feature into a platform your operations team already uses, that AI is running in your environment on your data, but it was never assessed by your third-party risk function because no new vendor relationship was created. The practical response is to treat AI feature activations within existing vendor products as change events that trigger risk review, the same way a new vendor would. This requires continuous visibility into the AI features active within your SaaS stack, without that visibility, the assessment cannot happen.
