E-23 governance is exposing the limits of manual AI model risk

At a glance

What this is: This is an analysis of OSFI E-23 compliance through the lens of AI model risk, with the central finding that manual governance processes do not scale as AI use cases expand.

Why it matters: It matters because IAM, NHI and AI governance teams need controls that keep pace with production AI systems, delegated authority and continuous change rather than periodic review cycles.

Context

E-23 is pushing financial institutions toward more specific AI governance, but the underlying problem is broader than one regulator. Traditional model risk practices were designed for slower-moving systems with bounded inventories, while modern AI programmes change more quickly, expand across business functions and demand continuous oversight.

The operational gap is governance capacity, not policy intent. When reviews, documentation and validation remain manual, organisations create a bottleneck that leaves use cases stuck before production and weakens the credibility of the governance model. That tension is increasingly visible wherever AI programmes are scaling faster than human review can absorb.

Key questions

Q: How should organisations scale AI governance without creating production bottlenecks?

A: Use risk tiering, automated evidence capture and workflow routing so high-risk models receive deeper human review while lower-risk systems move through a lighter, repeatable lifecycle. The point is to govern continuously without forcing every use case through the same manual sequence. When governance scales this way, it supports delivery instead of slowing it.

Q: Why do manual model risk processes break down for fast-moving AI programmes?

A: They assume stable inventories, slow change and enough expert time to review every model in sequence. AI breaks those assumptions because use cases multiply quickly, update frequently and span more risk domains than legacy model risk processes were built to handle. The result is governance debt, delayed production and weaker visibility into what is actually live.

Q: What happens when AI governance reviews do not keep up with change?

A: The programme can approve a system that no longer matches its actual permissions, integrations, or business purpose. That creates drift between policy and practice, which usually shows up as audit gaps, incident surprises, or controls that are too weak for the current risk. In effect, governance becomes accurate only in retrospect.

Q: How should security teams govern AI agents that can change behaviour at runtime?

A: Security teams should govern AI agents with runtime monitoring, behavioural baselines, and identity-triggered response, not just static approval workflows. The goal is to detect when an agent drifts from expected purpose, reduce privileges immediately, and keep accountability tied to a named owner. In agentic environments, governance must work at machine speed rather than review cadence speed.

Technical breakdown

Why manual model risk controls break at AI scale

Manual model risk assumes a relatively stable inventory, infrequent change and enough specialist time to review each system in sequence. AI breaks that assumption because model count, update frequency and use case diversity expand at the same time. When controls depend on humans to edit inventories, compile evidence and run sequential checks, the process becomes the constraint rather than the safeguard. That is why organisations see long queues of AI use cases waiting to move into production. The issue is not that governance is unnecessary, but that the governance mechanism itself is built for a slower lifecycle. See the AI Risk Assessment Guide.

Practical implication: Rebuild governance around automated evidence capture and risk-based routing instead of adding more manual checkpoints.

How risk tiering changes the governance workload

Risk tiering lets organisations reserve deep human scrutiny for the small number of AI systems that are truly high risk. Lower-risk models still need control, but they can move through a lighter lifecycle with automated documentation, testing and monitoring. This is the practical answer to scale: treat governance effort as variable, not uniform. Without tiering, expert teams spend too much time on low-impact use cases and too little on the systems that matter most. The governance model then looks comprehensive on paper but misallocates scarce attention in practice. See the AI Governance Guide.

Practical implication: Build a defensible tiering method so high-risk AI gets expert review while lower-risk systems follow an automated path.

What built-in controls mean for agent behaviour and authority

The article’s strongest operational point is that governance must connect to live systems, not just records about them. Built-in controls, monitoring and kill switches only work if they can change capabilities in real time when conditions shift. That is especially relevant where AI agents act with delegated authority, because the governance challenge is no longer just approval at launch but ongoing control over what the system can do. In identity terms, the control plane is becoming part of the trust model. [[L6|Identity Governance for AI Agents Guide]] is relevant here because agent ownership, lifecycle and revocation now sit inside the governance problem. See the Identity Governance for AI Agents Guide.

