Scenario: running an AI governance review

Metering and attribution produce the data; governance is the habit of acting on it. This guide is a recurring review loop (monthly fits most teams) that turns the governance reports into decisions without turning the meeting into a surveillance exercise. It assumes metering is set up and attribution has had a period or two to bed in.

1. Start from the exceptions, not the charts. The governance overview ranks a short list of exceptions worth attention this period, each sized and linked to the report that explains it. Work that list top to bottom rather than browsing dashboards: it exists so the review has an agenda.

2. Model mix. When high-cost models are carrying a large share of requests, the exception states the estimated monthly headroom. Follow it into the model breakdown, find the workloads that don't need the expensive model, and treat the headroom as a hypothesis to test: it assumes most of that work could shift, which is a review's judgement to make, not a fact.

3. Reliability drag. Spend burned on failed requests and retries. The API health report shows which models and providers are erroring and how latency is trending, usually an engineering fix (timeouts, retry config, a flaky endpoint) rather than a budget conversation.

4. Cache reuse. A low cache hit rate means repeated work is being paid for at full price. The cache ROI report shows what better reuse is worth; the fix lives in how prompts and context are structured.

5. Spend not tied to delivery. A low attributed share is a data-hygiene finding before it's a spend finding: unlinked identities and missing ticket references produce it just as surely as untracked exploration. The attribution view separates unticketed from unattributed: fix the identity gaps, nudge the ticket-reference habits, and only then ask whether the remainder is a problem.

6. Read the value story as labelled. The measured comparisons (AI-touched work against the rest of delivery) lead, and they're labelled as observed correlations for the period, not measured speed-ups. Keep that language in the review: people self-select when to reach for AI, and a governance review that launders correlation into causation stops being defensible. Modelled estimates stay behind their toggle, quoted as modelled if quoted at all.

7. Keep the privacy posture in the room. Run the review on org and team views. If individual detail is needed (a coaching conversation, an anomaly worth understanding), it's opt-in, framed as coaching, and the person can see the same detail themselves. Review minutes that name teams and workloads age better than minutes that name people.

8. Record what was decided. Exports (the AI Tax report exports to Excel) are logged to the audit trail, and spend-rule changes that come out of the review carry their own append-only history, so the trail from "what we saw" to "what we changed" survives an audit. For regulated teams this record is the point of the exercise.

9. Adjust the controls, then close. Decisions with dollar consequences usually land in budgets, limits and enforcement: tighten a budget, convert an alert-only rule to enforcing, add a restrict-models rule for the workload the model-mix review identified. Then let the next period run.

Cadence and drift

Monthly reviews suit the AI Tax's monthly trend; teams moving fast on AI tooling sometimes run the exception list fortnightly and the value story monthly. Watch for drift between reviews rather than re-litigating each one: an attributed share that stops improving, a cache hit rate that decays as prompts change, a model mix that creeps back after a migration. The AI Governance overview covers the report suite; the rollout guide covers getting to the point where this review has data worth reviewing.