A bank’s AI review should start with the proposed use: who relies on the output, what action it informs and what harm an error could cause. Classifying every language-model workflow under an outdated rule obscures those questions and can produce the wrong control design.
Start with the current regulatory position
OCC Bulletin 2026-13 and Federal Reserve SR 26-2 replaced the earlier SR 11-7 framework. The revised guidance excludes generative and agentic AI models from its scope. This does not remove the need for institution-specific governance. The institution’s risk and legal teams should determine the applicable obligations and control framework for each use, including any traditional models embedded in a broader workflow. OCC Bulletin 2026-13.
Classify the use before choosing controls
A document summary used by an analyst differs from a system that changes an account or influences a lending decision. Document the audience, permitted actions, data sensitivity and consequences of error. Identify any existing approval process the AI will support. The classification should be understandable to operations staff and should change when the scope or authority changes.
Validate the behavior the bank will rely on
Prepare cases with expected outputs and documented review criteria. Test incomplete evidence, conflicting sources, inappropriate requests and unavailable tools. Separate correctness, source support and action permissions in the results. A single average score can conceal an unacceptable error in a critical category. Keep the exceptions visible to the approver.
Use a workflow record that crosses team boundaries
For an analyst drafting a credit memo, document the approved sources, the sections Claude may prepare and the analysis the officer must perform independently. The record should distinguish extraction of a financial value from an interpretation of its significance. If a traditional risk score is also used, its provenance and validation sit alongside the language-model workflow rather than disappearing into it.
Ask the business owner and risk reviewer to agree how material corrections will be classified. A formatting edit is not the same as an unsupported financial statement. Keeping those categories separate makes the release discussion more precise and prevents a large volume of minor successful tasks from masking a consequential failure.
Treat changes as release decisions
A new model, prompt, retrieval configuration or connected tool can alter behavior. Record the proposed change, compare performance on the same cases, and obtain approval at a level appropriate to the impact. Keep a recoverable prior configuration. Monitoring should identify whether live cases differ from the accepted test set and who will investigate that difference.
Before the next decision
Planning checklist
- Documented use and applicability assessment
- Business owner, risk owner and independent challenge
- Behavioral tests with critical errors separated
- Controlled releases and recoverable configuration
Sources and further reading
- OCC Bulletin 2026-13: revised model-risk guidance
- Federal Reserve SR 26-2: revised model-risk guidance
Sources checked 5 October 2026. The design recommendations in this guide are AID’s analysis. Sector obligations depend on the use case and jurisdiction.
Apply this to a defined workflow
AID can structure an implementation and its evidence for review by the institution’s own risk and approval teams.
