Model Risk Management Checklist for AI Tools

What is MRM for AI?

Model risk management for AI applies familiar governance disciplines to newer tools: inventory, ownership, documentation, validation, change control, monitoring, challenge, remediation, and reporting. The challenge is that AI systems can be less transparent, more dependent on data quality, and more likely to change through vendor updates or retraining.

For financial institutions, the question is not whether a tool uses a fashionable label. The question is whether the tool produces outputs that influence decisions, controls, customer treatment, regulatory reporting, fraud detection, compliance monitoring, or operational resilience. If it does, the institution needs a defensible model risk view.

A checklist helps teams move from general concern to evidence. It turns 'we should review AI models' into concrete questions about inventory status, validation evidence, monitoring thresholds, explainability, data lineage, bias testing, and ownership.

SR 11-7, SR 26-2, and AI: what to know

Many institutions still use SR 11-7 language in model risk policies and validation procedures. Newer model risk guidance, including SR 26-2 and OCC Bulletin 2026-13, updates supervisory expectations for covered banking organizations while preserving the practical focus on governance, validation, monitoring, and documentation.

For AI governance work, that means legacy SR 11-7 mapping can remain useful, but new documentation should avoid treating SR 11-7 as the only current reference. A practical checklist should help teams translate older model-risk concepts into current policy language and current evidence expectations.

AI tools also create overlap between model risk and third-party risk. A vendor may control model design, training data, drift monitoring, retraining, and explainability. The institution still needs evidence that the tool is appropriate for its intended use and monitored after approval.

How to get started with AI MRM

Start with an inventory sweep. Ask business lines, IT, information security, compliance, vendor management, and analytics teams to identify AI-enabled tools and model-driven processes. Include tools that are embedded in vendor platforms, even when the vendor does not market them as standalone models.

Next, risk-tier each item. Customer-impacting, credit, fraud, AML, regulatory reporting, security, and critical operations use cases should receive deeper review than low-risk drafting or productivity use cases. The risk tier should drive validation depth, monitoring cadence, committee approval, and evidence retention.

Finally, convert gaps into remediation items. Missing documentation, incomplete vendor evidence, unclear ownership, absent monitoring thresholds, and stale validations should be tracked with owners and due dates. MRM improves when gaps become managed work, not informal observations.

The complete AI model risk checklist

These 20 items expand the model risk domain into practical evidence questions. Use them to screen AI tools, identify documentation gaps, and prioritize validation or monitoring work.

1. 1Is every AI tool or model-driven process captured in a centralized model or AI inventory?
2. 2Does each AI model have a named business owner and a named risk or control owner?
3. 3Has each model been risk-tiered based on use case, materiality, customer impact, and complexity?
4. 4Is the intended use documented, including limitations and prohibited uses?
5. 5Is validation evidence available before production use or material expansion?
6. 6Does validation cover conceptual soundness, data quality, performance, stability, and implementation?
7. 7Are explainability limits documented for customer-impacting or decision-support models?
8. 8Has the institution reviewed bias, disparate impact, complaint, and override indicators where relevant?
9. 9Are monitoring metrics, thresholds, escalation paths, and review cadence defined?
10. 10Does the process detect model drift, data drift, performance degradation, and unexpected outputs?
11. 11Are vendor-provided AI models supported by documentation, testing evidence, and change notifications?
12. 12Are model changes, retraining events, threshold changes, and vendor releases logged?
13. 13Are exceptions, validation findings, and monitoring breaches tracked to remediation?
14. 14Does reporting reach the right committee, management forum, or board body based on risk tier?
15. 15Are decommissioned models removed from production while retaining required documentation?
16. 16Does the inventory connect to vendor management, data governance, and information security records?
17. 17Are data sources, lineage, retention, and access controls documented?
18. 18Are challenger, benchmark, or reasonableness tests used where appropriate?
19. 19Are validation and monitoring performed by staff independent from model development where required?
20. 20Can audit or examiners trace a high-risk AI model from approval through ongoing monitoring evidence?

FAQ