July 2026: Ramp's spend-management data, covered in explainx.ai's breakdown of surging enterprise AI token costs, found that average monthly AI token spend across its customers grew 13x from January 2025 to 2026 — "not 13%," Ramp's own post stresses, "thirteen times." The heaviest spenders see costs jump 50% or more in roughly one of every four months. If your organization's AI budget conversation still sounds like a normal software line item, it's already out of date.
Most executives are stuck between two bad defaults: rubber-stamping every AI proposal that shows a slick demo, or blocking all of them out of governance anxiety. Neither is a framework — both are reactions. This guide gives leadership teams a consistent way to evaluate AI proposals, decide build versus buy, and set governance that scales with cost growth instead of getting blindsided by it.
TL;DR — what leaders are actually asking
| Question | Direct answer |
|---|---|
| Is AI ROI even measurable given cost volatility? | Yes, if you measure against a specific outcome, not a fixed budget. |
| Build or buy? | Buy commoditized capability; build where the feature touches your proprietary data or workflow. |
| What's the biggest governance blind spot? | Treating AI that acts (agents) the same as AI that only responds (chat). |
| Why do costs spike unpredictably? | Agentic coding tools make far more API calls per task than chat usage — track by team, model, and use case. |
| Do I need to use these tools myself? | Yes — it's the fastest way to evaluate vendor claims critically instead of trusting a demo. |
Why the old ROI mental model breaks
A typical software ROI conversation assumes a fixed cost and a fixed benefit: license fee versus time saved. AI spend doesn't behave that way. explainx.ai's coverage of Ramp's enterprise AI cost data is blunt about why: usage-based pricing plus agentic tools that make many more API calls per task means the same team's bill can look completely different month to month, with no change in headcount or scope.
The fix isn't a bigger fixed budget — it's building attribution into every AI proposal from the start: which team, which model, which use case, and what the cost ceiling is before it triggers a review. A proposal without that structure isn't ready for approval, no matter how good the demo looked.
The build-vs-buy decision, simplified
Buy when:
- The capability is commoditized — general-purpose chat assistants, standard document summarization, off-the-shelf coding assistants.
- Speed to value matters more than differentiation — you need the capability now, not a defensible moat.
- A vendor's context (their training data, their integrations) is genuinely sufficient for the use case.
Build when:
- The AI feature needs your proprietary data or workflow context that no vendor has access to.
- The feature is core to your competitive advantage, not a supporting capability.
- You have (or are willing to build) the engineering capacity to maintain it — a build without maintenance capacity is a liability, not an asset.
Most proposals that fail this test aren't obviously wrong — they're build proposals dressed up as strategic necessity when a buy would work just as well, or vendor deals that promise differentiation a commodity product can't actually deliver.
A worked example
Consider a customer support AI proposal. A team pitching "build our own support AI" needs to answer: does this genuinely need our proprietary ticket history and product data to be good, or would a vendor's off-the-shelf support AI — trained on broad support patterns — perform close enough for a fraction of the build cost? If the answer is "our product is unusually complex and our historical tickets are the actual differentiator," that's a real build case. If the answer is "we just don't want to pay a vendor," that's not — buy, and redirect the engineering time saved toward something that does need to be built in-house.
The reverse mistake happens too: buying a vendor's "AI-powered" feature that's really just a thin wrapper around a general model, for a use case that touches your most sensitive proprietary workflow. That's the scenario where you've outsourced both the differentiation and the data governance to a third party, for a capability you could have scoped and built with tighter control.
A one-page evaluation template
Every AI proposal above your review threshold should answer these on one page, before a meeting:
| Question | Why it matters |
|---|---|
| What specific outcome does this change — hours, error rate, cycle time? | Replaces "AI initiative" vagueness with a measurable target |
| Build or buy, and why? | Forces the differentiation-vs-commodity judgment explicitly |
| What's the cost ceiling, and who's tracking spend by team/model/use case? | Prevents the 13x-style spend surprise from becoming a fire drill |
| Does this AI respond or act — and what's the human checkpoint before anything irreversible? | Applies the governance distinction below before approval, not after an incident |
| What's the fallback if the model is wrong or unavailable? | Separates a resilient proposal from a demo that only works in the happy path |
The governance question most leadership teams skip
explainx.ai's guide to what actually matters for business leaders draws a distinction worth repeating in every AI proposal review: when AI only responds, the failure mode is bad information a human can catch before it propagates. When AI acts — an agent that executes a task, writes to a system, or triggers a workflow — the failure mode is a wrong action with downstream consequences before anyone reviews it.
That's not a reason to avoid agentic AI. It's a reason to ask a different set of questions for it: What's the blast radius of a wrong action? Is there a human approval step before anything irreversible happens? What's logged, and who reviews it? A proposal that can't answer these isn't ready to move from responding AI to acting AI, regardless of the ROI math.
Why this distinction gets missed in practice
Most leadership teams don't miss this distinction because they haven't thought about AI risk — they miss it because the same vendor, the same internal team, and often the same budget line covers both a chatbot pilot and an agent that writes to production systems. The review process treats them identically because they arrived through the same channel. The fix isn't a new process for every proposal — it's a single gating question at approval: "does this AI only respond, or can it act?" If the answer is "act," the proposal needs an explicit human-approval checkpoint documented before sign-off, regardless of how small the initial rollout is.
Org design implications
Leading an AI-native organization isn't just approving the right proposals — it's structuring the org so good AI use is the default path, not a special initiative. That shows up in a few concrete ways: incentive structures that reward outcomes AI-assisted work delivers (not just "did you use the tool"), hiring signals that value judgment about when to trust AI output over raw tool familiarity, and a visible pattern of senior leaders using these tools themselves rather than only mandating their use. Teams read leadership behavior, not leadership memos — if executives visibly use AI for their own strategy work, adoption down the org chart follows faster than any policy document achieves alone.
What people are asking about AI ROI and governance
"Isn't cost tracking an IT problem, not a leadership one?" Attribution by team, model, and use case needs to exist before finance can even ask the question — and that requires a leadership decision about what gets tracked, not just a tooling purchase.
"How do we avoid analysis paralysis on every proposal?" Reserve the full build-vs-buy and governance framework for proposals above a cost or risk threshold you set in advance. Small, low-risk pilots shouldn't go through the same process as an org-wide agentic rollout.
"Do we need a dedicated AI governance committee?" Not necessarily a new committee — but someone needs explicit ownership of the acting-vs-responding distinction above, or it falls through the cracks between engineering, legal, and finance.
How explainx.ai runs this for leadership teams
This exact framework — hands-on AI literacy, ROI and build-vs-buy evaluation, and governance for acting AI — is the curriculum behind explainx.ai's leadership upskilling program, delivered as executive briefings or private cohorts, with a free team assessment that emails a short readiness report based on where your leadership team is today.
Related on explainx.ai
- AI token costs surge: enterprise finance and governance — the Ramp cost data behind this framework
- AI for business leaders: what actually matters in 2026 — the acting-vs-responding governance distinction in full
- Technical AI concepts for business leaders — the literacy layer beneath this framework
- AI for HR professionals — org-design and people questions for AI-native teams
- Corporate AI training — facilitator-led programs across 25+ industries
- Nadella Reverse Information Paradox — enterprise trust boundary — why owned evals and orchestration are the moat
- How to build your own enterprise AI benchmark — charter, golden tasks, harness, compound loop
- geohot — frontier labs may not capture AI value — commodity models + owned evals as the real moat
- AI mania is eviscerating decision-making — Ludicity / Hermit Tech (Jul 2026) — token leaderboards, demo frenzies, and why mandates fail
Official: Ramp: the $1 trillion AI spend blind spot
Cost figures cited from Ramp's spend-management data reflect its own customer base as of April 2026 — treat them as order-of-magnitude planning signals, not a guarantee for your organization's next invoice. Last updated: July 9, 2026.