OCC’s AI Framework: Vendor Updates Need More Than Uptime Checks

Consider a bank’s customer-service platform gaining an AI assistant through a routine vendor update. Summarising a case is one capability; retrieving additional customer records or changing a case’s status is another. The procurement approval may be unchanged, even though the software’s access and authority are not.

That hypothetical illustrates the implementation issue raised by the OCC AI supervisory framework: an existing vendor relationship does not make every subsequent feature an already-assessed capability. AI change management needs to examine what a release changes—not simply whether the service stays online.

The OCC’s November 4, 2026 bulletin introduces an examiner framework and explicitly says it “does not establish supervisory expectations for banks.” Its term “super intelligence” covers technologies previously encompassed by artificial intelligence; the terminology is not evidence of a new technical capability.

The distinction matters throughout this analysis. The controls proposed below are engineering recommendations, not new OCC mandates.

The unit of review is the changed capability

Section 2.9 of the OCC framework addresses AI functionality added to vendor products. It identifies notice and transparency, relationship reassessment and model retesting as possible responses.

The practical implication is to connect vendor management with software-release management. A supplier assessment describes a relationship at a point in time. A release assessment asks whether the particular capability entering production still fits the bank’s approved use, permissions and data boundaries.

For example, an assistant that drafts an internal response and one that sends it to a customer require different acceptance criteria. The relevant change is not merely the presence of a model. It is the path from model output to business action: which information enters, which systems can be called and which approvals remain in place.

This also argues against reviewing only model-version changes. A new connector, altered instruction template or expanded service-account permission can change the operating risk without replacing the underlying model.

Availability is not correct operation

Section 2.10 of the framework states that an agentic system “could remain available while taking inappropriate or harmful actions.” An agentic system, in this context, can select and execute actions rather than merely produce a response.

A successful API response establishes that an interface answered. It does not establish that the resulting action was authorised, accurate or appropriate to the customer’s case.

Monitoring therefore needs separate signals for service health and business correctness. Latency and error rates belong in the first group. Unauthorised access attempts, incorrect workflow transitions and actions taken without required approval belong in the second. A healthy infrastructure dashboard should not override evidence of harmful behaviour.

A release-control checklist

The following checklist translates that distinction into proposed implementation controls. Its scope should reflect the consequences of the feature: internal drafting and autonomous record changes do not warrant identical deployment arrangements.

1. Make the change notice actionable

A useful notice identifies the affected capability, activation date, default setting, dependencies and any changes to data handling or permissions. It should distinguish an optional feature from an automatic change to existing behaviour.

The bank’s release record should connect that notice to an accountable application owner and an acceptance decision. Establish whether the vendor offers a test environment, delayed activation or version pinning—the ability to retain a specified release. These are capabilities to verify, not protections to assume.

The NIST AI RMF Playbook’s MANAGE guidance supports examining third-party release practices, documentation and change management. It supplies implementation context rather than an additional regulatory requirement.

2. Compare permissions before and after

Record which identities, tools and operations the feature can use. Separate reading information, proposing an action, executing it and administering the controls themselves.

Acceptance testing should include prohibited operations. Can a summarisation feature modify a record? Can an assistant act through a broadly privileged integration account despite the user’s narrower permissions? Does a required approval occur before execution, rather than appear afterward in an audit record?

Where permission enforcement sits outside the model, test that boundary directly. A written instruction telling an assistant not to act is not equivalent to removing its execution authority.

3. Trace the data path

Map the information sent to the feature, retrieved from connected systems and retained in outputs or logs. Ask the vendor to document relevant processing locations, retention settings, downstream providers and any use of bank data for training.

Test access boundaries using representative permitted and prohibited records. Include retrieval indexes and caches where applicable: restricting access to an original document is insufficient if an accessible derivative still exposes its contents.

Production logs need their own controls. An investigation record should support reconstruction without becoming an unnecessary repository of customer information.

4. Test outcomes, not matching prose

Build AI regression testing around business requirements. For a case-management assistant, proposed cases might cover incomplete records, conflicting instructions, attempted access outside the user’s role and failure of a connected service.

Where generated wording can vary, exact text matching is a weak acceptance criterion. Check instead whether the response uses permitted evidence, preserves required facts and avoids prohibited actions. Repeat consequential scenarios to examine variability; a single successful run is limited evidence.

Retain the test-set version, configuration, results and acceptance rationale. Where the vendor does not expose a stable model identifier or a production-equivalent test environment, record that limitation explicitly.

5. Define suspension before deployment

Specify which observed failures justify disabling the feature, who has authority to do so and how suspension reaches every execution path.

Hiding an assistant’s interface may leave background jobs, queued actions or integration credentials active. A suspension exercise should therefore check both visible functionality and downstream execution. Preserve enough state to determine which actions completed, which remain pending and which require investigation.

Third-party model monitoring becomes operationally useful only when an alert connects to an effective intervention.

6. Prove the fallback can carry the work

Fallback could mean a non-AI workflow, manual processing or a previous release, where supported. Each option has dependencies: staffing, access, processing capacity and compatibility with records already changed by the new feature.

Rolling software back does not necessarily reverse completed business actions. Recovery needs reconciliation, not simply redeployment.

NIST’s MANAGE 3.1 guidance recommends verifying contingency processes for mission-critical third-party AI systems. A useful exercise would disable the feature during a representative workload and establish whether unfinished cases transfer without loss or duplicate action.

The cost sits between releases

These controls create recurring work: maintaining test cases, reviewing permission differences, mapping vendor telemetry, investigating exceptions and keeping fallback procedures usable. The supplied sources establish no cost estimates or measured savings.

Deployment architecture changes that workload. A separately enabled assistant may be easier to isolate but still require additional access administration. AI embedded throughout a shared workflow may avoid another interface while making suspension more disruptive. Version pinning can preserve a tested configuration, but only if the vendor supports it and the retained version remains maintainable.

The proportionate approach is to concentrate deeper testing on changes that expand data access, execution authority or customer consequences. Treating every cosmetic update as a full reassessment wastes capacity; treating every release from an approved supplier as safe misses the changed capability.

The decisive question is not whether the vendor remains available. It is whether the bank can establish what changed, demonstrate acceptable operation and stop the feature without losing control of the underlying work.

*Methodology and limitations: This analysis uses desk research from the supplied verified primary-source excerpts and summaries. The full sources were not independently retrieved for this article. No vendor configurations, contracts or systems were examined or tested. The checklist is editorial analysis, not a finding about any bank’s implementation or a statement of additional regulatory obligations.*

Sources and References

• OCC Bulletin 2026-54: Super Intelligence—Supervisory Framework, November 4, 2026.
• OCC Supervisory Framework for Bank Use of Super Intelligence, particularly sections 2.9–2.10.
• NIST AI RMF Playbook—Manage, particularly MANAGE 3.1; undated live resource.