Enterprises have spent the past two years writing large checks for AI models, compute, licenses and GPUs. The investment wave has been extraordinary, driven by the belief that access to the most capable models and the fastest hardware would translate directly into business results. Yet a growing number of organizations are running into a stubborn problem: they cannot reliably access what they just built.

When expensive AI workflows collapse, it is tempting for leaders to assume the model is at fault. The model may be fine. The blame often lies elsewhere. Many organizations consistently underestimate the connectivity requirements beneath their AI strategy, and that blind spot is becoming more expensive as deployments move from controlled pilots into global production.

Recent research paints a clear picture of the strain. Fifty-nine percent of organizations now report bandwidth issues, up from 43% just a year ago. Latency challenges have nearly doubled, rising from 32% to 53%. Enterprises are paying for that gap in performance, in user experience and often in unnecessary spending aimed at the wrong part of the technology stack.

What the numbers show

• 59% of organizations report bandwidth issues, up from 43% a year earlier.
• Latency challenges have risen from 32% to 53%.
• A typical AI agent can generate up to 450% more total network traffic per task than a human performing equivalent work.
• AI traffic is distributed, bursty, concurrent and generated at machine speed rather than human speed.
• Bigger circuits do not automatically solve latency, jitter, packet loss, congestion routing or security inspection delays.
• Performance must be measured in the hardest geography, not only in the best one.

Those figures are not abstract. They point to a structural mismatch between how enterprise networks were designed and how AI applications actually behave. The network was once a background utility. In AI deployments, it becomes part of the product experience.

Addressing a data movement problem, not a compute problem

An AI conversation from two years ago and an AI conversation today would be almost unrecognizable. The market has moved from asking whether the technology is real to declaring full commitment and demanding that it work. For much of that shift, the dialogue has understandably centered on model structures, training techniques, parameter counts and benchmark scores. But a model is only as effective as the infrastructure connecting it to users, applications, agents and the other models on which it depends.

Enterprise AI is increasingly bogged down by data movement problems. Traditional enterprise networks were built around a predictable human transaction: someone searches for something, the system fetches it, and the transaction ends. AI breaks that pattern entirely. A single AI agent may call a model, retrieve enterprise data, invoke an API to another system, trigger a second model and return a synthesized result. Each step adds traffic, and each handoff adds delay.

That is not simply more traffic. It is a different kind of traffic: distributed, bursty, concurrent and generated at machine speed rather than human speed. A successful AI pilot may prove that the model works, but it does not prove that the enterprise can run it at scale. The pilot environment often hides the very conditions that determine production performance.

This pattern has been observed in live network projections at industry events, where engineers watched agentic workloads generate traffic spikes that looked nothing like the human traffic patterns their infrastructure was designed around. It was not a hypothetical exercise. The shift was visible in real time, showing how machine-driven workflows can concentrate demand in ways that traditional capacity planning does not anticipate.

The same story plays out every day across large enterprises rolling out AI strategy. In the initial environment, the system performs exactly as expected. Users are close to the cloud region, bandwidth is ample and usage remains modest because the organization has not yet fully adopted the tool. Everyone declares success. Then the deployment goes global.

Employees in Latin America, parts of Asia or Africa suddenly see dramatically slower responses. The instinctive conclusion for many leaders is that the AI platform itself is underperforming, so the logical response is to spend more. That means more compute, more licenses and more capital expenditure aimed at expanding the platform. But that can be the wrong lever.

When the full end-to-end transaction is examined, the model usually is not the problem. Consider the extraordinary scale of AI traffic as it moves from a branch office to a centralized security stack, then to a cloud region, then to a data-hosted backend somewhere else. Add inconsistent local internet performance, packet loss and congestion, and the AI experience deteriorates. The model may still be producing excellent output, but the user never experiences it that way.

The challenge also varies widely depending on where in the world the user is standing. At an AI symposium in Africa, attendees might have been expected to discuss which model to use, but the conversation instead focused on how to actually deploy the technology. In Latin America, the discussion heard most often from customers is not about raw bandwidth but about latency, specifically because of how the region’s infrastructure routes traffic back to major cloud regions. Silicon Valley and São Paulo are not the same infrastructure conversation, and treating them as though they were is exactly how well-intentioned rollouts stall.

This is not because the model got worse. It is because everything underneath it was never built to carry this kind of load across this kind of distance. When an AI application performs poorly, the instinct is to look up the stack. The answer is often underneath it.

Why a bigger pipe does not fix the problem

Bandwidth and latency may get treated as the same problem, but they are not. Bandwidth is volume, and AI increases it because organizations are moving richer data such as documents, images, video and telemetry. Latency is time, and it is where the harder problem lives.

AI workflows are chained. An agent calls a model, retrieves enterprise data, invokes an API to another system, and that system may call another model in turn. The cumulative delay across that chain is not predictable because no one knows in advance what will be asked or how far the request must travel. A request that feels instant in a lab can become sluggish when it crosses multiple regions, security layers and service boundaries.

That is why simply buying a bigger circuit does not solve the problem. Compute or GPU availability are not typically the bottleneck. What matters are congestion routing, packet loss, jitter and where security inspection happens along the path. Each of those factors can add time, and together they can turn a sophisticated AI workflow into a frustrating user experience.

Even hyperscale cloud infrastructure does not eliminate this. The system’s speed depends on whether a request can traverse the full chain, from user to network to security to execution and back, without the delay compounding at every hop. When customers are certain that a major cloud provider must be the bottleneck, the infrastructure on their end is rarely the issue. If anything, the cloud infrastructure is usually excellent because that is what it is built to deliver.

The real question is whether a request can survive the full round trip: from user, through the network, through security inspection, out to the cloud infrastructure and back again, without losing time at every handoff. As compute continues to improve, the path to accessing it becomes an increasingly important part of the performance equation. The fastest model in the world cannot compensate for a network path that adds delay at every stage.

Questions before spending another dollar

There is no one-size-fits-all fix, but there are questions every leader should be able to answer before scaling an AI deployment.

• Where do AI users, models and data sit: locally, regionally or centrally?
• What is the data sovereignty picture, and can traffic legally and technically move across the regions the rollout depends on?
• Are teams assessing the actual end-to-end network conditions experienced by AI users, including latency, jitter, packet loss and routing, or relying on average network metrics that can conceal problems along specific routes or in particular locations?
• Do the team running the AI strategy and the team running the network infrastructure talk to each other, or are they operating in separate silos?
• What does performance look like in the hardest geography, not the best one?

Until leaders can answer those questions, they will struggle to scale, regardless of how well the pilot went. Enterprises risk spending billions on an elite racing engine and then trying to race it on a road never designed for that speed. They will not get the performance they paid for, not because the engine is wrong, but because the infrastructure underneath it cannot support what they are asking it to do.

AI strategy and network strategy can no longer be separate conversations. They must be elements of the same conversation from the very beginning. The organizations that succeed will treat data movement as a first-class design requirement, measure performance where users actually operate and align infrastructure investment with the real behavior of AI workloads rather than the assumptions of a human-centered network.

Source:Network World News