Who should be accountable for governing AI and cloud infrastructure costs across operations and FinOps teams?

Why This Matters for Security Teams

AI and cloud cost governance fails when accountability is vague. If no team owns the power to approve workloads, stop waste, and enforce guardrails, spend becomes a side effect rather than a managed risk. That matters because uncontrolled usage can hide misconfigurations, shadow deployments, and unnecessary data movement, all of which create both financial pressure and security exposure. The NIST Cybersecurity Framework 2.0 reinforces that governance is not just policy writing; it is decision-making, oversight, and continuous execution.

In practice, the right model is shared accountability with clear operational ownership. FinOps can define cost visibility, allocation rules, and budget thresholds, while CloudOps and platform teams control the systems that actually consume resources. Security teams matter too when cost behaviour is tied to identity sprawl, overprivileged automation, or poorly governed AI agents. The question is not whether finance or engineering should "own" costs in isolation. It is who can intervene before the bill and the risk both grow. In practice, many security teams encounter cost governance only after runaway usage has already triggered exceptions, not through intentional control design.

How It Works in Practice

Effective governance usually combines policy ownership, technical enforcement, and exception handling. FinOps typically defines tagging standards, unit economics, chargeback or showback models, and reporting cadence. CloudOps or platform engineering owns the runtime controls, such as quotas, autoscaling limits, approved regions, and service provisioning pathways. For AI workloads, that scope should also include model usage controls, RAG pipeline spend, prompt and inference logging, and restrictions on unmanaged API keys or secrets.

Security and governance teams should set the control expectations, not operate every workload. That means defining who can approve new services, who can grant temporary exceptions, and who must remediate overspend or policy drift. Where AI systems are involved, this should extend to model provenance, training data integrity, and validation of outputs before downstream automation consumes them. NIST guidance on control baselines, including NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful because it maps governance to auditable action rather than informal oversight.

• Assign one accountable owner for policy and one operational owner for enforcement.
• Set spend thresholds, alert routes, and stop conditions before workloads go live.
• Require tagging, identity attribution, and workload ownership for every AI and cloud asset.
• Review exceptions on a fixed cadence, with explicit expiry dates and approvers.
• Connect cost anomalies to security review when they involve new identities, tokens, or automation.

Best practice is evolving, but current guidance suggests that cost governance should be treated like any other control domain: measurable, reviewable, and tied to named decisions. These controls tend to break down when organisations have separate budgets, decentralised engineering teams, and no shared platform inventory because no single team can see usage, approve changes, or enforce limits across the full stack.

Common Variations and Edge Cases

Tighter cost control often increases operational overhead, requiring organisations to balance budget discipline against delivery speed. That tradeoff is especially visible in AI environments, where experimentation, bursty inference demand, and variable token usage can make rigid budgets impractical. In those cases, the right answer is not a single hard cap for every team, but tiered approvals and exception workflows that differ by workload criticality.

There is no universal standard for this yet, particularly for agentic AI and shared platform teams. Some organisations place final cost accountability in FinOps, while others keep it with the engineering director or cloud product owner. The most reliable pattern is to keep the policy authority with governance functions and the execution authority with the teams that can change infrastructure in real time. Where identity is part of the cost problem, such as overprovisioned service accounts, orphaned API keys, or AI agents with excessive tool access, the issue becomes both financial and security-related. In those cases, accountability should include IAM or NHI governance, not just budget review.

For regulated environments, the governance model should also align to resilience and control evidence. That means preserving approvals, exceptions, and remediation records so auditors can trace why a workload was allowed, who accepted the risk, and when it was reviewed. If that trail does not exist, neither FinOps nor CloudOps can prove that cost controls were actually enforced.

Related resources from NHI Mgmt Group

• Who is accountable for governing AI app use in the browser across security, compliance, and IT teams?
• How should engineering teams reduce runaway AI infrastructure costs in managed cloud platforms?
• How should security teams govern AI gateway traffic when cloud pricing, routing, and logging costs are split across multiple services?
• How should security teams inventory AI agents across SaaS, cloud, and low-code platforms?