When the OCC, FDIC, and Federal Reserve revised their model risk guidance on April 17, 2026, they excluded generative and agentic AI from its scope. This shift places the responsibility on your team to govern these tools through an internal framework.
If you're using AI for transaction monitoring, regulatory change tracking, or control testing, you need documentation detailing the tool's operation, risks, and failure detection methods. This template provides that structure.
Purpose of the Template
This governance framework template is designed for AI compliance monitoring tools outside traditional model risk management guidance. Use it for:
- Alert triage systems that auto-close suspicious activity alerts
- Retrieval-grounded regulatory change trackers
- Agentic tools executing multi-step compliance workflows
- Evidence collection systems for control attestation
The template establishes internal governance where regulatory guidance ends. It documents the tool's purpose, operational boundaries, risk controls, and validation approach in a format your audit committee and examiners can review.
Prerequisites
Before customizing this template, ensure you have:
Technical documentation from the vendor: Details on model training, data usage, and output generation. Without this, you can't govern the tool.
A designated owner: Someone accountable for the tool's performance, typically a compliance officer or risk manager familiar with both regulatory obligations and technology.
Access to production logs: Review actual output, not just test results. If the tool doesn't log decisions or reasoning, add this requirement before deployment.
Baseline performance metrics: Define expected accuracy, false positive rate, or coverage percentage. You can't validate what you haven't defined.
The Template
AI [Integrated Risk Management (IRM) Platform](/glossary/integrated-risk-management-irm-platform) Governance Framework
[Tool Name]
Version [X.X] | Effective [Date]
1. TOOL DESCRIPTION AND SCOPE
1.1 Purpose
This tool performs [specific compliance function] by [brief technical description].
It supports compliance with [list regulatory obligations].
1.2 Technology Classification
☐ Generative AI (produces text, summaries, or recommendations)
☐ Agentic AI (executes multi-step workflows)
☐ Traditional ML (statistical model within SR 26-2 scope)
1.3 Operational Boundaries
The tool IS authorized to: [list permitted actions]
The tool is NOT authorized to: [list prohibited actions]
Human review is REQUIRED for: [list escalation triggers]
2. RISK ASSESSMENT
2.1 Identified Risks
- Unauthorized actions: [describe how tool could exceed boundaries]
- Goal misalignment: [describe how tool could optimize for wrong outcome]
- Erroneous output: [describe how inaccurate results could affect compliance]
- Data quality degradation: [describe dependency on input data]
- Threshold drift: [describe how parameters could become miscalibrated]
2.2 Risk Mitigations
For each risk above, document:
- Preventive control: [what stops the risk from occurring]
- Detective control: [how you'll identify when it occurs]
- Corrective action: [what you'll do when it occurs]
3. VALIDATION AND MONITORING
3.1 Pre-Deployment Validation
☐ Output accuracy tested against [benchmark or sample size]
☐ Bias assessment completed for [protected classes or risk factors]
☐ Retrieval grounding verified (for regulatory change tools)
☐ Alert disposition logic reviewed (for transaction monitoring)
☐ Escalation triggers tested under [scenario conditions]
3.2 Ongoing Monitoring
Metric: [specific measurement]
Frequency: [daily/weekly/monthly]
Threshold: [acceptable range]
Owner: [role responsible for review]
Escalation: [who receives alert when threshold breached]
Examples:
- Alert auto-closure rate: Weekly review by [Compliance Officer]. Escalate if >X%.
- False positive rate: Monthly review by [Risk Manager]. Escalate if >Y%.
- Retrieval citation accuracy: Quarterly sample of Z citations by [Legal].
3.3 Model Retraining or Recalibration
Trigger: [what event requires retuning]
Process: [who authorizes, how changes are tested, approval requirements]
Documentation: [what records are maintained]
4. VENDOR OVERSIGHT (if applicable)
4.1 Vendor Controls
☐ Vendor provides model documentation and change logs
☐ Vendor notifies institution before model updates
☐ Vendor maintains SOC 2 Type II or equivalent certification
☐ Contract includes right to audit and data portability
4.2 Vendor Performance Review
Frequency: [quarterly/annually]
Metrics: [uptime, accuracy, support response time]
Owner: [Third-Party Risk Manager]
5. GOVERNANCE AND ACCOUNTABILITY
5.1 Roles and Responsibilities
Tool Owner: [Name, Title], accountable for tool performance and risk
Technical Administrator: [Name, Title], manages configuration and access
Validator: [Name, Title], conducts ongoing monitoring reviews
Escalation Authority: [Name, Title], approves exceptions and remediation
5.2 Reporting
Frequency: [quarterly to Audit Committee, monthly to Risk Committee]
Content: Performance metrics, incidents, remediation status, planned changes
5.3 Annual Review
This framework will be reviewed annually and updated when:
- The tool's functionality changes materially
- Regulatory guidance affecting the tool is issued
- Validation reveals persistent control deficiencies
- An incident exposes a gap in governance
6. INCIDENT RESPONSE
6.1 Incident Definition
An incident occurs when: [define threshold, e.g., auto-closure rate exceeds X%,
false negative identified in examiner sample, unauthorized action executed]
6.2 Incident Workflow
1. [Tool Owner] documents incident in [Issues Management system]
2. [Validator] conducts root cause analysis within [X business days]
3. [Escalation Authority] approves remediation plan
4. [Tool Owner] implements corrective action and validates effectiveness
5. [Risk Committee] receives incident summary at next meeting
7. DOCUMENTATION AND RECORDS
Maintained records:
☐ Vendor contracts and SLAs
☐ Model documentation and training data descriptions
☐ Validation test results (pre-deployment and ongoing)
☐ Monitoring reports and metric logs
☐ Incident reports and remediation plans
☐ Annual governance framework reviews
Retention period: [X years, aligned with record retention policy]
Storage location: [system or repository]
Customizing the Template
Section 1.2: Check the box that matches your tool's technology. If it's generative or agentic, you're outside SR 26-2 scope and this framework is your only documented governance. If it's traditional ML, comply with the interagency guidance as well.
Section 1.3: Define operational boundaries clearly. For an alert triage system, specify conditions for auto-closing alerts versus escalating to a human. The OCC's April 24, 2026 consent order against Community Federal Savings Bank highlighted deficiencies in auto-closure logic. Your boundaries prevent such outcomes.
Section 3.2: Specify monitoring metrics. For retrieval-grounded regulatory change tracking, measure citation accuracy by sampling actual retrievals quarterly. For transaction monitoring, track false positive and false negative rates monthly. The Financial Stability Board's June 2026 report notes that real-time monitoring of agentic tools is impractical, so use detective controls to catch errors post-factum.
Section 4: If your tool is vendor-provided, include contract language requiring notification before model updates. You can't validate a tool that changes without your knowledge.
Section 6.1: Precisely define "incident". A single missed alert isn't necessarily an incident; a pattern of auto-closures above your threshold is. Calibrate this to your institution's risk appetite.
Validation Steps
After customizing the template:
1. Test escalation triggers: Run scenarios that should force human review. Confirm the tool escalates as expected.
2. Verify monitoring metrics are measurable: If you can't pull data to calculate a metric, revise the metric or fix your logging.
3. Conduct a tabletop exercise: Walk through an incident with the roles listed in Section 5.1. Identify gaps in authority or communication paths.
4. Present to your audit committee: They'll want to see documented governance for tools outside regulatory guidance. This template provides that assurance.
5. Schedule the first monitoring review: Don't wait for the defined frequency. Run the first review within 30 days of deployment to confirm your metrics and thresholds are realistic.
The revised model risk guidance didn't remove your governance obligation. It made your internal framework the only control that matters. This template ensures that framework exists before an examiner asks for it.
