Treating AI Spend Overruns as an Operational Risk Event in Banks

Why an overrun is a control question, not a budget question

Finance teams see AI overruns as invoices that exceed a forecast. Risk teams should ask a different question: what allowed consumption to pass an approved limit, and who owned the control that should have stopped it?

The operational risk framing fits the definitions banks already use. In the EU, CRR3 defines operational risk as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events, and it expressly includes model risk. A runaway agent loop, an unapproved model route or an unmonitored shared credential is a failed process or system control in that sense.

For EU entities, DORA adds a second test. An ICT-related incident is a single event or series of linked events, unplanned by the financial entity, that compromises the security of network and information systems and adversely affects the availability, authenticity, integrity or confidentiality of data or of services provided. Not every overrun meets this. A spend spike alone does not. An overrun that degrades a service, or that results from unauthorised access to models or credentials, may. Each case needs assessment against the definition.

No external taxonomy sets a threshold for AI consumption. The bank has to define and document its own criteria, which is why the next section proposes a structure.

Proposed classification criteria for AI consumption overruns

The criteria below are an illustrative starting point for internal calibration, not a regulatory standard. The distinguishing variable is whether a control operated, not how large the overrun was. Dollar thresholds belong in the bank's own risk appetite.

• Budget variance: Spend exceeds forecast but stays within approved limits. Identity, model access and tool permissions were as authorised, and controls operated. Handled by finance and the business owner.
• Near miss: A limit would have been exceeded, but a preventive control blocked, throttled or escalated the activity in time. Record it, because it shows the control worked and reveals the failure mode.
• Control failure or deficiency: Usage exceeded an approved limit because a control was absent, misconfigured, bypassed or dependent on after-the-fact reporting. Requires a root cause, a remediation owner and a due date, even without a recognised loss.
• Operational risk loss event: A control failure led to a recognised financial loss or adverse impact, such as unrecoverable charges or a degraded service. Enters the bank's event data and may trigger incident assessment, including DORA for EU entities.

Map each failure mode to a root cause and a runtime control

OWASP lists unbounded consumption (LLM10:2025) and unrestricted resource consumption (API4:2023) as recognised risk categories. Under that heading, four technical failure modes recur in banks deploying LLMs, agents and coding assistants. Each should be tied to a root-cause category and a preventive control, because a limit that is only reported on later is a detective control at best.

Trust-tiered rate limiting is documented as a pattern for agent-driven API use in payments. The same idea can be adapted to AI consumption: tighter limits for less trusted identities and higher-risk tools, with escalation for exceptions.

• Runaway agent loops: Root cause: process design with no iteration bound. Control: rate limit per identity and session, with block or human-approval escalation when a threshold is crossed.
• Repeated or uncontrolled tool calls: Root cause: excessive tool permissions. Control: allow-list tools, rate limit calls individually, and require approval for high-impact or high-volume actions.
• Unapproved model access or routing: Root cause: weak model inventory and access control. Control: block requests to models outside the approved set and record each denial.
• Shared or unmonitored credentials: Root cause: inadequate identity management. Control: limits tied to individual identities so consumption can be attributed to a control owner.

Place the event inside existing frameworks and assign ownership

Overruns rarely belong to one function. Operational risk owns event classification and loss data. Technology risk owns availability and resilience. Model risk owns whether LLMs, agents and coding assistants are in the model inventory and under appropriate validation and monitoring. Third-party risk owns the AI vendor relationship. Without explicit assignment, an event can be classified in one team and remediated in none.

On 17 April 2026, the OCC, in coordination with the Federal Reserve Board and FDIC, issued updated model risk management guidance (OCC Bulletin 2026-13). It covers model development and use, validation and monitoring, governance and controls, and vendor and other third-party products, and it rescinds earlier issuances including OCC Bulletin 2011-12 and OCC Bulletin 2021-19. As of October 2026, it is expected to be most relevant to banks with over $30 billion in total assets, and it calls for practices that are risk-based and commensurate with size, complexity and extent of model use. Control mappings that still cite rescinded bulletins should be updated.

The FDIC also points institutions to the interagency third-party risk guidance, which supports a risk-based approach across the life cycle of a third-party relationship. Where AI is consumed from an external provider, usage limits and exception handling belong in that life cycle. NIST AI 600-1 adds that GAI risk tiers should consider dependencies between GAI and other IT or data systems, which is a useful input when deciding how tightly to limit a given agent or tool.

Evaluating a runtime enforcement approach

Test any approach against four questions. Does it enforce limits before execution, at the level of the individual interaction and tool call, rather than only reporting spend later? Which actions does it support, and are decisions recorded in a form audit can review? Can limits be tied to identities, credentials and approved models, so shared credentials and unapproved access are detectable? Can records be mapped to the bank's event taxonomy, model inventory and NIST AI RMF documentation, and who owns each mapping?

Trussed is runtime control and evidence infrastructure for consequential AI. 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 continuous audit-ready evidence, mapped to frameworks including NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Its deepest experience is in insurance, a regulated financial sector, and its scope does not extend to transaction-level governance or end-to-end tracing of agentic workflows.

A practical next step is to take one recent overrun or near miss, classify it with the criteria above, and check whether the evidence needed to support that classification existed at the time.