How Separate AI Governance Will Create Compliance Headaches Under OSFI E-23

OSFI's E-23 guideline will advantage institutions with unified model inventories over those with separate AI governance programs, creating duplicate validation regimes for the same systems.

What most people think

A dedicated AI governance function represents mature regulatory response. Separating AI risk from model risk provides focus and seniority. This approach ensures specialized attention to AI-specific concerns while maintaining clear lines of accountability.

What the data shows

Our live incident database tracks 1,500 AI failure stories from public news in the last 180 days. In the most recent 45-day window, there were zero model-category incidents compared to one in the prior period. This suggests model risk failures are rarely reported in the news that governance teams typically monitor.

The EU AI Act's high-risk obligations and serious incident reporting requirements apply to the same systems covered by OSFI E-23, but seven months later in December 2027. This creates a compressed timeline where both regulatory regimes will overlap.

Why this happens

OSFI E-23 is fundamentally a model risk management guideline, not an AI guideline. Its scope explicitly includes "models including AI/ML." When a system qualifies as both a model and an AI system, it must satisfy both model validation and AI governance review requirements.

Institutions with a unified model inventory can treat AI systems as part of their existing model risk framework, validating them in a single cycle. Organizations with separate AI governance programs, however, face two distinct validation schedules with potentially different evidence requirements for the same system. This duplication creates unnecessary complexity and potential reconciliation failures.

The best argument against this

The strongest counterargument is that AI requires specialized governance attention distinct from general model risk. AI systems have unique failure modes that demand focused expertise and dedicated oversight. Separating these functions ensures proper attention to AI-specific concerns like explainability, bias, and novel risks.

However, this separation creates practical problems when regulatory frameworks like OSFI E-23 explicitly include AI within their scope. The solution isn't necessarily unified governance, but rather conscious design of how these frameworks interact, with clear decision points about where AI-specific oversight fits within the broader model risk management process.

What I think happens next

By May 2028, at least one Canadian financial institution will publicly disclose a remediation finding related to a mismatch between its AI governance review cycle and its E-23 model validation cycle for the same system. This would appear in regulatory filings, enforcement notices, or trade-press reports we ingest.

What would prove this wrong: If no such disclosure or enforcement story appears in our feed or in OSFI published findings by May 31, 2028, the claim is incorrect.

What to do about it

• Map every AI system to both its E-23 model validation cycle and its AI governance review cycle. Identify systems where these dates diverge by more than one quarter.
• Decide now whether AI governance review will function as a gate within model validation or as a parallel process. Document this decision clearly for all stakeholders.
• Consolidate evidence packs so one artifact satisfies both regimes rather than producing separate documentation for each review cycle.

For institutions struggling with how to structure these overlapping requirements, the Argus platform (argus.threatclaw.ai) can help by tracing every interaction an AI application produces, providing concrete evidence that satisfies both model risk and AI governance requirements.

When considering how to structure your AI governance approach, remember that the goal isn't simply to meet regulatory requirements but to create a system that provides meaningful oversight without creating unnecessary duplication of effort. As discussed in "Why Your AI Projects Need Their Own Rulebook" on ThreatClaw, the most effective approach balances specialized oversight with efficient processes.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.

Related reading:

• When One AI Disagrees With Its Twin, Hackers Win on ThreatClaw
• Why Your AI Projects Need Their Own Rulebook on ThreatClaw