Responding to Examiner Findings of Inconsistent AI Controls Between Business Lines

What the finding means under current guidance

An examiner finding of inconsistent AI controls usually reflects a simple pattern. One business line requires a formal approval path for a generative AI tool, another allows it by default. One redacts customer data before it reaches a model, another relies on staff judgment. The bank then cannot show, in a uniform way, what each system was allowed to do or what it did.

Two supervisory developments frame the response as of November 2026. The Federal Reserve, OCC and FDIC issued revised interagency Model Risk Management guidance (SR 26-2), which supersedes and replaces an earlier SR letter. It says model risk management practices appropriately vary among banking organizations based on risk profile and model usage. On 4 November 2026 the OCC issued a supervisory framework to support examiners evaluating banks' use of super intelligence systems and agents in normal-course business activities.

The tailoring language matters. Variation by risk profile and usage is acceptable. Variation because each business line built its own approach is harder to defend. The remediation goal is to make differences in control explainable by risk, and to prove that the stated controls operated.

Building the common minimum baseline

A baseline fails when it is a document each business line interprets for itself. Write each control so that its operation can be observed: who may invoke a system, which business processes are permitted to call it, what data may enter it, which actions an agent may take, and when a person must approve.

The OCC framework supports this level of specificity. It refers to controls over the business processes permitted to invoke a system or agent, and to controls that limit automated representations and require verification in higher-impact contexts. Defining permitted invocations explicitly gives examiners something concrete to compare across lines.

Ownership needs the same precision. The OCC framework lists diffuse ownership and insufficient technical fluency as a governance risk that can limit oversight and challenge. It also indicates that effective challenge may depend on independence from both the group that owns or develops a system and the group that validates or monitors it. Name an accountable owner per system and keep the challenge function separate from the teams it reviews.

Where a human process is the backstop, document it and test it. Audit may assess whether that backstop is independently governed, tested and effective.

What runtime enforcement covers and what stays with model risk management

The OCC framework describes control as preventing unauthorized, inappropriate or unsafe actions by a system or agent. Controls that can be decided per interaction or tool call are candidates for one policy applied across business lines. This mapping is an analytical inference, not an OCC requirement. Runtime enforcement does not replace the expectations in the revised guidance for validation, development controls and ongoing performance monitoring.

• Data handling: Runtime: redact or block restricted data in an interaction. Remains with governance and MRM: define data classes and approve use cases.
• Permitted actions and tools: Runtime: allow or block specific tool calls by system and process. Remains with governance and MRM: decide which processes may invoke which systems.
• Human review: Runtime: escalate defined actions for human approval and record the decision. Remains with governance and MRM: set review criteria and test the reviewer backstop independently.
• Usage limits: Runtime: rate limit calls by system or business line. Remains with governance and MRM: set the thresholds through risk tiering.
• Model soundness: Runtime: not addressed. Remains with governance and MRM: validation, documentation, performance monitoring and effective challenge.

Evidence that shows consistent operation

Examiners and internal audit need to see that controls ran, not only that they were written. The revised guidance refers to whether related policies are implemented accordingly, and to documentation supporting effective model risk management. The OCC assurance dimension asks for evidence that controls continue to operate effectively. NIST AI RMF MEASURE 1.2 calls for regular assessment of the effectiveness of existing controls, which makes it a reasonable mapping target for control-operation records.

Evidence is comparable only when it has the same shape in every business line. For each system, retain what it was permitted to do under the baseline, each enforcement decision (allowed, redacted, blocked, rate limited, escalated), the outcome of any human approval, and the policy version in force at the time. Fragmented evidence, such as one team's tickets and another's tool exports, forces examiners to reconcile formats before they can assess consistency.

Vendor updates add a further requirement. The OCC framework notes that updates can alter behavior between periodic reviews and may justify more frequent monitoring or re-validation. Records captured at the interaction layer show how behavior changes independent of vendor release cycles. That is an inference, and it supplements rather than replaces re-validation.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls, and generates audit-ready evidence mapped to NIST, among other frameworks. Insurance, a regulated financial sector, is where Trussed is deepest. Its platform has run 100+ models under one policy plane and has been in continuous production in a regulated enterprise for 18+ months. It does not perform model validation, and it does not provide model lineage or transaction-level governance.