In-House AI Control Plane Engineering Team Size for a Bank, Under Current Model Risk Guidance
Under the planning assumptions in this guide, a bank building a runtime AI policy enforcement and evidence layer should expect roughly 14 to 24 engineers during the initial build and 11 to 18 in steady state. These are planning assumptions, not published benchmarks. Steady state is lower than build but never near zero, because enforcement, evidence and regulatory mapping must keep pace as models, tools and guidance change.
Criteria for comparing build against buy
- Which of the six workstreams are covered, for build and for steady state?
- Which parts of the integration surface (models, agents, tools, MCP servers) are enforced at runtime today, and which are planned?
- How is evidence generated, retained and exposed to internal audit, model risk and examiners, and who owns it?
- How are human-approval escalations defined, documented and reviewed, and can the design support independent challenge?
- Who maintains connectors and policies as models, tools and guidance change, and how often are they reviewed?
- What deployment model, retention configuration and data residency options are available, and what runtime proof exists?
What current guidance means for the workload
The guidance behind this work has moved. As of November 2026, the Federal Reserve's SR 26-2 presents revised model risk management guidance that updates SR 11-7. It emphasises a risk-based approach tailored to a banking organization's model risk profile and the size and complexity of its operations. It also states that effective policies establish a monitoring and control process and specify the allocation of resources. SR 11-7 remains useful as historical context, including its expectation that internal audit assess the model risk management framework. Map requirements to SR 26-2 first.
The OCC has also published a supervisory framework on bank use of advanced AI and agents. It describes assurance as evidence that controls on a system or agent continue to operate effectively, and it says higher-consequence use cases may warrant tighter autonomy limits, more direct human oversight, more independent validation and stronger resilience measures.
For an engineering team, three things follow. Evidence generation is continuous, not a periodic report. Control strength should scale with use-case consequence, which widens policy engine scope. The group that enforces controls should stay separable from the groups that build and validate AI systems. Each of these turns into standing work, which is why steady-state headcount matters as much as the build estimate.
Six workstreams and staffing ranges
The ranges below are planning assumptions, shown as engineers per workstream for the initial build and for steady state. Roles can overlap on smaller teams, so treat the totals as a structure to adjust, not a quota.
- 1. Policy definition and enforcement in the execution path: Policy engine developers, a security engineer and a policy author. Build 3 to 5, steady 2 to 3. Covers decisions such as allow, redact, block, rate limit and escalate, applied to individual interactions and tool calls.
- 2. Integration surface coverage: Backend and platform engineers for models, agents, tools and MCP servers. Build 3 to 6, steady 2 to 4. Every new model, agent framework or tool adds connector and test work.
- 3. Escalation and approval workflows: Application engineers and a workflow designer. Build 2 to 3, steady 1 to 2. Approvals must be defined, assessed and documented, with a record of each decision.
- 4. Evidence generation and retention: Data engineers and a storage or security engineer. Build 3 to 5, steady 2 to 3. Covers evidence schema, tamper resistance, retention, residency and access for audit.
- 5. Reliability and uptime operations: SRE and infrastructure engineers. Build 2 to 3, steady 3 to 4. A layer in the execution path needs on-call coverage, capacity planning and incident response.
- 6. Regulatory mapping and ongoing maintenance: A technical program lead and a compliance-minded engineer. Build 1 to 2, steady 1 to 2. Maps controls to SR 26-2, the OCC framework and NIST AI RMF functions, and runs policy review cycles.
Assumptions behind the ranges
The totals assume one primary cloud environment, a portfolio in the tens of models, several agent use cases, a handful of tool and MCP server integrations, and evidence that must be retained and queryable by internal audit. Under those conditions the sums are 14 to 24 for build and 11 to 18 for steady state.
The ranges move with specific factors. More models and agents raise integration and policy work. A multi-cloud or self-managed deployment adds infrastructure and security effort. Longer retention periods, strict data residency and regional separation increase the evidence workstream. Heavier examiner evidence expectations add requirements for evidence quality, access and reproducibility. Higher-consequence use cases add policy engine scope and approval workflows.
Most build estimates miss the steady-state curve. The work does not stop at launch. NIST's generative AI profile advises regularly reviewing safety and security controls, especially when a system runs in novel circumstances. Each new model, tool version or regulatory update reopens policy, connector and mapping work.
Operating burden and independence
Reliability is the least visible cost. Because enforcement sits in the execution path, its availability affects every governed AI interaction, so the team must decide whether it fails open or fails closed and then staff on-call rotations, capacity planning and incident review accordingly. Evidence volume is a second operating load, since enforcement at scale produces continuous records that need storage, retention policy and access control.
Independence is the third. The OCC framework notes that effective challenge may depend on independence from both the group that develops or owns a system and the group that validates or monitors it. That affects who can operate the control plane and who approves changes to policy. Model risk, internal audit and independent validation teams will interact with the platform, and whether their capacity counts toward the engineering headcount is an organizational choice. Document the resourcing rationale, as SR 26-2 ties policies to the allocation of resources.
Where Trussed fits in the decision
Trussed is one option to evaluate against the criteria above. It enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit and escalate-for-human-approval decisions to individual interactions and tool calls. Enforcement produces continuous, audit-ready evidence mapped to frameworks including NYDFS and NIST. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency.
The production record includes 18+ months of continuous operation in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane and 30+ GB of audit evidence generated per day. Insurance, a regulated financial sector, is where Trussed is deepest. Banks should judge fit against their own examiner expectations and integration surface, and compare it to the staffing model above.
Planning ranges by phase (assumption-based)
Initial build
About 14 to 24 engineers across six workstreams.
Steady state
About 11 to 18 engineers, weighted toward reliability, evidence and integration upkeep.
Largest build drivers
Integration surface coverage, policy engine scope and evidence design.
Largest run drivers
On-call operations, connector maintenance and regulatory mapping.
Outside the count
Model risk, internal audit and independent validation capacity.
Test your staffing model against a shipped runtime layer
Walk through the six workstreams, your integration surface and your evidence requirements with an expert.
Talk to an ExpertHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.