The Hardware Gap: Why AI's Winners Will Right-Size Their Data

Every physical input to enterprise AI is now constrained. Gartner projects that 40 percent of AI data centers will be power-constrained by 2027, with grid approvals in major markets running two to three years. In the first months of 2026, more than 75 data center projects worth $130 billion were blocked over power and water concerns. Data center water consumption is projected to reach hundreds of billions of gallons annually by 2030. And each chip generation makes it worse: a rack of AI servers that drew 10 to 15 kilowatts a few years ago now approaches 150 in the newest designs.

The industry's answer is to build more of everything. Executives waiting on that buildout should know that technology has hit walls like this before, and the companies that won did not wait for capacity. They shrank the payload.

160 characters and a pager network

Text messaging did not get new spectrum. When GSM engineers designed SMS in the 1980s, they noticed that the network's signaling channels, the control plane that sets up calls and manages handoffs, had spare capacity between operations. So they fit an entire messaging medium inside it: 140 octets per message, which is where the famous 160-character limit comes from, seven-bit characters packed into space the network already had. One of history's most profitable communication services ran on capacity everyone else considered overhead.

BlackBerry made the same bet even more aggressively. Its early devices ran on two-way pager networks with single-digit-kilobit throughput, bandwidth that made real email look impossible. RIM's answer was ruthless data discipline: server-side compression, emails truncated to their first couple of kilobytes with the rest fetched only on demand, attachments held back until explicitly requested. Executives got what felt like full email in their pocket a decade before smartphones, because RIM treated every byte as a cost and engineered the payload down to what the decision actually required.

Ten channels in the space of one

Cable television faced the same physics. A coaxial plant has fixed usable spectrum, and an analog broadcast consumed a full 6 MHz slice per channel. When demand for channels outgrew the wire, the industry did not dig up every street in America to lay fatter cable. It went digital: MPEG-2 compression squeezed a standard-definition stream down to a few megabits, and quadrature amplitude modulation packed roughly 38 megabits into that same 6 MHz slice. Ten or more channels now traveled where one had, on the same physical wire, because the industry re-encoded the payload instead of waiting for new infrastructure.

When physics caps the pipe, the winners shrink the payload. The losers wait for a bigger pipe.

The AI translation

Enterprise AI is at the same wall, and the prevailing advice is to connect everything: every system, every archive, every table, on the theory that more data means better answers. Notice who gives that advice. Companies that sell storage, compute, and per-token inference have an arithmetic interest in the volume of data you process. More data is better, for them.

For the enterprise, more data is mostly more noise, more overhead, and more cost. An AI system retrieving across an ungoverned everything inherits every duplicate customer record, every conflicting metric definition, every stale table nobody decommissioned. The answers come back fluent and wrong. And then the expensive part happens: when millions of dollars hang on an output nobody can trace, checking it becomes a manual reconciliation project. The technology that promised faster decisions quietly lengthens time-to-decision, because trust was never engineered into the pipeline.

Right-sizing is the discipline

The alternative is the SMS move, applied to data. Start from the business questions that actually carry value. Identify which data genuinely helps answer them, and organize that data so its definitions hold and its lineage is provable. Let the AI draw from governed, curated sources, and know at all times which sources feed which answers and which training sets are used for what. That knowledge is what foundational data infrastructure is: not a bigger pipe, but an engineered payload.

The payoff mirrors the history. Better governance produces answers leadership can trust without manual reconciliation, which is where time-to-decision is actually won. Smaller, cleaner retrieval surfaces cost less to run in an era of constrained compute. And when the hardware gap eventually narrows, the companies with right-sized foundations will scale into that capacity cleanly, while everyone else scales their noise.

At Standard North, this is the whole premise of our work: the SNARS™ Evaluation measures whether your data foundation can support what you're building, and our remediation right-sizes the foundation so what you feed the model is exactly what the business question requires. The hardware gap is real. The response to it is engineering discipline, and it starts below the model.