Shared Responsibility Model for Customer-Hosted AI Runtime Control Under 2026 Supervisory Guidance

What changed in the supervisory baseline

Two developments affect how a bank should write this matrix. On April 17, 2026, the OCC, Federal Reserve Board and FDIC issued revised model risk management guidance (OCC Bulletin 2026-13). It sets a risk-based approach, covers vendor and other third-party products, and rescinds prior model risk management guidance. On September 11, 2026, the FDIC, OCC, Federal Reserve Board and NCUA issued a proposal that would replace existing third-party risk management guidance with guidance tailored to the level of risk. As of November 2026 the proposal is out for public comment and is not final.

The constant across both is the principle that matters most for a shared responsibility model. The final interagency third-party guidance says a bank's use of third parties does not diminish its responsibility to meet its requirements to the same extent as if the activities were performed in-house, and the proposal continues that principle. For a customer-hosted deployment this has a practical consequence. The vendor can own the code. It cannot own the bank's accountability for what the deployed system does.

Because both documents emphasize risk-based tailoring, the depth of the matrix should follow the consequence of the AI use cases the runtime layer covers. A layer in front of customer-facing or decision-support systems warrants more granular rows than one covering a low-risk internal assistant.

Why cloud shared responsibility only partly maps

Cloud shared responsibility models divide duties by service model. The 2020 joint statement on cloud security says the contract should define control responsibilities for both parties, and that responsibilities differ across SaaS, PaaS and IaaS. Under PaaS, the institution is responsible for provisioning and configuring platform resources and for controls over deploying and administering applications on the provider's platform. NIST guidance adds that relinquishing security responsibility should not be a motivation for moving to cloud.

A vendor-supplied software layer running in the bank's own cloud account is a different case. The bank holds the account, so it behaves like IaaS or PaaS: the bank provisions, configures and operates the deployment. The vendor is neither the cloud provider nor a hosted service. Treat this mapping as analysis rather than settled guidance, and write it into the contract explicitly instead of relying on inference.

A useful way to organize the rows is the layered view described in a 2024 speech by then Acting Comptroller Michael Hsu: an infrastructure layer, a model layer and an application layer. That speech is not binding guidance. It does offer a sound test for each row: accountability works best when it sits with the party that has the capability to act. Record the layer each control sits in and who owns it.

A responsibility matrix for a self-managed runtime enforcement layer

The rows below are an analytical starting point, not a regulatory list. Assign each row a named bank owner and a concrete vendor deliverable, and write both at control level in the contract.

• Cloud infrastructure and network: Bank: account structure, network paths, encryption keys, capacity. Vendor: deployment requirements and reference architecture.
• Policy authoring and approval: Bank: defines what the AI may do, approves every policy change, owns the exceptions. Vendor: supplies the enforcement capabilities that policy is expressed in.
• Identity and access: Bank: integrates with its identity provider, grants and reviews administrator access. Vendor: documents roles and permissions the software needs.
• Upgrades and patching: Bank: schedules, tests and applies releases in its environment. Vendor: ships releases and patches with change notices and release documentation.
• Retention, residency and evidence custody: Bank: sets retention periods, region placement and custody, and controls retrieval. Vendor: documents what evidence is produced and in what form.
• Incident response and examiner documentation: Bank: declares incidents, runs response, answers examiners. Vendor: provides support, defect analysis, notification and technical documentation.

Why customer-hosted deployment matters for evidence and residency

Deployment in the customer cloud changes where evidence lives. When the enforcement layer runs in the bank's account, the records it generates are written into storage the bank controls. Residency follows the region the bank selects, and retention follows the periods the bank configures. The final third-party guidance names the bank's access to its own and the third party's data, and the timely sharing of that data and supporting documentation with regulators, as a planning and contract consideration. Custody in the bank's own environment makes that retrieval a bank-side operation instead of a vendor request.

The tradeoff is workload. The bank takes on storage sizing, access control over evidence, backup and the discipline of testing upgrades. A self-managed model reduces dependence on the vendor for evidence access, and it increases the operating burden on the bank's platform team. State both in the matrix so the burden is a planned decision rather than a surprise.

Policy enforcement in the execution path is what makes the evidence meaningful. When a layer enforces policy at runtime, with outcomes such as allow, redact, block, rate limit or escalate for human approval, each outcome is a decision that can be recorded at the moment it occurs. That is different from reconstructing behavior after the fact. Human approval workflows are bank-side decisions: the vendor supplies the escalation mechanism, and the bank decides who approves what.

Governance rules that keep the matrix defensible

Name who monitors the AI system and who is accountable for its use, and record it in governance documentation. OCC supervisory material on AI makes oversight of this kind an explicit element, and it also points to how contracts assign responsibility for model-related errors or losses and to notice of new functionality, with retesting when vendors change things.

Three practices follow. First, run the vendor product inside the bank's model risk management framework, since the revised guidance expressly covers vendor and third-party products. Second, treat vendor-driven changes as events that need notice and, where the risk warrants, retesting before adoption. Third, keep policy change approval with the bank. The NIST AI Risk Management Framework observes that a developer can hold a different risk perspective and use different risk measures than the party deploying the system. The deployer cannot assume the supplier's view of risk matches its own.

Re-check the status of the third-party proposal and the revised model risk guidance before relying on any compliance statement, because the proposal could change before it is final.

Where Trussed fits

Trussed provides runtime control and evidence infrastructure for regulated enterprises. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, and generates continuous audit-ready evidence from that enforcement. It deploys self-managed in the customer cloud, with configurable retention and data residency, which places custody decisions with the customer. It has run in continuous production in a regulated enterprise for more than 18 months, and insurance is the regulated sector where its experience is deepest. The framework above applies whichever vendor a bank selects.