Intelai
AI Is Not a Utility Until It Has an Owner
The electricity analogy breaks on three things: model behavior changes on upgrade, output is not fungible, and the meter says nothing about correctness.
Every executive deck about AI eventually reaches the electricity slide. AI is becoming a utility, the slide says: invisible, foundational, metered, plugged in like power. The argument is that you do not build a power plant, so you should not build a model.
The advice is right. The analogy is doing damage, because it implies that a model call has the properties that make electricity easy to consume, and it does not.
Electricity is fungible and constant. A model is neither, and the difference is where the operating cost hides.
Where the analogy breaks
Three differences matter, and each one changes how you run the thing.
The first is that electricity does not change flavor. A kilowatt-hour from one supplier behaves like a kilowatt-hour from another, which is why you can switch suppliers on price. A model from one provider behaves differently from a model at the same provider one version later, and neither is wrong. The behavior changed, and every downstream process that depended on the old behavior is now untested.
The second is that output is not fungible. A kilowatt-hour is a unit. A summary, a classification, or an extracted field is an interpretation, and two runs can differ. That is not a defect to be fixed. It is a property that has to be designed around, with evaluation sets, thresholds, and a human path for the cases that matter.
The third is that the meter measures the wrong thing. Electricity billing tells you what you consumed. Token billing tells you what you consumed and nothing about whether the output was correct. The quality signal has to be built, and it is the most expensive part of the program.
What is actually utility-like
The parts of AI infrastructure that deserve to be treated like a utility are the boring ones, and treating them that way is genuinely valuable.
Routing, retries, and rate limits. Identity and access control, so you know which application spent the tokens. Quotas and cost allocation, so a team cannot quietly become the largest consumer. Logging of requests and responses, with retention that matches your policy. A gateway that every call passes through, so the policy is in one place instead of in eleven codebases.
Those are the same controls you would put in front of any external service, and building them once is how an organization avoids the sprawl of every team integrating a different provider with its own key.
The model itself is the part that does not behave like a utility. Put the gateway around it and treat the model as a component behind the interface. That is the design that survives a provider change.
The version problem
Model versions get deprecated. That is not a scandal, it is how software works, and it is the single most under-planned event in enterprise AI.
A pinned model version buys stability until the provider retires it. When that happens, the choice is to move to a new version and re-run your evaluations, or to keep a self-hosted copy and take on the operational burden. Both are legitimate. Neither is free, and neither is in the budget if nobody wrote it down.
The planning question is not "which model should we use." It is "what is our change process when the model changes, and who signs off on the new evaluation results." A team that can answer that has an AI platform. A team that cannot has a demo that happens to be in production.
The same logic applies to prompts. A prompt is configuration. It should be versioned, reviewed, and tested like configuration, because a change to a prompt is a change to system behavior whether or not anyone filed a ticket.
The data boundary decides the architecture
For regulated data, the utility metaphor runs into a wall that the electricity version never had.
You can buy power without telling the utility what is in your building. You cannot send a document to a model provider without considering where it goes, who can see it, whether it is retained, and whether the provider's terms permit training on it. For controlled unclassified information, protected health information, or anything under a data processing agreement, that consideration is the architecture.
There are three answers, and they are all valid depending on the data. Send it to a provider under a contract that satisfies your obligations. Send it to an environment you control, with the model hosted inside your boundary. Or do not send it at all, and run a smaller model on the data where it lives.
The mistake is treating the first answer as the default for every data type, because it is the easiest to procure. The classification comes first, and the deployment model follows it.
What infrastructure actually means
A utility is not a category of technology. It is a set of commitments: an owner, a service level, a change process, a cost model, and a fallback when it fails.
Apply that list to your AI capability and the gaps become visible.
Who owns the gateway, and who is on call when it fails. What the service level is for latency and availability, and what the application does when the call times out. How a model or prompt change is approved, and what evidence the approver sees. How cost is allocated and capped. What happens when the provider is down, and whether the fallback is a smaller model, a cached answer, or a human queue.
None of those questions are about intelligence. All of them decide whether the capability is dependable.
The electricity comparison is useful for one purpose: it convinces a budget holder that AI is not a series of experiments. After that, put it away.
A model is a component with a version, a cost, a failure mode, and a data boundary. The infrastructure around it is what makes it dependable, and the infrastructure is your work, not the provider's.
The organizations that get this right do not talk about AI as a utility. They talk about the owner, the service level, and the change record. That is a less inspiring slide and a much better system.