Budgets that hold

For any line of AI spend, three questions test whether you're in control of it:

1. Where did it go? — attribution, which chapter 4 built.
2. Who decided that? — an owner for every dollar, which your unit choice named.
3. Can you stop it? — and this one is the tell.

Most organizations, pressed honestly, answer the third question "we'd notice eventually." That is the difference between observing spend and governing it, and this chapter is about crossing it.

Governance by PDF

The most common AI governance artifact in the wild is a document. It's often a good document: which tools each role may use, what data must never be pasted where, approval steps for new vendors, per-team spending guidance. People read it, mean well, and follow it — mostly.

What the document never has is a meter or a limit. Nothing counts spend against the guidance; nothing stops a request when guidance is exceeded; nothing even notices until an invoice does. Governance by PDF fails not because people ignore it but because compliance is unobservable — no one, including the well-meaning, can tell whether they're inside the lines, and the lines themselves push back on nothing. The bill arrives anyway, and the postmortem discovers that everyone followed the policy as they understood it.

A policy is a statement of intent. A budget is intent with an enforcement point. The rest of this chapter is about where that point lives.

Alerts inform the postmortem. Blocks prevent it.

There are two kinds of budget control, and the distance between them is the whole subject.

Alerts fire after spend happens: an email at 80% of budget, a dashboard trending red. Useful — but by the time a human reads the alert, the spend it describes is already on the invoice, and the spend that follows it often is too. Alerts shorten the postmortem; they don't prevent it. A month's damage can land between "threshold crossed" and "someone acted."

Blocks live where requests happen. A real limit means the request that would cross the threshold is denied at the moment it's made — the model call returns a budget error instead of a completion, and spend stops at the line rather than being reported crossing it. This is what "enforced" means: not a strongly-worded notification, but a no.

The uncomfortable corollary: if nothing in your stack can refuse a request, you don't have budgets. You have thresholds with commentary.

Where limits attach

A blocking limit needs a dimension to attach to, and the right ones are the rungs and owners you've already built:

• Team or project — the workhorse. Matches how budgets are actually owned, and the attribution from chapter 4 makes it enforceable.
• Model — caps the expensive frontier model while leaving cheaper ones open; turns "please use the small model for drafts" from a request into a default.
• Key or environment — the blunt instrument that catches runaway scripts, test loops, and leaked keys; every key should have a ceiling on principle.
• Person — the finest grain and the hardest, because it requires identity resolution first: mapping keys, seats, and sessions back to actual humans. Do teams before people; most governance questions are answered at the team level anyway.

Set limits generous at first — the point of the first blocking budget is to exist, not to constrain. A ceiling nobody hits still converts every future anomaly from an invoice surprise into a denied request someone investigates the same day.

The easiest recovered dollar

While the blocking machinery is being argued about, one control recovers money with no enforcement at all: idle seats. Chapter 4 built the numbers — provisioned seats minus active seats, priced at the subscription rate. That difference is spend with no usage, no owner benefiting, and no one defending it.

Check it monthly, reclaim what's idle, and reassign before renewing. It is routinely the fastest governance win available: no request is blocked, no workflow changes, and the savings are visible on the very next invoice.

Governance people can see is governance people accept

A budget that says no will, eventually, say no to someone mid-task. How that moment goes decides whether your governance survives contact with your own organization.

The failure mode is the quiet throttle: requests mysteriously slowing or failing, no explanation, engineers filing it under "the AI is flaky." That breeds workarounds — personal keys, shadow accounts — which destroy the attribution everything else depends on. The pattern that works is the opposite: a clear error that names the limit, and a fast path to raise it. "This request exceeds the Q3 budget for team X — request an increase here" turns a denial into a decision routed to the budget's owner, usually resolved in minutes. People accept limits they can see, understand, and appeal. What they route around is limits that behave like outages.

Attribution tells you where the money went. Budgets decide where it's allowed to go. What remains is sequencing — getting from nothing to all of the above in a month. That's chapter 7.