AI cost governance: definition, control points, and the role of runtime policy enforcement

A working definition

This guide treats AI cost governance as a discipline with four layers: usage metering, attribution, budgeting and enforcement. The layers are a practical framing for platform teams, not a formal standard. Each answers a different question, and confusing them is the most common reason teams believe they have limits in place when they only have reports.

AI FinOps usually sits in the budgeting and attribution layers. It concerns visibility, allocation and forecasting of AI spend, and it depends on metering data. AI usage monitoring is closer to metering. AI risk governance is broader: it concerns whether AI use is appropriate, safe and compliant, and consumption is only one input. AI cost governance overlaps with all three but adds one requirement that the others do not: a limit must be able to change what happens to an individual interaction.

That requirement matters more as architectures move from single model calls to agents that call tools, invoke MCP servers and chain further model calls. Consumption in these systems is driven by decisions made at runtime, often without a person in the loop. A monthly invoice describes the sum of those decisions. It does not constrain any one of them.

Which layers are retrospective and which act in the execution path

The distinction that matters for platform teams is timing. A control either acts before consumption, in the path of the request, or it reports afterwards. Both are useful, but they are not interchangeable, and they produce different evidence.

• Usage metering: Retrospective. Counts tokens, calls and tool invocations as they occur or after. Evidence: usage records, which show what happened but not what was permitted.
• Attribution: Retrospective. Maps metered usage to users, applications, teams or business units. Evidence: allocation reports, only as accurate as the identifiers captured at the time of the call.
• Budgeting and alerts: Retrospective, or advisory. Sets targets and notifies when thresholds are crossed. Evidence: the budget, the alert and any later review. Nothing stops the next request.
• Runtime enforcement: In the execution path. Evaluates policy before a request or tool call proceeds. Evidence: a record of the policy version applied and the decision taken for that interaction.

What finance, risk and audit stakeholders can rely on

Each stakeholder asks a different question. Finance wants to know who consumed what. Risk wants to know whether the organisation defined limits and whether they were applied. Audit wants records that were generated at the time and cannot be reconstructed after the fact. Metering and attribution satisfy the first question. They do not answer the second or third, because a usage record shows consumption but not the policy in force when it occurred.

For each interaction, durable evidence should show which policy and version applied, what decision it produced (allowed, redacted, blocked, rate limited or escalated), and when. It should also be retained under a defined period and in a location consistent with the organisation's data residency requirements.

Regulatory context should be stated carefully. As of October 2026, the EU AI Act (Regulation (EU) 2024/1689) requires a risk management system that is established, implemented, documented and maintained for high-risk AI systems. The high-risk rules apply from 2 December 2027 for stand-alone systems and 2 August 2028 for systems embedded in products, following the Digital Omnibus on AI. Whether a deployment is high-risk depends on its use case. Obligations for general-purpose AI model providers have applied since 2 August 2025 and fall on those providers. Where a usage limit forms part of an organisation's documented controls, the useful question is whether it can be shown to have been applied, and that is an evidence question as much as a configuration one.

Where runtime policy enforcement fits

Metering, attribution and budgeting remain necessary. Runtime enforcement does not replace them. It supplies the layer they lack: a decision made in the execution path, with a record of that decision.

Trussed provides this layer as runtime policy enforcement. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. For each individual interaction or tool call, it can allow, redact, block, rate limit or escalate for human approval. These controls are enforced at runtime, not reviewed after the fact. The enforcement itself generates continuous audit-ready evidence, mapped to frameworks including the EU AI Act and NIST, so a finance, risk or audit stakeholder can see what a policy permitted and what was decided. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

Its scope is individual interactions and tool calls. It does not attribute consumption at the level of a business transaction or workflow, so teams should keep their existing metering and attribution tooling for that purpose.