More AI Isn’t the Answer. Efficient AI Is.

The AI tools available right now are genuinely capable. Claude Code works. The models being deployed across enterprise environments are not the bottleneck, and this piece is not an argument that they are. 

The bottleneck is the layer underneath them. 

When an AI tool queries data infrastructure that is ungoverned, inconsistently defined, or refreshing at a cadence that has nothing to do with how decisions are actually made, the tool performs exactly as designed — and every query costs more than it needs to, returns answers that require human validation before anyone can act on them, and erodes the productivity gain the tool was supposed to deliver. At enterprise scale, the budget ceiling arrives faster than the value does. 

The most consistent mistake I have seen organizations make in AI deployment is treating it as a tool selection problem. The tool gets evaluated carefully. The data layer underneath it does not. Procurement scrutinizes the model. Nobody scrutinizes the refresh frequency. 

Powerful tools pointed at inefficient infrastructure produce expensive outcomes at the same speed. The bill just arrives faster than it used to.

Here is what we actually did. And more importantly, what we asked first. 

The initial estimate of $60,000 per month was what it cost to build the application without ever asking what it needed to do. Maximum model capability, high refresh frequency, LLM-powered search throughout because those were the defaults, not because anyone had checked whether the use case required them. We were treating the AI like a Swiss Army knife and paying for every blade whether we used it or not. 

The exercise of going back to the business outcome wasn’t a technical audit. It was closer to an interrogation. For each part of the architecture, one question: does this serve how decisions are actually made, or how we imagined they might be made? 

The answers were uncomfortable in the useful way. 

First: how often does the data actually need to be refreshed?

Not how often could it be refreshed, but how often does the decision-making this tool supports actually require fresh data? The answer was less often than we had assumed. A lot less. Refresh frequency had been set for a theoretical worst case that never materialized in practice. Reducing it did not compromise the application. It removed a cost that was never earning its keep. 

Second: which data needed to be refreshed at all?

Once you stop treating the entire data environment as equally time-sensitive, the picture changes quickly. Some data was stale the moment it arrived and nobody was using it. Some was critical. Nobody had drawn that line before deployment. 

Third: where was AI doing work a simpler tool could do just as well?

The question makes people uncomfortable, because the honest answer feels like admitting AI wasn’t needed. That reading misses the point. Reaching for a large language model to run a retrieval task a keyword index handles perfectly isn’t sophistication. That’s an expensive habit. 

Fourth: where was model complexity adding value, and where was it just adding cost?

Not every step in an AI workflow requires a frontier model. The question is not “what is the most capable model available?” The question is “what is the minimum capability required to produce a trustworthy output here?” 

Monthly cost after those four questions got honest answers: $6,000. With room to spend less. 

None of those were architectural decisions. They were deployment decisions, the kind that get made in the first week if someone asks or get discovered in month six if nobody does. 

Three decisions consistently separate organizations that get compounding value from AI from organizations that get compounding cost. 

The first is knowing specifically what the AI is being asked to do before it is deployed. Not in general terms. Which queries. Which data sources. Which refresh frequency. Which decisions is this tool actually supporting, and how often are those decisions made? The organizations that answer these questions before deployment spend a fraction of what organizations that answer them after deployment spend. From an enablement perspective, this is the conversation that almost never happens before a tool goes live. It happens six months later, when the bill is already large. 

The second is matching model complexity to task complexity. AI tools are increasingly capable of doing nearly everything. That does not mean they should. Standard API calls, simpler models, cached results, and reduced refresh frequencies are not compromises. They are correct engineering decisions when the use case does not require the overhead. The instinct to always use the most powerful available tool is natural. In AI infrastructure, it is expensive. 

The third is the data layer itself. Think of it like hiring a team of analysts and then giving them conflicting spreadsheets to work from. They will produce answers, fast ones, but you will spend as much time checking their work as you would have spent doing it yourself. When the same business concept is defined differently across data sources, that is exactly what happens to an AI tool: it reconciles the inconsistency at query time, or it returns an answer that looks confident but requires human validation before anyone can act on it. A data layer built on consistent, governed definitions does not just reduce cost. It removes the validation overhead that quietly erodes most of the efficiency gain the tool was supposed to deliver.  

Strategy Mosaic, Strategy Software’s universal semantic layer, is where those three decisions become structural rather than tribal. It maintains a single governed source of business definitions, metrics, KPIs, hierarchies, that every AI tool in the environment queries from. When model complexity, refresh frequency, and data governance are aligned at the semantic layer before deployment, the efficiency conversation happens once, not repeatedly across every tool, team, and budget cycle.  

AI infrastructure efficiency, according to Strategy Software, is the alignment of model capability, data refresh frequency, and governance to the actual decisions the tool supports, not to theoretical maximum use. 

Three questions that should be answered before any AI tool goes live at scale: 

1. What is the actual decision cadence? 

What is the data refresh frequency, and does it match the actual cadence at which decisions are being made? If the answer requires asking five people who each give a different number, that is the infrastructure problem, visible in advance. 

2. Where is the AI doing work a simpler tool could do? 

Map the queries. Not every step in an AI workflow needs a frontier model. The ones that do not are costing money without adding capability. 

3. Are the definitions consistent across every data source the AI touches? 

An AI tool querying inconsistent definitions returns fast answers that require slow validation. That is not efficiency. It is the illusion of efficiency with the costs deferred. The validation time does not disappear. It moves to a human, at the most inconvenient possible moment. 

These are not architectural questions reserved for CTOs and data engineers. They are enablement questions. Any team responsible for making AI work in their organization can ask them. They should be asked before the infrastructure estimate comes back. 

The AI budget conversation is coming for every organization running AI at scale. Uber’s disclosure made a private pattern public. The organizations that are prepared for it are not the ones with the best tools. They are the ones that asked the efficiency questions before the bill arrived. 

Uber’s experience is not a warning about Claude Code. It is a warning about what happens when the infrastructure conversation is deferred until after deployment. The tool did exactly what it was designed to do. The architecture was not designed to make that work efficient. 

The fix is not a better tool. It is infrastructure that is honest about what it is being asked to do: consistent data definitions, appropriate refresh frequencies, model complexity matched to task complexity, and a governed data layer that ensures every dollar of AI spend is spent on a question worth asking. Strategy Mosaic, the universal semantic layer, provides that foundation: a single governed source of definitions that every AI tool in the environment queries consistently, so the efficiency conversation happens at the data layer, not at the model bill.