AI Cost Governance KPIs: A Practical Reference for Platform Teams

What the KPI set has to do

Many enterprises run several models, agents, tools and coding assistants across multiple providers. Token consumption, per-interaction cost and tool-call volume are often tracked differently by each team. When that happens, spend is reviewed from invoices after the fact, and nobody can say whether limits were applied consistently or whether usage matched what was approved.

A KPI set fixes this by making each measure explicit: what it counts, how it is calculated, where the data originates, who owns it and what level triggers action. The scope should include licensing and service fees as well as usage-based charges, because AI adoption carries ongoing operating costs beyond the initial platform investment. Document expected and realized costs as a baseline before choosing thresholds, and tie cost decisions to the organization's stated risk tolerance.

The NIST AI RMF is voluntary. Using its govern, map, measure and manage functions to structure spend KPIs is a design choice, not an obligation. It is a useful one, though: it treats costs as something to document and compare against a benchmark, and it expects metrics and controls to be reassessed after deployment rather than set once.

Core KPIs: calculation, data source and measurement level

The table lists one representative KPI family per row. Formulas are starting points. Adapt them to how your providers meter usage and how your teams are organized.

• Spend attribution coverage: Calculation: attributed spend divided by total spend, cut by model, application, team, agent, tool and MCP server. Source: provider billing exports plus request metadata. Level: interaction and tool call, if identifiers are attached at request time.
• Unit cost: Calculation: LLM cost per request is (input tokens x input price + output tokens x output price) summed over requests, divided by request count. Repeat per tool call and per model. Source: provider usage fields and a maintained price table. Level: interaction and tool call.
• Usage concentration: Calculation: share of spend or tokens held by the top N applications, teams or models. Source: attributed spend. Level: aggregate of interaction data; interpretation needs business context.
• Limit and threshold adherence: Calculation: share of interactions evaluated under a defined policy, rate-limit events per period, and threshold breaches per owner. Source: runtime policy decisions. Level: interaction and tool call.
• Exception and escalation handling: Calculation: blocked and escalated requests, exception approval turnaround (decision time minus request time), and exceptions past expiry. Source: escalation and approval records. Level: interaction for the events; approvals need workflow context.
• Cost signal data quality: Calculation: usage records with complete token counts divided by total requests, unattributed spend share, price table age, and variance between metered usage and invoices. Source: usage records, invoices, price table. Level: interaction for completeness; invoice reconciliation is financial.

Interaction-level versus business-level measurement

Some KPIs come directly from what happens in a single model call or tool call. Token counts, the model used, the calling application or agent, the tool or MCP server invoked, the policy decision and the timestamp are all observable at that level. From them you can compute cost per request, cost per tool call, token usage by model, rate-limit events and blocked or escalated counts without any outside input.

Other KPIs need context that an individual interaction does not carry. Whether spend is justified depends on the value of the outcome, which sits outside the call. Share of usage under an approved use depends on a register of approved use cases mapped to applications and owners. Budget adherence requires budgets by cost center. Concentration is computed from interaction data, but deciding whether it is a problem is a business judgment.

Keep this boundary visible in the KPI catalog. Mark each KPI as interaction-level or context-dependent, and name who supplies the missing context. Per-interaction data should not be presented as proof of end-to-end workflow cost or business outcomes. Linking several calls into a single task or transaction is a separate capability, and the KPIs above do not assume it.

Assign ownership, thresholds and review points

A KPI without an owner is a report nobody acts on. Assign each KPI to a named role, set a threshold that triggers a defined response, and record when the definition itself will be reviewed. The sources of the thresholds should be documented benchmarks or baselines, not guesses that harden into policy.

• Platform engineering owns the measurement layer: Unit cost, attribution coverage and data quality KPIs depend on instrumentation and price tables, so these teams usually own them.
• Application owners own their own spend: Each application or team owner should see attributed spend and unit cost for their systems and respond to threshold breaches.
• Security and risk own adherence and exceptions: Policy coverage, blocked and escalated requests, and exception turnaround fit naturally with the function that defines the policies.
• Finance owns reconciliation and budgets: Invoice variance and budget mapping need financial context that engineering does not hold.
• Set a cadence per KPI: Operational KPIs such as rate-limit events suit frequent review. Definitions, thresholds and controls should be reassessed on a fixed schedule your organization chooses.
• Budget for measurement itself: Deeper per-interaction capture carries storage and compute cost. Decide the depth of capture per workload deliberately.

Keeping the cost signal reliable

The most common failure is not a bad formula but a bad input. Usage records may lack token counts for some providers or streaming responses. Requests may arrive without the identifiers needed for attribution, leaving an unattributed remainder that grows quietly. Price tables go stale when providers change rates, which silently distorts unit cost. Different providers also meter differently, so cost per request is only comparable after normalizing units.

Track these as KPIs in their own right. Usage record completeness, unattributed spend share, price table age and invoice reconciliation variance show whether the other KPIs can be trusted. A rising unattributed share is a signal to fix tagging before drawing conclusions from the attributed figures.

Shadow usage is the other gap. Spend that never passes through a measured path cannot appear in any interaction-level KPI. An inventory of AI use cases, built by polling system owners on a regular schedule, is one way to surface unregistered usage. Compare the inventory against metered traffic and billing lines, and treat mismatches as findings to investigate.

Where runtime enforcement makes adherence KPIs verifiable

Limit and exception KPIs are easy to estimate and hard to verify. If limits are applied by convention or checked in a later review, adherence is inferred. If policy is enforced in the execution path, each decision (allow, redact, block, rate limit, escalate for human approval) is a recorded event tied to a single interaction or tool call. Share of usage under a defined policy, rate-limit events, blocked and escalated requests and approval turnaround then come from enforcement records, not reconstruction.

Trussed enforces policy at runtime across models, agents, tools, MCP servers, AI sites and coding assistants, and produces audit-ready evidence from those decisions. Its scope is individual interactions and tool calls. Retention is configurable and the system can be self-managed in the customer's cloud, which matters when each adherence KPI needs evidence kept for a defined period. The same KPI definitions in this guide apply whether you collect the data this way or through other means.