When should organisations use traditional FinOps controls for AI infrastructure, and when do they need new governance rules?

Why This Matters for Security Teams

AI infrastructure often looks like ordinary cloud spend at first glance, so teams default to familiar FinOps practices such as tagging, allocation, and budget thresholds. That works until usage becomes highly variable, model experimentation accelerates, or a small set of users can trigger large downstream compute and storage costs. At that point, cost control is no longer only a finance issue. It becomes an operational governance issue tied to workload approval, service limits, and change management.

The practical challenge is that AI consumption can scale faster than the organisational controls built for standard application hosting. Traditional FinOps is still essential, but it is not enough when teams can provision GPU-backed services, call external models, or run autonomous workflows with limited friction. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to manage governance, risk, and resource accountability together rather than as separate disciplines.

In practice, many security teams encounter AI cost abuse only after a pilot becomes a production dependency, rather than through intentional capacity planning.

How It Works in Practice

Traditional FinOps controls should remain the baseline for AI infrastructure because they provide the mechanics that every environment still needs: cost allocation, budget alerts, forecasting, and exception handling. These controls are effective when the main problem is visibility. They are not enough when the main problem is control of rapidly changing consumption patterns, especially where users can create, retrain, or invoke AI services in an ad hoc way.

When AI workloads are predictable, existing governance can usually manage them through cloud cost policies and standard approval paths. When they are not predictable, organisations need new rules that govern the conditions under which AI services may be used, who can approve high-cost workloads, and how usage is monitored. NIST AI guidance and the NIST AI Risk Management Framework both point toward controls that address risk, accountability, and measurement, not just spend reporting.

Operationally, that usually means combining finance controls with AI-specific guardrails:

• Set spending thresholds for training, fine-tuning, and inference separately.
• Require approval for model classes, data volumes, or GPU tiers above defined limits.
• Track cost per workload, per team, and per business outcome rather than only by subscription.
• Monitor usage spikes that may indicate prompt loops, runaway agents, or unplanned scale-out.
• Align access to AI platforms with identity and privilege controls so service enablement is not fragmented.

Where AI is embedded into automated workflows, governance also needs an identity angle. If an agent can call tools, request compute, or trigger downstream actions, the organisation should treat that execution path as a governed entitlement, not just a usage line item. This is where the overlap with NHI management becomes material: the same control plane that authorises a workload should also define what that workload is allowed to consume. These controls tend to break down when AI platforms are shared across business units with weak ownership boundaries because no single team can enforce usage policy end to end.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance cost visibility against speed of experimentation. That tradeoff is especially visible in research teams, product prototyping, and agentic automation pilots, where strict approval gates can slow discovery if they are applied too early or too broadly.

Best practice is evolving, but current guidance suggests using traditional FinOps until the workload shows clear signs of autonomy, volatility, or non-linear cost growth. At that point, new governance rules should define what “acceptable use” means for AI infrastructure, including who may launch large jobs, how third-party model services are approved, and what telemetry is required before a system is promoted beyond pilot status.

There are also edge cases where cost governance and security governance converge. For example, open-ended access to model APIs can create both financial exposure and data exposure, especially if users can send sensitive content to external services. In those environments, cost controls alone are too narrow. Organisations should coordinate with OWASP guidance for large language model applications and AI risk policies to ensure that budget thresholds do not become the only barrier to unsafe use. The key question is not whether AI is expensive, but whether its consumption can be predicted, bounded, and attributed with enough confidence for the current control model.

Related resources from NHI Mgmt Group

• Should organisations use AI for identity governance before they clean up data and policies?
• How should organisations use AI agents in access reviews without losing governance control?
• Should organisations use new AI-specific identity standards or existing ones?
• How should organisations use AI in IAM without weakening governance?