AI Control Plane Components: Build Versus Buy for a Bank

What an AI control plane is made of

An AI control plane is not one product. It is a set of functions that together decide what models, agents, tools, MCP servers and coding assistants are permitted to do, enforce that decision, and prove it afterward. Sourcing decisions go wrong when the set is treated as a single build or a single purchase.

Published references give a useful way to split the work. An OCC supervisory framework document, current as of November 2026, groups considerations into areas that include control (preventing unauthorized, inappropriate or unsafe actions by an AI system or agent), resilience (detecting, containing, recovering from and remediating failures) and assurance (evidence that controls continue to operate effectively). Its language is permissive, so treat it as a decomposition aid rather than a checklist of mandates.

On the technical side, NIST CSRC conference material on runtime execution governance argues that the decision must control the path capable of producing the governed consequence. OWASP's AI Security Verification Standard lists identity for AI components and users, change control, and output control as separate testable areas, and its agentic application guidance treats identity and access, runtime protection and supply chain security as distinct topics. Taken together, these support six components: policy definition, runtime enforcement, identity and access, human approval, evidence generation and retention, and code provenance.

Five criteria for each sourcing decision

Apply the same five questions to every component so the decision record is consistent across teams.

Differentiation: does the component express something particular to the bank, such as risk appetite or who may approve an exception? If so, outside parties cannot supply it. Maintenance burden: runtime enforcement must keep pace with new models, agent frameworks, tool protocols and MCP servers. Industry commentary on AI deployment describes significant ongoing investment to maintain controls, so estimate the staffing for upkeep, not only the first release.

Evidence durability: records must show that controls kept operating, not only how they were configured at launch. Examiner defensibility: can the bank explain to an examiner what the component does, how it was validated and how it fits existing model risk management processes? Deployment and data residency: prompts, outputs, embeddings, logs and feedback may all become evidence, so where the component runs and where those records live can rule an option in or out regardless of features.

A component that scores low on differentiation and high on maintenance burden is a buy candidate. A component that scores the reverse is a build candidate. Mixed scores usually mean a split, where the bank owns the definition and a purchased component executes it.

Component-by-component starting positions

These are starting positions for architecture review, not fixed answers. Existing platforms, staffing and third-party risk appetite will move some of them.

• Policy definition: build: Policy intent, risk appetite and autonomy boundaries are institution-specific. The bank owns the rules, even if authoring tools are purchased.
• Runtime enforcement: evaluate buying: Low differentiation and high maintenance burden across models, agents and tools. Must act in the execution path, not only observe.
• Identity and access: extend what exists: Baseline identification, authentication and access control are assumed to exist already. Connect the control plane to current IAM rather than replace it.
• Human approval: split: Approval authority and thresholds are the bank's. Escalation triggers can be enforced by a purchased component and routed into existing workflows.
• Evidence and retention: split: Evidence generation is best tied to enforcement. The bank sets retention, residency and its mapping to model risk management documentation.
• Code provenance: evaluate buying: Origin, licence and security context of code are commodity analysis. Assess as its own component, since supply chain risk is treated separately.

Evidence, examiners and third-party risk

Evidence is where weak boundaries surface. If enforcement happens in one team's code, approvals in another's tickets and records in a third system, assembling a coherent account for an examiner becomes a manual exercise. Evidence generated by the enforcement point itself, at the moment of each decision, avoids reconstructing events later.

The OCC document suggests linking inventory entries to ownership, provenance, autonomy, monitoring and continuity arrangements. Evidence records should therefore reference the bank's AI inventory so an examiner can move from a system to its controls to what actually happened. Mapping that evidence to the NIST AI RMF functions (GOVERN, MAP, MEASURE and MANAGE) is a bank decision; no source prescribes which component maps to which function, so make the mapping explicit and keep it with the model risk management file.

Buying shifts some work rather than removing it. NIST's generative AI profile flags untraceable integration of upstream third-party components and improper supplier vetting as value chain risks. Banks have described applying due diligence and validation to vendor models much as they do to in-house ones, and a purchased control component should expect comparable scrutiny under the bank's third-party risk policy. Ask what documentation, validation access and evidence export the vendor provides before the contract, not after.

Producing a defensible sourcing decision

The output for procurement and architecture review should be a short decision record per component, not a single verdict. Document system boundaries before deployment and again after material change, since a changed boundary can change which component owns a control.

• List the six components and name the bank's current owner for each.
• Score each component on the five criteria and record the evidence behind each score.
• Mark each as build, buy or split, and define the interface where the bank's policy meets the purchased enforcement.
• Run third-party risk review on every purchased component and record the validation approach.
• Test evidence end to end: pick one blocked or escalated action and trace it from policy to enforcement to retained record.