Runtime governance loses budget fights for a predictable reason. The person asking for it describes a control, and the person holding the budget hears a tax on a program that is already behind schedule. The request competes against features, and features win.
The case that survives a budget committee is not a risk case. It is a case built on spend that already exists, obligations that already exist, and a delay that is already costing something. This page sets out that case, the numbers to gather before the meeting, and the three objections that reliably come back.
Start with the spend that is already happening
Before arguing for new money, account for the money already moving. In most enterprises of any size, AI spend has arrived through several doors at once: model provider invoices on engineering cards, seat licenses for assistants bought by individual departments, cloud inference on existing commitments, and consultants building agents against all of it.
Three figures change the conversation, and all three are usually obtainable within a week.
Total model provider spend, by team, for the last two quarters. Pulled from billing rather than from what teams report. The gap between those two numbers is itself an argument.
Count of distinct AI tools with access to production data or systems of record. Not a count of approved tools. A count of actual ones. This number is routinely higher than the CIO's estimate, and the delta is the finding.
Spend not attributable to an owner. Every dollar here is a dollar the company cannot govern, forecast or turn off.
That third figure is the wedge. A finance function that cannot attribute spend has a control weakness independent of any AI risk argument, and it is a weakness finance owns. Shadow AI discovery is usually where these numbers come from.
The four arguments, ranked by how well they travel
1. Cost control on spend that is growing without a brake
This argument travels furthest because it does not require the committee to accept a risk premise. A control point in the call path is also the only place where model spend can be attributed, capped and optimized, because it is the only place that sees every call.
Three mechanisms do the work. Per-team model allowlists and denylists stop a team from reaching for a frontier model when a smaller one serves the task, which is the largest single source of avoidable spend in most estates. Budget enforcement at the control point turns a monthly surprise into a hard limit. Semantic caching removes repeat inference for requests that are substantively the same, which matters most in the high-volume internal use cases where the same question arrives hundreds of times a day.
The honest framing: these mechanisms reduce spend by an amount that depends entirely on the estate's current discipline, and the size of the reduction is the strongest argument in undisciplined estates and the weakest in well-run ones. Measure before promising. Our cost optimization material covers the measurement approach.
2. An obligation with a date on it
Regulatory deadlines convert a discretionary project into a scheduled one, which is a different budget category. The specifics depend on jurisdiction and sector, and the value of this argument is entirely in the specificity.
For firms in scope of the EU AI Act, the obligations attach to a classification the firm performs on its own systems, so the first deliverable is the classification, not the control. For US financial institutions, the relevant obligations are older than AI and apply anyway: SR 26-2 on model risk, which excludes generative and agentic AI from its scope and returns the governance determination to the institution, FINRA Rule 3110 on supervision, NYDFS Part 500 for New York covered entities, and GLBA on customer information. Healthcare organizations face the HIPAA Security Rule without any AI-specific amendment being necessary for it to apply.
The argument is not that a regulator will impose a penalty. It is that an existing obligation now has a new surface, the firm cannot currently evidence compliance on that surface, and the examination cycle has a date.
3. The deal that is blocked
The most persuasive number in the room is usually revenue that is already stalled. Enterprise procurement and security review increasingly ask AI-specific questions, and the answers are supplied by the governance program. Where a customer requires third-party attestation rather than a questionnaire response, ISO/IEC 42001 certification is the usual ask, and certification has a lead time that a budget committee understands.
If a named account is waiting on an answer the company cannot give, that account belongs in the request, with the deal value and the date it was raised.
4. The incident that has not happened yet
Put this last. Committees discount it, correctly, because every project claims it. Where it earns its place is in specificity about a failure mode the existing security program genuinely does not cover.
Two qualify. Indirect prompt injection arrives inside content an agent was legitimately asked to process, so the attacker never authenticates and the perimeter is never crossed in any sense the existing stack recognizes. Data poisoning attacks the corpus rather than the system, which places it outside the scope of every runtime control the firm currently owns.
If the CISO agrees that neither is covered today, the argument has a sponsor. If the CISO disagrees, the argument has a problem and it is better to find that out before the meeting.
The three objections
"We already have an AI gateway." Usually true, and usually a routing and cost tool rather than a control point. The discriminating question is whether the existing gateway can refuse a request on policy grounds, and whether the refusal produces a record an examiner would accept. The comparisons with LiteLLM and Portkey set out where that line falls in practice.
"Our cloud provider handles this." Partly true within one provider's models and not true across an estate that uses several, plus the assistants bought by departments and the agents built by consultants. The scope of provider-native controls is the scope of that provider.
"We will add controls once the use cases are proven." This is the objection that costs the most, because agents accumulate authority quietly and retrofitting a control point means changing every integration that was built without one. The counter is not a warning. It is the current count of integrations, and the same count projected two quarters forward.
What to ask for
Ask for a scoped phase with a measurable exit, not a platform. A defensible first phase covers one business unit, produces the attributed spend figure and the tool inventory, and enforces one policy that everyone agrees on. The exit criterion is a document: the enforcement record for that policy over thirty days.
That document is what funds phase two, and it is also the first section of the board report.
Related reading
Cost optimization · Board reporting · EU AI Act · AI governance FAQ · Glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs