OCC AI Controls Mapping for Bank Model-Risk Governance
This OCC model risk AI controls mapping connects the current 2026 interagency guidance to control objectives and bank owners; repeatable tests and retained evidence; gaps and retests. It keeps the scope boundary explicit: OCC Bulletin 2026-13 excludes generative and agentic AI models, so a bank applying these disciplines to an LLM must anchor that decision in its own policy or another applicable source.

A control map with AI governance in the requirement column and dashboard in the evidence column tells an examiner almost nothing. Useful OCC model risk AI controls mapping names the current source and objective; the control point and owner; the test and retained artifact; the open gap and retest. OCC Bulletin 2026-13 makes one boundary decisive: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." I would leave an LLM row red until the map identifies the bank policy that places it under model-risk disciplines.
TL;DR
- Start every row with its governing source and applicability rationale. OCC Bulletin 2026-13 replaced Bulletin 2011-12 on April 17, 2026.
- Preserve the exact exclusion: generative AI and agentic AI models fall outside the revised guidance's scope.
- Map principles to a bank control point and accountable owner; a repeatable test and retained evidence; the gap and retest state.
- Give an HTTP gateway credit only for policy decisions and records on routed traffic. Validation and outcomes analysis remain with bank owners, together with governance and third-party accountability.
Source and scope govern every row
OCC Bulletin 2026-13 issued revised interagency guidance on April 17, 2026. Four OCC source documents were rescinded by this issuance. They include Bulletin 2011-12 and the Model Risk Management booklet. The other two are the 1997 credit-scoring issuance and the 2021 BSA/AML statement. The matching Federal Reserve SR 26-2 letter superseded SR 11-7 and SR 21-8.
The guidance addresses model development and use together with validation and monitoring. It also addresses governance and controls together with vendor or other third-party products. It applies a risk-based approach and sets neither enforceable standards nor prescriptive requirements. It is expected to be most relevant to banking organizations above $30 billion in total assets, with possible relevance to smaller banks that carry significant exposure to model risk.
Put those facts in the map. For an LLM or agentic system, add the explicit exclusion and cite the bank policy or separate authority used to assign controls. A source cell containing OCC AI rule fails the scope test.
Development and use map to an approved operating baseline
Requirement and objective: the revised guidance describes sound principles for effective model development and model use, including testing. The objective is a documented system whose purpose and design; data and assumptions; limitations and implementation match its approved use.
Control point: use-case approval with development review, followed by production release authorization.
Owner: the business sponsor owns purpose and reliance. Development supplies design evidence, and data owners control lineage and suitability. Independent functions named by bank policy review the risk and release decision.
Test and evidence: trace one production system through approved purpose and requirements; dependencies and test results; limitations and approval; deployed configuration. Retain the use-case record and architecture; lineage and model or endpoint identifier; prompt and retrieval versions where applicable; unresolved findings and signed release manifest. AI model inventory management provides the join identifiers.
Gap and retest: flag moving aliases and missing intended-use limits. Also flag generic vendor benchmarks and production features absent from test. Retest the deployed configuration after remediation.
Validation maps to qualified challenge and independent conclusions
Requirement and objective: the 2026 guidance discusses model validation and monitoring, including conceptual soundness and outcomes analysis. The objective is effective challenge that fits the model's purpose and materiality, together with its complexity and actual risk.
Control point: validation plan approval and validation conclusion, followed by issue acceptance before use or continued use.
Owner: the bank's assigned validation function owns the conclusion and independence. Development supplies reproducible materials. Business and governance owners decide use restrictions and remediation under policy.
Test and evidence: reproduce selected tests and challenge assumptions and limitations. Inspect implementation and review outcomes tied to approved use. Retain validator qualifications and independence; scope and data; environment and procedures; actual results and findings; management responses and restrictions; approval and retest.
Gap and retest: a model card and provider assurance packet can inform validation, as can a successful demonstration. Each leaves the bank's configured use unchallenged. For generative and agentic AI, label this row as a bank-policy mapping because Bulletin 2026-13 excludes those models from direct scope.
Monitoring maps to populations, thresholds, and governance action
Requirement and objective: ongoing monitoring should identify performance deterioration and changes in use, plus other conditions that alter model risk. The objective is a timely, evidence-backed decision about continued use and restriction, together with remediation or retirement.
Control point: monitoring job and threshold review; escalation and periodic governance decision.
Owner: model or AI oversight maintains the plan. Business outcome owners interpret operational effect. Independent review and internal audit retain their assigned roles.
Test and evidence: freeze the source population and reconcile it to routes and business records. Execute approved measures and select samples under a documented method. Preserve thresholds and alerts; reviewed cases and trends; exceptions and management decisions; follow-up tests. A fraud-support use can connect selected outputs to analyst dispositions; summarization review can assess unsupported statements and restricted-data handling.
Gap and retest: mark the row partial when the dashboard lacks a denominator or configuration version; sampling method or outcome link; decision owner. Retest after the source population and review path can be reproduced.
Governance maps to decisions, challenge, and issue closure
Requirement and objective: the guidance discusses clear policies and roles; responsibilities and documentation; model inventory and issue management; internal audit. The objective is visible accountability and a continuous record of challenge plus management action.
Control point: policy approval and inventory attestation; committee decision and exception approval; independent audit.
Owner: the board and senior management hold the responsibilities assigned by the bank's governance structure. Model-risk leadership maintains policy. Business and control owners operate it. Internal audit evaluates the rigor and effectiveness of practices and policy implementation where it participates in the program.
Test and evidence: select an inventory entry and policy exception, plus a validation recommendation and monitoring breach. Follow each through owner and due date; management response and remediation or risk acceptance; independent retest and closure. Preserve decisions beside source evidence. A red folder tab with the original missed date should remain visible after closure.
Gap and retest: reopened issues and overwritten due dates weaken the row. So do self-approved exceptions and inventory entries lacking actual routes. Retest the original failure condition and preserve both results.
Change control maps versions to impact and deployment
Requirement and objective: the bank needs a controlled history as models and data; use and implementation; provider dependencies change. The objective is an impact decision before risk enters production, supported by testing and rollback capability.
Control point: change intake and impact assessment; release authorization and post-change monitoring.
Owner: development or platform teams identify technical changes. The business owner assesses use impact. Validation and risk functions participate according to bank policy, together with security and legal, plus compliance functions. Release management controls deployment.
Test and evidence: trace a model or endpoint change through notification and impact assessment; validation scope and review; approval and deployment time; rollback target and post-release result. Inventory prompt and retrieval changes, plus policy and application changes that can alter behavior or exposure.
Gap and retest: provider changes behind a stable API alias and emergency releases outside normal approval create version ambiguity. So do prompt edits absent from release records. The tamper-evident audit log guide explains integrity for request events; bank change records must supply the approval and impact conclusion.
Third-party controls map contracts to actual production use
Requirement and objective: the revised guidance addresses vendor and other third-party products, including validation considerations. The objective is enough bank-owned understanding and challenge, together with monitoring and contingency planning for the exposure created by the external product.
Control point: due diligence and contract approval; service-change intake and performance review; incident response and exit execution.
Owner: third-party risk management coordinates the relationship. The business owns use and dependency. Procurement and legal control terms. Security and compliance functions own their assigned assessments, together with model-risk and continuity, plus records functions.
Test and evidence: reconcile contracted services to production endpoints. Retrieve due diligence and responsibilities; data handling and model-change notice; incident terms and assurance reports; performance reviews and relevant subcontractor information; remediation and continuity; exit evidence. The OCC's third-party relationships bulletin covers planning and due diligence; contracting and monitoring; termination.
Gap and retest: provider documentation supports oversight but cannot prove the bank used the service only for approved purposes. Retest after contract scope agrees with both route inventory and production population.
Routed HTTP decisions map to a narrow evidence control
Requirement and objective: enforce bank-approved identity and workflow policy, together with content and destination policy, on authenticated HTTP traffic routed to an LLM. Retain an attributable event that joins to use and change; monitoring and exception; provider records. This is an implementation mapping under bank policy, rather than a claim that OCC Bulletin 2026-13 prescribes an AI gateway.
Control point: the HTTP policy decision point between a bank-controlled application or agent and an approved LLM endpoint.
Owner: the application owner supplies authenticated identity and purpose. Security engineering owns routed policy and egress. Records owners set retention rules and retrieval access. Business and model-risk functions own the conclusions made with the evidence, together with compliance and audit functions.
Test and evidence: send permit and deny cases; restricted-content and missing-identity cases; disallowed-destination and response-policy cases. Preserve principal and workflow; endpoint and model identifier where available; classification and policy version; decision and UTC time; response disposition and correlation ID; signature and protected export. AI audit log chain of custody gives the custody pattern.
Gap and retest: direct browser use and local inference sit outside this control point, together with embedded vendor AI and bypass routes. Stolen credentials also sit outside this control point. Assign each gap to its actual owner and rerun the route test after remediation.
DeepInspect
DeepInspect sits inline on HTTP AI traffic deliberately routed between bank-controlled applications or agents and LLM endpoints. It evaluates application-supplied identity and workflow context against versioned content and destination policy, inspects responses, and writes a signed, tamper-evident event containing the active policy version and decision, together with the timestamp.
In this map, DeepInspect can serve as the routed HTTP policy point and provide selected request evidence for joins into inventory and changes; exceptions and monitoring; provider oversight. The bank retains responsibility for identity proofing and route completeness; model-risk scope and development and use; validation and outcomes analysis; governance and issue closure; third-party decisions and retention; independent audit. Local inference and browser-direct use need controls at their actual boundaries, together with embedded vendor AI and bypass traffic. Book a demo today.
Frequently asked questions
- Does this mapping make OCC Bulletin 2026-13 apply to LLMs?
No. The bulletin's exact statement controls: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." The map shows how a bank may apply selected disciplines through its own policy or another applicable source. Every LLM row should retain that attribution.
- Can one control support several mapped principles?
Yes. A frozen production population can support inventory reconciliation and monitoring, together with change review and audit sampling. Keep separate objectives and owners, plus expected results and conclusions, so distinct decisions retain their own status.
- What makes a controls-mapping test repeatable?
A second qualified reviewer can execute it using the recorded population and configuration; input and procedure; expected result and evidence location. Retain the tester and date, plus actual result and issue, followed by the retest.
- How should partial coverage appear?
Name the uncovered route and system; population and period; evidence join. Record an owner and interim measure, plus target date and retest. A single coverage percentage hides the difference between one missing signature and an application that bypasses the control point entirely.
- Does routed request evidence prove model validation?
It proves the recorded decision for traffic that crossed the HTTP policy point. Validation needs qualified challenge of the model or system within the bank-defined scope. Outcomes analysis and business disposition; customer impact and conceptual soundness; route completeness and provider oversight require separate evidence and owners.