Bank Examiner Expectations for AI Usage Controls Evidence Under the Revised Model Risk Guidance

What changed in the model risk baseline

On April 17, 2026, the OCC issued Bulletin 2026-13, announcing updated model risk management guidance from the OCC, the Federal Reserve Board and the FDIC. The guidance clarifies model risk management principles, sets out a risk-based approach, and rescinds prior model risk management guidance and other issuances. It covers model development and use, validation and monitoring, governance and controls, and vendor and other third-party products.

The guidance states that it does not set enforceable standards or prescriptive requirements, and that non-compliance will not result in supervisory criticism. That shapes how risk leaders should read it. It describes sound practice. It does not list evidence an examiner must receive for AI usage limits.

Program documents that still cite SR 11-7 or OCC 2011-12 should be reviewed against the revised text and updated. The mapping in this guide is an inference from published guidance and examination materials, not a codified AI cost-control requirement.

Where examiners are likely to probe AI usage and consumption

Four themes in existing materials give examiners a reasonable basis for questions about AI usage controls.

The first is limits on use. The Federal Reserve's model risk guidance gives placing limits on model use, or more closely monitoring performance, as examples of appropriate controls when a model has limitations. It also says that when a model's use is extended beyond its original application, sound practice involves analysis of the new usage and a review of existing controls. A coding assistant or agent that gains new tools is a plausible example of extended use.

The second is monitoring. An effective ongoing monitoring plan may include regularly assessing limitations and having procedures for responding to issues before and after approval. Records of how issues were handled matter as much as the plan.

The third is third-party oversight. The revised guidance covers vendor products, and earlier Federal Reserve supervisory material frames the expectation that a bank evaluate a fintech's activities as though it performed them itself. External models and tools sit inside that scope.

The fourth is operational control. The FFIEC Architecture, Infrastructure, and Operations booklet, announced in 2021, gives examiners procedures to evaluate operational controls. It is not AI-specific, but it shows how examiners test whether controls work.

Policy documentation versus operating evidence

A usage policy says what should happen. Operating evidence shows what did happen. Examiners can read a policy in minutes. The harder question is whether a specific limit, entitlement or approval step functioned on a specific date for a specific identity.

Cost and consumption belong in this discussion as risk-tolerance questions. NIST AI RMF Map 3.2 calls for documenting potential costs, including non-monetary costs from AI errors, in relation to organizational risk tolerance. Read that way, a consumption limit is a control with a documented rationale, not only a budget measure. NIST AI RMF is voluntary framework material, not a bank examination requirement, but it is a useful structure for organizing artifacts. MAP 4.2 asks that internal risk controls for AI system components, including third-party AI technologies, be identified and documented. Govern 1 refers to AI risk policies and processes that are in place, transparent and implemented effectively.

The Federal Reserve Board's own compliance plan under OMB M-25-21 offers an analogue. It describes technical controls to monitor AI usage, detect policy violations and terminate noncompliant use, along with documented waivers that include scope, justification and supporting evidence. That describes the Board's internal practice as an agency, not a bank examination requirement, but it shows the control categories that a mature program tends to contain.

Evaluating whether a control enforces policy at runtime

The central distinction is where the control sits. A control in the execution path makes its policy decision before the AI action completes. A control that works through after-the-fact review reconstructs what happened from records and relies on someone noticing a problem. Both have a place, but they produce different evidence. This is an analytical framing, not a regulatory definition.

Use these criteria when assessing a mechanism. Does it act on the interaction or tool call itself, so a prohibited action is blocked rather than flagged later? Does each decision record carry enough context to reconstruct what AI was allowed to do and what it did? Does coverage extend to external models and tools, consistent with MAP 4.2 and the guidance on vendor products? Can entitlement state be shown as of a past date? Can evidence be retained and produced independently of the teams being examined, with retention periods you set? Can records be mapped to Govern, Map 3 and Map 4.2, and to your model risk and third-party risk documentation?

There are tradeoffs. Runtime enforcement adds a dependency in the path of AI use, so availability and failure behavior need to be tested and documented. Tight limits can interrupt legitimate work, which makes exception handling and escalation design part of the control, not an afterthought. Per-interaction records can also be voluminous, so retention and residency settings need deliberate decisions.

Where Trussed fits

Trussed is control, provenance and evidence infrastructure for consequential AI. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with decisions to allow, redact, block, rate limit or escalate for human approval. Enforcement applies to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and that enforcement generates audit-ready evidence continuously, mapped to frameworks including NIST, NAIC, NYDFS, HIPAA and the EU AI Act. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Insurance is the regulated financial sector where Trussed is deepest. Its customers span four regulated verticals: insurance, pharma, healthcare and education. Financial services beyond insurance is not a vertical where Trussed claims deployments, so banks should evaluate it against the criteria above like any other mechanism. Trussed runs 100+ models under one policy plane, has operated continuously in production at a regulated enterprise for 18+ months, and has held 99.95% uptime on live production traffic. It generates 30+ GB of audit evidence per day.