Build vs Buy an AI Control Plane: A Bank CIO Framework Under the 2026 Model Risk Guidance

Start from the current supervisory baseline

Many bank AI policies still cite SR 11-7 and OCC Bulletin 2011-12 as the model risk baseline. That guidance has been rescinded. On April 17, 2026, the OCC, the Federal Reserve and the FDIC issued updated interagency model risk management guidance (OCC Bulletin 2026-13; Federal Reserve SR 26-2). It clarifies principles, sets out a risk-based approach and rescinds prior model risk management guidance. As of November 2026, requirements written against the older documents should be re-baselined before they become build or buy criteria.

The 2026 guidance covers model development and use, validation and monitoring, governance and controls, and considerations for vendor and other third-party products. It also states that practice appropriate for one banking organization may be inappropriate for another with a different risk profile or model purpose. That makes your own inventory of intended AI uses the starting input. A generic requirements list will not hold up.

The OCC has also published a supervisory framework for bank use of agentic systems, which it calls Super Intelligence. It discusses controls that may prevent unauthorized, inappropriate or unsafe actions by an agent, and it defines human-in-the-loop and human-on-the-loop oversight. It places policies, technical controls and monitoring at the data, model, application and infrastructure levels. A runtime layer covers part of that stack, so state which part.

Define the functional scope before comparing options

Most failed build or buy evaluations start with an unbounded scope. A useful definition is narrow. An AI runtime control layer sits in the execution path and makes a decision on each interaction or tool call: allow, redact, block, rate limit, or escalate for human approval. It then records that decision, the policy that produced it and any approval outcome as evidence.

Several adjacent capabilities are real requirements but are not runtime enforcement. Pre-deployment testing and validation assess a model before it is used. Governance workflows manage inventory, ownership and approvals. Observability and monitoring detect misfires and support containment after the fact, and the OCC framework describes them alongside preventive controls, not in place of them. Version control of models and datasets, a lifecycle control that NIST's draft generative AI profile calls for, is also a separate requirement.

The test for runtime scope is simple. If the decision must be made before the action completes, and it depends on the content of that specific interaction or tool call, it belongs in the execution path. A governance process that reviews the action afterward does not meet that test. Write this boundary down with risk, security and compliance, because it determines what a build must deliver and what a vendor must be held to.

Define human escalation triggers at the same time. The OCC framework notes that a misfire, hallucination or control breach may justify temporarily increasing human involvement. Decide which events route to a human approver and how that maps to your own in-the-loop and on-the-loop definitions.

Comparing build, buy and hybrid

Score each option against the same criteria and the same scope definition. The table describes typical tendencies, not outcomes. Your own assessment should replace them with evidence from your teams and from vendor answers.

• Time to examiner-ready evidence: Build: depends on how early the evidence store and policy versioning are designed. Buy: depends on whether the vendor's evidence maps to your control framework. Hybrid: depends on the integration boundary.
• Deployment control: Build: full control, full responsibility. Buy: confirm self-managed deployment in your cloud, plus retention and data residency settings you configure. Hybrid: the split of data and control must be documented.
• Maintenance burden: Build: your team maintains every enforcement point as models and tools change. Buy: shifts maintenance to the vendor but adds dependency. Hybrid: two maintenance paths.
• Coverage: Test coverage across models, agents, MCP servers and coding assistants against your actual inventory, not a vendor list or a build roadmap.
• Model risk alignment: Can the option be reviewed, validated where applicable and monitored under the 2026 guidance, including its vendor product considerations?
• Third-party risk fit: A buy or hybrid option adds a third party to assess, and it must also fit your existing model risk process. Name an owner for each review.

Evidence is the deciding criterion

Examiners and internal audit will want to see what AI was permitted to do, what it actually did, and who approved exceptions. An option should therefore be judged on the records it produces, not only on the controls it applies. A reasonable test is whether you can reconstruct, for a given interaction or tool call, the policy in force, the decision taken, any redaction or approval, and the time and system involved.

Build and buy differ mainly in durability and consistency. A build can produce exactly the records you specify, but it must keep the format stable across years of change and prove the records are complete. A purchased layer produces evidence in its own structure, so you must check that the structure, retention and storage location satisfy your policies and can be examined without vendor involvement. In both cases, define retention and data residency requirements first and test the option against them.

Also confirm what the option does not cover. Runtime evidence shows enforced decisions on interactions and tool calls. It does not replace model validation records, dataset or model lineage, or the governance documentation your model risk framework requires. Say this explicitly in the decision memo so that no one assumes a single layer closes every examination question.

Where Trussed fits, briefly

Trussed is one example of a buy option. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants: allow, redact, block, rate limit and escalate for human approval, at the level of individual interactions and tool calls. Enforcement generates audit-ready evidence continuously. It deploys self-managed in the customer cloud, with configurable retention and data residency.

The approved production facts are 100+ models under one policy plane, 18+ months of continuous production in a regulated enterprise, and 99.95% uptime on live production traffic. Trussed's deepest regulated financial sector is insurance. It does not claim bank or other financial-services customers, so a bank should validate fit through its own diligence and the questions above.

Trussed is not a governance workflow tool, an observability product or a pre-deployment testing product. Those functions would sit alongside it in your control stack.