Does OCC Bulletin 2026-13 directly govern generative AI models?

The bulletin states the exclusion exactly: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." A bank can still decide that model-risk disciplines are appropriate for an LLM under its own governance practices. The checklist must attribute those controls to bank policy or another applicable source.

Is OCC Bulletin 2026-13 a binding regulation?

The OCC says the revised guidance sets neither enforceable standards nor prescriptive requirements, and noncompliance with the guidance will not result in supervisory criticism. Applicable laws and regulations can create separate duties. The same applies to orders and bank policy, along with other supervisory sources. Record each control's actual source.

Which banks are the main audience for the revised guidance?

The bulletin says the guidance is expected to be most relevant to banking organizations with more than $30 billion in total assets. It can also be relevant below that threshold when a bank has significant model-risk exposure due to model prevalence or complexity, or activity outside traditional community banking. The applicability memo should use the bank's facts.

Does passing the eight checks validate an LLM?

The checklist organizes evidence and exposes gaps. Validation requires the qualified function assigned by bank policy, with scope and depth based on the system's purpose and risk. A passed route test proves a named policy decision for traffic crossing that route. It supplies no conceptual-soundness or output-accuracy conclusion. It also supplies no customer-outcome or whole-system conclusion.

How often should the checklist run?

Set cadence through the bank's risk-based policy and control design. Trigger a rerun after material model and endpoint changes. The same applies to prompt and retrieval changes, plus changes to use and data. Provider and monitoring changes also trigger a rerun. Also rerun after significant incidents and unresolved reconciliation differences. Preserve each prior result so reviewers can see control operation through time.

OCC AI Compliance Checklist for Bank Model-Risk Governance

A spreadsheet row marked SR 11-7 compliant is stale before the examiner opens the supporting folder. OCC Bulletin 2026-13 replaced the 2011 model-risk source on April 17, 2026. Its scope contains a sharper issue for LLM programs. The bulletin says, exactly: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." This OCC model risk AI compliance checklist starts there. I would reject any checklist that silently turns familiar model-risk practice into an OCC requirement for excluded systems.

TL;DR

Grade eight checks. Mark each result as pass or out of scope. Use remediate for the remaining result state. Preserve the owner, test date, evidence, and retest state for each result.
Use OCC Bulletin 2026-13 and Federal Reserve SR 26-2 as the current sources. The revised guidance replaced the 2011 issuances.
Record the exact exclusion: generative AI and agentic AI models are outside the revised guidance's scope.
A bank may apply model-risk disciplines to an LLM through its own policy. Label that source correctly and keep gateway evidence limited to routed HTTP decisions.

Check 1: cite the current source and define scope

Owner: model-risk governance with legal and compliance review.

Pass condition: the policy and workpaper cite OCC Bulletin 2026-13, dated April 17, 2026. They record that the bulletin rescinded OCC Bulletin 2011-12 and several related OCC issuances. The bank also records the bulletin's nonprescriptive status and the exact GenAI and agentic AI exclusion.

Evidence: approved applicability memo and policy source register, plus the affected-procedure list and governance approval. Identify the bank-owned policy or other authority that brings an excluded AI system into review. Keep the model-risk source separate from privacy, consumer-compliance, cybersecurity, records, and third-party sources.

Remediate when: a checklist presents SR 11-7 or OCC Bulletin 2011-12 as current. Also remediate when it quotes a 2026 model-risk principle as a direct GenAI requirement or leaves the policy basis blank.

Check 2: approve the use case before production

Owner: business sponsor with the bank's assigned risk review functions.

Pass condition: each AI use has an approved purpose and accountable owner. It identifies intended users and the business process, along with data classes and the provider route. It also records the output reliance level and human-review rule. Prohibited uses are included. The approval names any customer or prudential impact and sets monitoring plus reassessment triggers.

Evidence: use-case intake and risk assessment, plus legal and compliance reviews. Include the security assessment and approval record. Preserve the current operating procedure, system diagram, and decision rights. A printed approval page beside a monitor should show the same provider endpoint and workflow name visible in the production route inventory.

Remediate when: one enterprise chatbot approval covers credit analysis, complaint summaries, fraud investigation, and code assistance without separate impact analysis. Use AI model inventory management to connect the approved use to its model and provider dependencies.

Check 3: reconcile inventory to actual routes

Owner: AI platform engineering with model-risk inventory oversight.

Pass condition: the approved inventory agrees with deployment records, provider accounts, application egress, and the routed request population for the review period. Each active use resolves to an owner and endpoint. Record the model identifier where available, plus the workflow and data classification. Include the policy version.

Evidence: frozen inventory export and route inventory, plus provider usage or billing and API-management records. Preserve deployment manifests and IAM principals. Include the reconciliation query and row counts, along with differences and investigation tickets. Preserve the extraction time and schema version.

Remediate when: provider usage contains an endpoint absent from the inventory or applications can call around the approved policy point. Also remediate when a shared service identity hides the acting person or agent. The post-authentication gap explains why application-supplied identity and workflow context matter after login.

