Give AI an accountable operating model
A useful AI program needs clear ownership and controls. They need an operating model that defines who approves use cases, who challenges model design, how monitoring is performed, what evidence is retained, and how leadership stays informed when model risk begins to move.
This executive briefing outlines a practical governance structure for community and regional banks adopting AI across underwriting, fraud operations, marketing, collections, customer engagement, and internal productivity workflows.
Scope the rules before designing the controls
SR 26-2 replaced SR 11-7 and SR 21-8 on April 17, 2026. It is expected to be most relevant above $30 billion in assets; generative and agentic AI are outside its scope. Broader AI governance still needs to address those uses.
Read the Federal Reserve guidanceDecision rights and accountability
Effective AI governance in banking requires clearly assigned ownership across the three lines of defense and executive leadership:
- Board and executive committee: Approve risk appetite, escalation thresholds, and strategic direction.
- Business owners: Own use-case outcomes, operating risk, and control compliance in production.
- Model risk / validation: Independently challenge design, assumptions, testing, and performance.
- Compliance and legal: Assess fair lending, UDAAP, privacy, record retention, and disclosure requirements.
- Technology and data teams: Manage infrastructure, access, data lineage, resiliency, and change control.
- Internal audit: Evaluate whether the operating model is functioning as designed.
A defensible AI governance model should map directly to existing banking control expectations rather than treating AI as a separate universe. That includes model risk management principles, change management, third-party oversight, complaint monitoring, fair lending review, access governance, issue management, and board reporting.
Examiners increasingly expect institutions to explain where AI is being used, why it was approved, what data it relies on, how outcomes are monitored, what overrides occur, and how leadership would know when intervention is required.
Risk and control boundaries
- Weak input controls can create silent decisioning errors across credit, fraud, or servicing workflows.
- Poor prompt or feature governance can produce inconsistent outputs and unapproved business logic drift.
- Insufficient explainability can complicate adverse action notices, complaint handling, and examiner review.
- Bias and segmentation errors can create fair lending, UDAAP, or reputational exposure.
- Inadequate override tracking can hide breakdowns between policy, model recommendations, and final decisions.
In addition to traditional model controls, banks should define standards for training data provenance, drift detection, version control, prompt management, output review, human-in-the-loop requirements, vendor attestations, and production monitoring for accuracy, fairness, latency, override frequency, and unusual behavior.
Implementation and ongoing challenge
- Use-case intake and tiering: Formal approval workflow before development or procurement.
- Policy framework: AI policy, model standards, validation standards, monitoring standards, and exception management.
- Model and AI inventory: Complete registry of systems, owners, vendors, datasets, versions, and control status.
- Independent review: Validation and effective challenge appropriate to use-case materiality.
- Production monitoring: Outcome testing, drift alerts, fairness review, override analysis, and incident escalation.
- Change governance: Retraining, prompt changes, feature changes, vendor updates, and release approvals.
- Management reporting: KRIs, KPI trends, issue aging, validation status, and board-level summaries.
- Documentation and evidence: Decision logs, review memos, committee records, test artifacts, and audit trail retention.
Banks often struggle with fragmented ownership, inconsistent documentation, weak inventory discipline, unclear approval authorities, and overreliance on vendors for evidence. Another common issue is treating governance as a one-time approval instead of a continuous operating discipline.
- Create an AI governance committee with clear authority and escalation rights.
- Define materiality thresholds that determine validation depth and board reporting cadence.
- Standardize templates for use-case approval, model cards, testing summaries, and exceptions.
- Track both performance metrics and risk indicators, not just business ROI.
- Require evidence packages that can support internal audit and examiner review without rework.
Validation should test conceptual soundness, implementation integrity, performance stability, limitations, and outcome reasonableness. After deployment, continuous monitoring should assess data drift, outcome drift, fairness signals, overrides, customer complaints, issue recurrence, and change activity.
Explore Cicrim’s SR 26-2 governance approach for AI, analytics, and decisioning programs.
Use the operating model and roadmap
The operating model defines ownership, lifecycle gates, monitoring and evidence. The roadmap adds a phased delivery plan, readiness gates and a working backlog structure.