Presenting a Build vs Buy AI Control Plane Decision to a Bank Board

Define the capability before comparing options

Internal teams often bring this choice to the board as an engineering project or a vendor selection. That framing hides the real subject. The board is accountable for AI risk oversight and needs to know that the bank can show what its AI systems were permitted to do and what they did.

The OCC's 2026 supervisory framework for AI use describes two ideas that make a useful definition. Control means identifying controls that may prevent unauthorized, inappropriate or unsafe actions of an AI system or agent. Assurance means providing evidence that those controls continue to operate effectively. A decision paper should define the capability in those terms: policy enforced in the path that can produce a consequence, covering individual interactions and tool calls, with outcomes of allow, redact, block, rate limit or escalate to a human, and with evidence generated by the enforcement itself.

The distinction that matters most is between a control that decides at the moment of an interaction and one that only observes and reports afterwards. Both have value, but they answer different examiner questions. Write the definition so that both build and buy proposals are measured against the same one.

Set six evaluation criteria and apply them to both options

Criteria set before vendors or internal designs are presented keep the discussion on accountability. Each criterion below should be answered for the build option and the buy option in the same terms.

• Enforcement in the execution path: Does the control decide on individual interactions and tool calls before they take effect, or does it review them afterwards?
• Evidence quality and retention: What does each decision record, who owns the evidence, how long is it kept, and can examiners and internal audit reach it directly? Evidence and logs are sensitive data, so access controls and risk-based retention periods apply.
• Deployment model and data residency: Where does the control run and where is evidence stored? Compare the options on who can access prompts, outputs and records.
• Coverage across models, agents, tools and coding assistants: How do new models, agents, tools, MCP servers and provider-supplied agents come into scope, and who is accountable for keeping coverage current?
• Framework mapping: Can the evidence be mapped to NIST and other frameworks that apply to the bank, and to the bank's own model risk management framework, including SR 11-7 and OCC Bulletin 2011-12?
• Independence and exit: Does the control layer stay independent of any single model provider, and what would replacement or exit involve under each option?

Set out the risks and ownership of each option

Building gives the bank direct control over design and data. The cost is a long-term operating burden that rarely appears in an initial proposal. Policy enforcement in the execution path must be engineered, kept available and tested. Evidence must be durable and in a form that auditors can use. Coverage must be maintained as models, agents, tools and MCP servers change. The OCC framework names lifecycle stages from design through monitoring, change management and retirement, and the paper should cost the control layer across all of them, not only initial development. It should also name the team that owns it and what happens if that team's priorities change.

Buying shifts engineering effort but not accountability. The OCC framework indicates that where vendors are used, accountability for managing the bank's risk generally remains with the bank. Interagency third-party guidance says practices are tailored to the bank's size, complexity and risk profile, and that for critical activities, plans may be presented to and approved by the board or a designated committee. The paper should therefore state whether the control layer is classed as a critical activity. Due diligence should test whether the provider can perform as expected and adhere to bank policies. The contract should address notice of changes, bank access, monitoring and exit. The OCC framework also notes that banks may reassess or retest when vendors add AI functionality to products already in use.

For either path, assign named internal owners, document the residual risk and record who accepted it. A third-party risk management proposal published in September 2026 emphasizes risk acceptance decisions and governance practices. As of November 2026 it remains a proposal, so the paper should be written to hold up under either version of the guidance.

Agree what evidence the board will receive

The OCC's Director's Reference Guide says the board should agree with management on a set of key performance measurements and risk indicators and on how often they are reported. Settle this in the decision paper, not after approval. The test for each item is the assurance idea above: does it show that controls continue to operate effectively?

Useful reporting usually includes policy decisions by outcome (allow, redact, block, rate limit, escalate) and the resolution of escalations. It also covers coverage measured against an inventory of models, agents and tools, in line with the OCC's reference to span of control. Add changes that triggered reassessment or retesting, control failures and how they were contained, and confirmation that evidence is retained and accessible. Higher-consequence use cases may warrant stronger controls and more direct human oversight, so reporting should be able to be cut by use case tier.

The NIST AI RMF Govern playbook notes that organizations can establish board committees for AI risk oversight and should connect AI governance to existing governance and risk controls. The paper should state which body owns the decision and the ongoing oversight, and how its reporting joins the bank's existing risk reporting.

What a bought capability can cover

A neutral paper does not assume that buying is the answer, but it should show what a bought capability can cover so the build estimate is compared with something concrete. Trussed is one example. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with outcomes of allow, redact, block, rate limit or escalate for human approval on individual interactions and tool calls. Enforcement produces audit-ready evidence mapped to frameworks including NIST. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency.

Trussed reports 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic and 100+ models under one policy plane. Insurance is the regulated financial sector where its experience is deepest. These points show the scope a bought option can cover. They do not replace the bank's own due diligence, and each criterion above should still be tested against the bank's use cases.