Govern AI Spend Before Finance Governs It for You

Workflow area: Measurement & ROI · Tier: Core · Hands-on time: ~30 minutes

The pattern repeats in almost every org that rolled out AI tools fast: procurement bought a block of top-tier seats "to be safe," a third of them show near-zero usage, two power users quietly burn more API credit than the rest of the org combined, and nobody can answer "what did we get for it?" That last question is the dangerous one — an ungoverned bill invites a blanket cut, and blanket cuts take the productive spend down with the waste. Governing the spend yourself is how you keep control of the tools.

When to use — and when not to

• Use it monthly once you have more than ~20 paid seatsbelow that, a spreadsheet glance suffices; above it, the waste hides.
• Use it before every renewal negotiationusage data is your only leverage against "everyone needs Enterprise."
• Use it when API costs cross roughly 10% of your tooling budgetmetered spend without per-team ownership always drifts upward.
• Skip the chargeback machinery under ~50 engineersshowback (visible per-team numbers, no internal billing) gets the behavior change without the accounting overhead.
• Don't use spend data to judge individualsa low-usage engineer might be in a domain the tools serve badly; usage governance is about seats and tiers, never performance.

The recipe

1. 1.

   Pull the usage export from every admin console. Coding-assistant consoles, chat-tool workspaces, and API dashboards all export per-user or per-team usage. Collect last 90 days: active days per seat, requests or sessions, and API tokens per team or key. Strip individual names before analysis — replace them with role + tier (e.g., "senior-backend, Pro seat").

2. 2.

   Run the seat audit with a fixed prompt. Same template monthly, so trends are comparable:

   Copy

   You are auditing AI-tool spend for an engineering org. Here is
   90 days of usage: seat tier, monthly cost, active days, and
   usage volume per (anonymized) seat, plus API spend per team.
   
   Produce:
   1. SEAT BUCKETS — for each tool: unused (0-2 active days/month),
      light (3-8), regular (9+). Count and monthly cost per bucket.
   2. TIER MISMATCHES — seats whose tier exceeds their usage
      pattern (top-tier seat, light usage) and the downgrade saving;
      also the reverse: heavy users on a lower tier hitting limits.
   3. API CONCENTRATION — teams or keys consuming >20% of API
      spend, with month-over-month trend.
   4. ACTIONS — ranked by annual saving: reclaim, downgrade,
      upgrade, or set a team budget. State the saving per action.
   
   Rules: do not recommend removing a tool, only right-sizing it.
   Flag any number that looks anomalous with [CHECK] rather than
   explaining it away.
   
   Usage data:
   [PASTE EXPORT]
   

3. 3.

   Read the output as proposals, not verdicts. Good output looks like:

   Copy

   SEAT BUCKETS — Coding assistant (Enterprise, $39/seat)
   - unused: 11 seats — $429/mo   [CHECK: 6 are the ML team]
   - light: 17 seats — $663/mo
   - regular: 52 seats — $2,028/mo
   
   TIER MISMATCHES
   - 14 Enterprise seats with light usage → Business tier
     saves ~$2,352/yr
   - 3 heavy users on Business hitting rate limits weekly →
     upgrade; est. cost $684/yr
   
   API CONCENTRATION
   - platform-team key: 41% of API spend, +18% MoM — no budget set
   

   The [CHECK] lines matter most: those six ML-team seats may be unused because the team uses a different sanctioned tool — reclaiming them without asking creates the story "leadership took our tools away over a spreadsheet."

4. 4.

   Set per-team API budgets with named owners. Every API key gets a team owner and a monthly budget with an alert at 80%. The owner's job is not to minimize spend — it is to be able to say what the spend produced. A team that doubles its API bill while cutting cycle time is a success story, not a problem.

5. 5.

   Close the loop with a one-page monthly note. Total spend, spend per active user, actions taken, savings banked, and one line connecting spend to your impact metrics (pb-38's measures, if you run them). Send it to your finance partner before they ask. The leader who volunteers the number never gets ambushed by it.

Make it yours

• Startup or small team: the audit is a 15-minute monthly ritual, and the biggest lever is the free-tier and open-weight literacy your budget forces anyway — know what the free tiers of each tool actually allow commercially, and whether a self-hosted open-weight model covers your bulk API workloads (batch classification, internal search) at a fraction of metered cost. Spend the paid seats on the people shipping daily.
• Mid-size org: run showback, not chargeback — publish per-team spend next to per-team adoption in the same monthly note. Teams self-correct when the numbers are visible; internal billing at this size costs more in process than it recovers.
• Large org or GCC: pyramid-scale orgs need the full FinOps treatment — tier policy by role band (not "Enterprise for everyone"), quarterly true-ups against the vendor contract, API budgets enforced at the key level, and a reclaim workflow (30 days unused → notify → 60 days → reclaim) that runs automatically. At 2,000 seats, a 15% unused rate is a mid-six-figure annual leak.

Quality check

• Anomalies were investigated before actions shippedevery [CHECK] line got a human conversation; reclaiming a seat someone needed costs more trust than the seat cost money.
• No individual was named in any reportbuckets and roles only; the moment usage data touches a performance conversation, engineers start gaming activity metrics.
• Upgrades appear alongside downgradesan audit that only ever cuts is a cost exercise, not governance; heavy users hitting limits are lost productivity you can buy back cheaply.
• API spend trend is explained, not just plottedthe platform team's +18% month should have a sentence attached ("agent pilot ramping, expected"), or it is noise.
• Savings claims survive finance's mathannualized savings on a seat someone re-requests next month are fiction; report savings net of re-adds.