Who should own AI spend forecasts in a mature programme?

Why This Matters for Security Teams

AI spend forecasts are not just a budgeting exercise. In a mature programme, they expose which workloads are scaling, which teams are consuming shared capacity, and whether autonomous AI agents are creating cost outside normal approval paths. If ownership is unclear, the organisation loses the ability to explain variance, enforce guardrails, or separate legitimate growth from wasteful or risky usage. That is especially important where AI systems depend on service identities, API keys, or delegated access that can silently expand consumption.

Security and governance teams should treat forecast ownership as a control question, not just a finance question. The practical challenge is that usage data often sits across cloud billing, platform telemetry, product analytics, and identity logs. A forecast that is technically accurate but not owned by the group closest to the consumption pattern will usually fail to drive action. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces accountability across governance, risk, and operational controls rather than leaving spend oversight as a pure reporting function. In practice, many security teams encounter uncontrolled AI spend only after access sprawl or agent misuse has already inflated the bill.

How It Works in Practice

In a mature programme, the owner of AI spend forecasts should be the person or team that can both interpret the demand signal and act on it. That is usually a platform owner for shared model infrastructure, a finance owner for chargeback and allocation, or a product owner where AI usage is tightly tied to a revenue line. Where AI agents are involved, the ownership model should also make it clear who can answer why the agent was able to call tools, retrieve data, or invoke models at that level of cost.

A workable operating model usually includes three layers:

• Forecast owners set the assumptions, including expected traffic, model mix, token usage, and environment scope.
• Control owners review whether access paths, service identities, and guardrails explain the observed consumption.
• Finance or portfolio owners reconcile variance and decide whether to reforecast, reallocate, or cap spend.

This is where identity governance becomes relevant. If a non-human identity or agent has broad tool access, it can create a spend spike that looks like normal demand unless the logs connect usage back to the identity that triggered it. Current guidance suggests forecasting should be tied to a named operational owner, while chargeback alone is not enough to create accountability. The right question is not only “what did it cost?” but “which workload, identity, or agent caused it, and who can change that behaviour?”

For governance teams, mapping the forecast to a control framework helps keep the process auditable. NIST AI governance expectations align well with the need to document assumptions, owners, and escalation paths, while model and agent telemetry should be retained long enough to explain forecast variance and unusual usage. These controls tend to break down when AI services are centrally pooled across many teams and the organisation cannot attribute usage to a single accountable owner because shared billing and shared credentials obscure the source of demand.

Common Variations and Edge Cases

Tighter ownership often increases administrative overhead, requiring organisations to balance forecast accuracy against the cost of additional reporting and approvals. That tradeoff is real in shared platform environments, where a single model gateway may serve multiple business units and where strict ownership can slow experimentation.

There is no universal standard for this yet, but best practice is evolving toward a split model: finance owns the allocation method, the platform team owns the technical forecast inputs, and the product or service owner owns the business justification. That arrangement works best when AI agents, model endpoints, and service identities are separately tagged so that forecast variance can be traced without ambiguity. Where the programme is still early, central ownership can be acceptable temporarily, but only if it includes a clear path for escalation and reallocation.

Edge cases often appear in regulated or highly distributed environments. If one team trains models and another team runs inference, ownership should follow the dominant cost driver rather than the corporate reporting line. If a service identity can trigger external tools or retrieval pipelines, the cost owner should be the team with authority to limit that access. The practical test is simple: whoever can change the usage pattern should be able to explain the forecast. That principle is strongest when supported by NIST Cybersecurity Framework 2.0 governance discipline, but it becomes fragile in multi-tenant platforms where shared identities and blended charge codes hide accountability.

Related resources from NHI Mgmt Group

• Who should own CAASM outcomes in a mature security programme?
• Who should own EU AI Act monitoring in an enterprise?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?