Questions about AI accountability are increasingly common. Last week, three model risk managers asked me, "Should we own this?" after their organizations announced AI initiatives. The anxiety is real: AI systems don't fit neatly into existing model risk frameworks, yet someone needs to be accountable when things go wrong.
Lloyds Banking Group has made a clear decision. They've assigned their model risk office ultimate responsibility for AI system roll-out. Suzanne Brink, the bank's head of responsible AI, stated, "We have true accountability with our second line, in the model risk office."
This decision raises practical questions for others. Here's what I'm hearing from practitioners trying to figure out where AI risk should sit.
Does the model risk office make sense for AI governance?
Yes, if you're dealing with AI systems that make predictions or decisions based on data. Your model risk office already validates statistical models under SR 11-7. They understand data quality, performance monitoring, and the three-line defense structure. Extending that mandate to machine learning models is a natural fit.
The advantage is not creating a parallel governance structure. Your second line already knows how to challenge model assumptions, review validation evidence, and escalate material findings. They speak the language of risk appetite, materiality thresholds, and audit readiness.
The catch is that traditional model validation focuses on statistical properties. AI systems, especially those using foundation models or generative components, introduce risks your model risk office may not have encountered yet, like prompt injection and hallucination rates. These don't map cleanly to SR 11-7's framework.
You'll need to build new capabilities, but you're building them inside a team that already has accountability experience.
What if we don't have a mature model risk function yet?
Centralizing AI risk in an immature function is a mistake. I've seen organizations assign AI governance to a two-person model validation team that's already overwhelmed. That's not accountability; that's abdication.
If your model risk office can't keep up with traditional model inventory, adding AI systems will break it. In that case, establish a dedicated AI risk function that reports into the same second-line structure. Give them clear scope: AI system inventory, risk tiering, validation standards, and escalation protocols.
Run it in parallel until your model risk office has capacity. Then consolidate. The goal is accountability, not organizational elegance.
How do you assign accountability without creating turf wars?
Define scope in writing. Not "the model risk office oversees AI" but "the model risk office approves AI systems for production deployment and maintains ongoing monitoring for model performance drift and fairness metrics."
Be specific about handoffs. Your first line (the AI development team or business unit) owns model development, testing, and documentation. Your second line (model risk office) owns independent validation and approval. Your third line (internal audit) tests whether the first two lines are doing their jobs.
Document who approves what. At Lloyds, the model risk office has "ultimate responsibility" for roll-out. That likely means they hold go/no-go authority. If your CISO also needs to sign off on AI systems that process sensitive data, write down the sequence: model risk approves the model, CISO approves the deployment architecture, both signatures required before production.
Turf wars happen when accountability is vague. "We're all responsible for AI risk" means no one is.
What changes in your model risk framework to accommodate AI?
Start with risk tiering. Your existing framework probably tiers models by financial impact, regulatory importance, and complexity. Add AI-specific factors: training data provenance, explainability constraints, user-facing vs. internal, potential for bias amplification.
Update your validation standards. SR 11-7's three pillars still apply, but you need AI-specific tests. For conceptual soundness: review training data lineage, check for prohibited data sources, assess alignment with intended use. For ongoing monitoring: track drift in both input distributions and output quality, monitor for adversarial inputs, measure fairness metrics across demographic groups. For outcomes analysis: compare AI system decisions to human expert judgments, track override rates, investigate outlier predictions.
Expand your documentation requirements. Model cards work for simple classifiers. For systems using foundation models, you need technical documentation that maps to EU AI Act Annex IV even if you're not EU-regulated: intended purpose, training data characteristics, performance metrics, known limitations, human oversight measures.
Should we wait for clearer regulatory guidance before centralizing accountability?
No. Regulatory clarity is coming, but it won't arrive faster than your AI deployments. The EU AI Act is in force. ISO/IEC 42001 provides a management system framework you can implement now. NIST AI RMF gives you a risk-tiering structure.
Centralizing accountability doesn't mean you've figured out every validation test. It means you've established who decides when an AI system is ready for production, who monitors it post-deployment, and who gets called when it fails.
Lloyds made that call. Their model risk office now owns AI roll-out decisions. That's not a perfect framework, but it's a clear one. When their board asks "Who approved this AI system?" there's an answer.
What's the biggest mistake organizations make when assigning AI accountability?
Assigning it to a committee. I've seen "AI Governance Councils" with representatives from risk, compliance, legal, IT, and the business. Everyone attends meetings. No one can say no to a deployment.
Committees advise. Accountability requires a single function with approval authority. That function consults the committee, but when the decision gets made, one name goes on the approval form.
The second biggest mistake: assigning accountability without resourcing. If your model risk office now owns AI systems but you haven't added headcount, budget, or training, you've created accountability theater. Real accountability means the team has capacity to review systems before deployment, not just discover problems in the post-mortem.
Where do I go from here?
Map your current state. List every AI system in production or development. For each one, write down who approved it for deployment and who monitors it now. If you can't name specific people, you've found your accountability gap.
Draft a responsibility matrix. Use RACI or a similar framework. For each AI lifecycle stage (development, validation, approval, deployment, monitoring, incident response), assign Responsible, Accountable, Consulted, and Informed roles. The Accountable role should be singular.
Pilot with one high-risk system. Pick an AI application that matters but isn't business-critical. Run it through your proposed accountability structure. Document what works and what breaks. Iterate.
The goal isn't a perfect framework. It's a clear answer to "Who owns this?" when your CEO asks.
