AI Cost Governance Checklist: What to Put in Place in the First 90 Days

How to read this checklist

AI cost governance, as used here, means an agreed baseline for who can use which AI resources, how much, and under what approvals, plus a record showing which controls were in force. It applies to models, agents, tools and coding assistants alike.

The phasing is practical sequencing, not a mandated order. The NIST AI Risk Management Framework and its Playbook state explicitly that they are not checklists and not necessarily ordered steps. They do suggest connecting AI governance to existing organizational governance and risk controls, and that is the starting point here: extend the structures you already run rather than building a parallel one.

Each item is tagged by how it is delivered. Process controls are decisions and responsibilities held by people, such as policy and approvals. Technical controls are tooling and configuration, such as tagging, billing exports and dashboards. Runtime-enforceable controls are those that can be applied to an individual request or tool call in the AI execution path. Many items need more than one type, and the tag shows where the item is primarily delivered.

Days 1 to 30: ownership, policy and risk tolerance

The first month produces decisions, not tooling. Limits set without an owner or a stated tolerance tend to be inconsistent, and they are often adjusted only after an overrun. Settle who decides, what the organization will tolerate, and which AI resources are in scope.

Risk tolerance matters because it gives limits and approval thresholds a basis. NIST guidance on mapping AI risk includes establishing risk tolerance levels, and it ties the documentation of costs to organizational risk tolerance. Treat that as a prompt to write tolerances down in terms that can later be turned into numbers.

• Name an accountable owner (process): Purpose: one party decides on usage policy. Owner: head of platform engineering with a finance partner. Done when: the owner, a delegate and an escalation contact are recorded.
• Write the AI usage policy (process): Purpose: define who may use which models, agents, tools and coding assistants. Owner: security and platform engineering. Done when: the policy is approved and linked to existing risk and governance controls.
• Set risk tolerance and approval tiers (process): Purpose: give limits a basis. Owner: risk function with finance. Done when: tiers state which usage needs no approval, which needs manager approval, and which needs review.
• Define scope and a resource register (process): Purpose: avoid unmanaged usage. Owner: platform engineering. Done when: every in-scope provider, tool and assistant is listed with a named business owner.

Days 31 to 60: usage inventory and spend attribution

Budgets cannot be set responsibly until usage can be attributed. Attribution means tying each unit of usage to a team, application and, where relevant, an agent. Common mechanisms are separate credentials per application, mandatory tags or metadata on requests, and billing exports mapped to a cost-centre list. Quotas and approvals also need an identity to key on, which is one reason to give agents distinct identities. NIST design guidance for agent identity points the same way, stating that agent-specific metrics, thresholds and policies are needed to manage the scale of interactions. It is emerging guidance, not a settled standard.

Expect gaps. Where a tool reports usage only at the seat or organization level, or where traffic reaches providers outside any shared path, attribution will be partial. Record those gaps and the assumptions used to fill them. An honest baseline is more useful than an apparently complete one.

• Inventory actual usage (technical): Purpose: compare real usage with the register. Owner: platform engineering. Done when: observed usage is reconciled to the register and unknown sources are triaged.
• Establish an attribution scheme (technical): Purpose: tie usage to team, application and agent. Owner: platform engineering with finance. Done when: each in-scope source maps to a cost centre, and exceptions are listed.
• Assign identities to agents and services (technical, runtime-enforceable): Purpose: give controls something to key on. Owner: platform and identity teams. Done when: no in-scope agent runs under a shared or anonymous credential.
• Draft budgets and limits from the baseline (process): Purpose: propose figures grounded in observed usage and stated tolerance. Owner: finance with platform engineering. Done when: draft limits exist for each tier and unit.

Days 61 to 90: limits, approvals, review cadence and evidence

The final phase turns drafts into controls in force. Budgets and procurement limits usually live in finance and purchasing processes. Rate limits and approval requirements on individual interactions and tool calls can be applied closer to the request. Decide, per limit, which mechanism is authoritative, so that two controls do not quietly disagree.

Approval and escalation workflows need a defined route: who is asked, how quickly they must respond, and what happens when they do not. Finally, set a recurring review. NIST AI RMF MEASURE 1.2 expects that the effectiveness of existing controls is regularly assessed and updated. Record the outcome of each review, including changes made and the reasons for them.

Retention periods and evidence formats should follow your existing records policy and your auditors' requirements. The goal is that for any date you can show which controls were defined, which were in force, and when they were last reviewed.

• Activate budgets and alert thresholds (technical): Purpose: surface overruns early. Owner: finance with platform engineering. Done when: each unit has a budget, and alerts reach a named owner.
• Enforce rate limits and tool-call restrictions (runtime-enforceable): Purpose: bound usage per identity. Owner: platform engineering. Done when: limits are active and a test shows the limit applying.
• Operate approval and escalation paths (process, runtime-enforceable): Purpose: route above-threshold requests to a person. Owner: policy owner. Done when: one escalation has been run end to end and recorded.
• Start the review cadence and evidence file (process): Purpose: show controls were defined, in force and reviewed. Owner: policy owner with risk. Done when: a first dated review, with policy versions and configuration history, is stored.

What can be enforced in the AI execution path

Most of the checklist is process or tooling work. A smaller set of controls can be applied at runtime, to each request or tool call as it happens: rate limits per identity, restrictions on which tools an agent may call, blocking disallowed destinations, and escalation to a person above a threshold. Monetary budgets, procurement approvals and chargeback remain with finance and purchasing, because they depend on billing data and contracts rather than on a single request.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit or escalate an interaction for human approval, and its scope is individual interactions and tool calls. Because enforcement happens at runtime, not after the fact, each decision also produces audit-ready evidence that supports the retained record described above. It is deployed self-managed in the customer cloud, with configurable retention and data residency.

That evidence covers what policy was applied to an interaction. It does not replace spend reporting, attribution to cost centres, or the human ownership set in the first 30 days.

Tradeoffs to settle early

Three decisions tend to cause rework if left open. Tight limits protect against overruns but can block legitimate work, so pair them with a fast approval route. Fine-grained attribution gives better accountability but needs consistent tagging and identity discipline, so start with the units finance already reports on. Finally, a control that exists only in a policy document is difficult to evidence, so favour controls that leave a record when they act.

• Reuse existing governance: Extend current risk, finance and security processes instead of creating a separate structure.
• Pick one authority per limit: State whether finance, procurement or runtime policy is authoritative for each limit.
• Document attribution gaps: Record where usage cannot be tied to a team or agent and revisit at each review.
• Date every change: Keep versioned policies and configuration history so any past state can be shown.