The SaaS model is cracking. Not slowly, and not quietly. Enterprises are waking up to the fact that the subscription software era, built on predictable seats, annual renewals, and feature roadmaps, was not designed for the pace or the cost structure of AI. Budgets that made sense twelve months ago look different when you are paying for tokens instead of licenses, and when every team in the building has quietly shipped an agent of their own.
Before we get into how to fix it, the honest question worth asking is: do you actually know if you are getting value from your AI investments? Do you know which AI tools your organization is running right now? Do you know which tasks they are being used for, what they cost per interaction, and whether any of them are producing outcomes worth the spend? For most enterprises, the answer to at least one of those questions is no. That is not a technology problem. It is a governance problem, and it is more common than anyone wants to admit publicly.
The RFP Is not built for this
Traditional enterprise procurement was designed for a world of deterministic software. You evaluated a vendor, ran a proof of concept, scored a matrix, and signed a contract. The process was slow, but it was defensible. It created paper trails, reduced risk, and gave legal and finance something to stand behind.
AI vendors, especially the ones building genuinely differentiated capabilities right now, are not always equipped for that level of presales rigor. Some of the most important infrastructure getting built today comes from teams that will not survive a six-month procurement cycle. The risk of a slow evaluation is real. The risk of inaction, of watching faster organizations lock in strategic AI partnerships while you are still in discovery, is also real, and in most cases larger.
The answer is not to abandon diligence. It is to develop a faster, lighter evaluation framework actually built for how AI tools work: probabilistic outputs, token-based costs, model routing complexity, and governance that travels with every deployment. The organizations building that muscle now are the ones who will move with confidence later.
The instinct to build
Here is the question most AI budget conversations are not actually asking: do you know whether your organization is getting value from its AI investments? Not in the abstract, but specifically. Do you know which tools are running, which tasks they are handling, what each interaction costs, and whether any of it is moving a metric that matters? For a lot of enterprises right now, the honest answer is no, and the build-versus-buy decision gets made anyway.
In regulated industries especially, there is a strong pull toward building proprietary AI. Control and compliance are real concerns. But purchased AI tools succeed roughly 67% of the time, compared to 33% for internally built alternatives, according to MIT's NANDA research. The gap consistently comes down to three things internal builds underestimate: model lifecycle management, ongoing evaluation and retraining, and cost discipline at scale. When you cannot clearly answer whether an existing AI investment is working, building another one is not a strategy. It is a bet on top of a blind spot.
The deeper issue is that enterprises often conflate control with strategic differentiation. Building proprietary AI only makes sense when ownership creates compounding advantage over time, when the use case is so specific to your data, your customers, or your operations that no vendor can replicate it. Everything else is engineering cycles spent on something the market will commoditize regardless.
The mental model I use: own what differentiates, rent what commoditizes. Foundational model hosting, commodity productivity tools, general-purpose copilots, keep those flexible. Redirect your engineering capacity toward the AI that is genuinely yours to build. And before you do either, make sure you can actually measure the outcome.
Agent sprawl: The new shadow IT
The build-versus-buy question does not play out in isolation. It compounds across every team simultaneously. 63% of executives now cite platform sprawl as a growing concern, and the pattern is recognizable to anyone who has walked into a federated enterprise. The HR team buys an AI recruiting tool. Sales builds something on their own stack. Marketing wraps an existing SaaS product with a custom layer. The internal IT team spins up a ticket resolution agent over a weekend and integrates it into Slack.
Each of those decisions was made with good intent. Collectively, they create a fragmented AI estate where capabilities overlap, costs go untracked, governance is inconsistent, and the user experience varies based on which tool a given team happened to adopt. It is the AI version of shadow IT, moving faster and carrying higher costs than anything that came before it.
The trajectory ahead makes this more urgent. Gartner projects that by 2028, 33% of enterprise software applications will have built-in agentic capabilities, up from less than 1% in 2024. Most organizations have not built the governance infrastructure to manage the agents they have deployed today, let alone what is coming. The question worth asking is not whether sprawl exists in your organization. It almost certainly does. The question is whether anyone has the mandate and the framework to address it.
The answer to that question is architectural. Sprawl is a data problem as much as it is a procurement problem. When agents are deployed without a shared data foundation, they pull from inconsistent sources, produce contradictory outputs, and create governance blind spots that multiply with every new deployment. The same principle that applies to data infrastructure applies here: you cannot govern what you cannot see, and you cannot consolidate what you have not inventoried. A centralized function that owns the foundational layer, the data architecture, the governance standards, the evaluation criteria, and the approved stack that teams build on top of, is what creates the golden path. It does not slow teams down. It gives them something reliable to build on.
High productivity and contained sprawl are not competing goals. They look that way when there is no architecture behind the AI program. With clear build-versus-buy criteria, standardized evaluation, and a governance model that travels with every deployment, you can move fast without fragmenting the estate.
Customer zero as a governance model
One of the most underused tools in AI program management is something that sounds obvious: using your own platform internally before recommending it externally. We call this Customer Zero thinking, and its value is less about sales credibility than it is about operational discipline.
When a centralized function runs Customer Zero programs, it becomes the incubator for the whole enterprise. Internal teams get access to vetted, governed AI tools. The centralized team gets real-world signal on what works, what breaks, and what costs more than expected before any of that reaches a customer. Governance gets tested under actual conditions rather than theoretical ones.
This is how you close the loop between procurement and value. You stop asking whether an AI tool has good features and start asking whether it holds up when your own people depend on it. Tools that create drag internally will create drag for customers. Tools that drive measurable productivity gains internally carry a credibility no demo can replicate.
The enterprises that come out of this period well will not be the ones who moved the fastest. They will be the ones who built the criteria, the governance, and the operational discipline to make AI choices that compound over time. Two decades of software buying habits built something durable. AI requires something different, and the window to build it is now.