Check 4: preserve development and validation evidence

Owner: model development and use owners, with validation performed under the bank's independence rules.

Pass condition: for systems the bank places under model-risk policy, the file connects purpose and theory to data and assumptions. It records limitations and testing, plus implementation and acceptance. Validation addresses conceptual soundness and outcomes analysis where appropriate, along with ongoing monitoring. Scope and depth follow risk and actual use.

Evidence: development documentation and data lineage, plus the test plan and actual results. Include limitations and the issue log. Preserve the validation report and management response, along with the approval and deployment manifest. Provider materials can support the file. The bank's configured use and reliance still need a bank-owned conclusion.

Remediate when: a model card substitutes for use-specific testing or latest replaces a reproducible version. Also remediate when the validator receives only successful examples selected by the development team. The Federal Reserve's SR 26-2 letter confirms that the revised interagency guidance superseded SR 11-7 and emphasizes a risk-based approach.

Check 5: test monitoring against defined populations

Owner: model or AI oversight with business outcome owners.

Pass condition: the monitoring plan names its source population and cadence. It records thresholds and the sample method, plus the reviewer and escalation path. Include the governance response. Measures match the approved use. A summarization workflow may assess unsupported statements and restricted-data handling. A decision-support use may require adjudicated outcome analysis.

Evidence: population query and completeness reconciliation, plus selected samples and monitoring output. Preserve the exception list and trend review, along with the management decision and follow-up test. The selected set should include denied and changed requests where they inform the control objective.

Remediate when: a dashboard shows aggregate provider usage but omits the denominator, sample-selection method, active configuration, or business outcome. Monitoring evidence should tell a reviewer which population was tested and what management did with the result.

Check 6: connect changes and exceptions to approval

Owner: change management with the accountable business and risk owners.

Pass condition: changes to the model and endpoint enter an impact assessment before deployment. The same applies to the system prompt and retrieval source, as well as the application and policy. Monitoring threshold changes also enter the assessment. Approved exceptions have an owner and rationale. They include a compensating control and expiry, plus a usage record and closure authority.

Evidence: change ticket and impact assessment, plus testing and approval. Preserve the deployment event and rollback plan. Include post-release monitoring and the exception register, along with use history and the expiry action. Preserve the independent retest. Preserve the old state inside the change record. A closed issue should retain the failed test that opened it.

Remediate when: provider release notes arrive after production changed or emergency work stays outside retrospective approval. Also remediate when exceptions renew automatically. I prefer a visible overdue exception to a green score assembled by deleting the original failure.

Check 7: test third-party control through the relationship lifecycle

Owner: third-party risk management with the business and security functions, plus the legal and model-risk functions assigned by policy.

Pass condition: due diligence and contract terms match the provider's role and risk. Ongoing oversight covers approved services and data handling. It addresses model changes and performance, plus incidents and subcontractors where relevant. It also covers evidence access and concentration, along with continuity and exit.

Evidence: due-diligence assessment and the contract and responsibility matrix. Include assurance reports and service reviews, plus incident records and change notices. Preserve remediation and board or committee reporting where required. Include the exit test. The OCC's 2023 third-party risk bulletin describes a continuous risk-management life cycle for third-party relationships.

Remediate when: a SOC report becomes the entire oversight file or the contract covers a provider while production uses an unlisted service. Also remediate when model-version notice lacks an operational recipient and impact workflow.

Check 8: prove the routed HTTP decision record

Owner: security engineering with the application and records owners.

Pass condition: tests send approved and denied requests through authenticated application -> HTTP policy point -> approved LLM endpoint. Additional cases cover restricted content and missing identity context. Test disallowed destinations and response handling, plus record retrieval and integrity verification. Expected results are written before execution.

Evidence: route diagram and application-supplied principal and workflow. Record the endpoint and model identifier where available, plus the content classification and policy version. Preserve the decision and timestamp, along with the response disposition and correlation ID. Include the signed event and protected export. Complete a retention test. Use AI audit log chain of custody to preserve selection and custody.

Remediate when: direct provider calls bypass the control or events identify only a relay account. Also remediate when the test proves policy configuration while production operation remains untested. Local inference, direct browser use, embedded vendor AI, and stolen-credential activity need evidence from their actual control owners.

DeepInspect

DeepInspect provides an inline policy point for HTTP AI traffic deliberately routed between a bank-controlled application or agent and an LLM endpoint. It evaluates application-supplied identity and workflow context against versioned content and destination policy. It then inspects the response and creates a signed, tamper-evident decision record with the policy version and timestamp.

That record can support Check 3 and Check 8, then join selected requests to change and exception evidence, plus monitoring and provider evidence. The bank retains responsibility for identity proofing and route completeness. It remains responsible for use approval and model governance and validation, plus customer and business outcome review. Its responsibilities also include third-party oversight and retention decisions, along with independent audit. Local inference, direct browser activity, embedded vendor AI, and bypass routes remain outside this HTTP control point. Book a demo today.