Practical implication: Treat agent authority as something that must be continuously governable, revocable and visible in a central system of record.

NHI Mgmt Group analysis

Manual AI governance is becoming a control bottleneck, not a control layer. The article shows that adding more reviews and checkpoints to model risk processes does not scale when AI inventories are expanding rapidly. Governance that depends on manual sequencing will always lag the systems it is meant to govern. Practitioners should treat automation as a governance requirement, not an efficiency upgrade.

Risk tiering is the only defensible way to preserve expert attention. High-risk AI deserves human-led scrutiny, but low- and medium-risk systems need a lighter path if the programme is to remain operational. Without tiering, organisations burn specialist capacity on low-value work and under-govern the systems with the greatest business exposure. The discipline is to reserve human judgement for the cases that justify it.

AI governance debt: the gap created when inventories, ownership and evidence trails lag behind real production AI systems. That debt accumulates whenever governance records are edited after the fact rather than maintained through the lifecycle. The article makes clear that the problem is structural: the organisation no longer knows its true AI estate fast enough to govern it well. Practitioners should assume governance debt will surface first as delay, then as blind spots.

Agent governance now overlaps with identity governance. When AI systems can change behaviour, receive authority and be turned off through policy, they start to look like managed digital workers rather than static models. That creates a direct governance bridge to agent identity, lifecycle control and revocation discipline. The organisational question is no longer only whether a model is approved, but whether its authority is continuously bounded. Practitioners should align AI governance with lifecycle and revocation controls for agentic systems.

E-23 will reward organisations that make governance executable. The article’s real message is that policy language is not enough unless it is tied to current state, monitoring and action. Organisations that can translate governance requirements into live controls will move faster and create stronger audit evidence. Practitioners should design AI governance so that controls can be enforced, not merely documented.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Risk Assessment Guide

What this signals

AI governance debt: organisations now accumulate risk whenever inventories, ownership and evidence trails lag behind production AI systems. Governance has to move from after-the-fact documentation to live lifecycle control if it is going to remain credible, and that shift is as much about operating model design as it is about compliance.

The control question is no longer whether AI can be reviewed, but whether review can happen at the same pace as model change. That is why tiering, automation and centralised authority matter together: they reduce friction without abandoning accountability.

AI security decision-making power is shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey. For practitioners, that means governance needs operating controls that those teams can actually enforce day to day.

For practitioners

• Build a defensible AI inventory Create a current inventory of models and AI systems, then tie each entry to an owner, risk tier and production status so governance reflects reality rather than spreadsheets. See the AI Governance Platform Buyer's Guide.
• Define tiering criteria before scaling Use a consistent risk model to separate high-risk AI from lower-risk use cases so expert review is reserved for the systems that truly need it.
• Automate documentation and validation loops Use templates, test automation and workflow checks to capture evidence during the lifecycle instead of reconstructing it after deployment.
• Centralise control actions and status Maintain a single system of record where monitoring results, control changes and shutdown actions are visible to governance, operations and executives.

Key takeaways

• Manual AI governance does not scale when model inventories, updates and ownership changes are expanding faster than review cycles can absorb.
• The key operational shift is from static documentation to tiered, automated control of live AI systems.
• Where AI agents receive delegated authority, governance and identity management start to overlap, making revocation and visibility essential.

Related NHI Mgmt Group resources: AI Risk Assessment Guide · AI Governance Guide · Identity Governance for AI Agents Guide

Key terms

• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
• Risk tiering: Risk tiering is the practice of grouping vendors by the level of exposure they create based on data access, system criticality, and business dependency. It lets organisations spend more control effort where the blast radius is largest and keep lower-risk relationships under lighter governance.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
• Central System Of Record: A single authoritative place where status, control actions, monitoring results and ownership are visible for each AI system. It reduces fragmentation across teams and makes it possible to enforce governance decisions in near real time.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and agentic AI identity in a way that supports modern access and control programmes. It gives practitioners a common language for governing delegated authority, lifecycle control and machine identities across the broader security stack.