Recent discussions on operational risk benchmarking reveal a critical issue: banks are divided on whether AI risk should have its own category or be part of existing frameworks. This decision impacts which committee handles AI incidents, the capital calculations applied, and who responds when a credit model drifts.
What the Benchmarking Shows
Conversations with practitioners highlight several tensions:
Varied structural placement. Some banks classify AI risk under technology or model risk. Others have standalone AI risk functions reporting to the Chief Risk Officer. A third group distributes AI accountability across business units, with centralized oversight for high-risk systems under the EU AI Act.
Governance gaps at handoff points. When model risk teams validate an AI system but operational risk teams manage post-deployment incidents, accountability blurs. For example, if a loan origination model is validated pre-launch but later approves loans outside policy, operational risk logs it as a technology failure. Neither team oversees the full lifecycle.
Unsettled capital treatment. Banks using the Advanced Measurement Approach for operational risk capital must decide if AI-related losses fit existing Basel event types or need new categories. This affects capital adequacy and regulatory reporting.
Fragmented regulatory expectations. SR 11-7 provides a model risk management framework. The EU AI Act outlines conformity requirements for high-risk AI systems. ISO/IEC 42001 offers an AI Management System structure. None specify where AI risk fits in your three lines of defense model.
What This Means for Your Team
As a Chief Risk Officer, your structural decision will shape your organization's AI risk posture for years. The wrong choice can create gaps where incidents slip through committee boundaries.
Distributed model. AI risk owned by business units works with mature risk cultures and strong central oversight. It fails if units lack AI expertise or need consistent risk tiering across the organization, making it hard to aggregate AI risk exposures enterprise-wide.
Centralized model. A standalone AI risk function provides clear accountability and consistent standards. It fails if the central team becomes a bottleneck or loses business context, risking a compliance theater where the AI risk team reviews documentation but never sees the system in production.
Hybrid model. AI risk distributed with strong central coordination is common but challenging. You need clear RACI matrices, regular cross-functional forums, and executives willing to enforce collaboration when territories collide.
Action Items by Priority
Immediate (next 30 days):
Map your current AI risk touchpoints across all three lines of defense. Document which teams review AI systems at development, validation, deployment, and monitoring stages. Identify gaps where no team has clear accountability. This isn't about creating the perfect structure; it's about knowing where your blind spots are today.
Near-term (next quarter):
Pilot a unified AI risk register that spans model risk, operational risk, and compliance. Include all AI systems subject to SR 11-7, EU AI Act high-risk classifications, or material business impact. Use consistent risk tiering criteria based on the NIST AI RMF or ISO/IEC 23894 contextual risk factors. Test whether your current committee structure can actually use this register to make decisions.
Define escalation paths for AI incidents that cross risk domains. When a customer-facing chatbot generates biased outputs, does that route through operational risk (customer complaint), model risk (model performance issue), or compliance (potential discrimination)? Write the decision tree before the incident happens.
Medium-term (next two quarters):
Align your AI risk taxonomy with your operational risk event classification. If you're using Basel II event types, document how AI-related losses map to existing categories. If existing categories don't fit, build the business case for new ones with your regulators.
Establish AI risk metrics that feed both operational risk reporting and AI-specific governance. Post-market monitoring results (EU AI Act Article 72) should inform your operational risk loss database. Model performance metrics from SR 11-7 ongoing monitoring should trigger operational risk event logging when thresholds breach.
Build competency across risk functions. Your operational risk team needs enough AI literacy to recognize when a technology incident is actually a model failure. Your model risk team needs enough operational risk knowledge to assess deployment controls and incident response procedures.
Strategic (next year):
Pressure-test your structure with a cross-functional AI incident simulation. Script a scenario where a General-Purpose AI Model with Systemic Risk (EU AI Act Article 51) that you've fine-tuned for credit decisioning produces unexpected outputs at scale. Which committee leads the response? Who makes the decision to take the system offline? Who owns the regulatory notification under both SR 11-7 and EU AI Act requirements?
This exercise will reveal whether your structural choices actually work under stress or just look good in org charts.
