How AI impacts global network operations, not just performance
Most of what gets written about AI and networking is about data center infrastructure: the fabrics and facilities being built to train and serve models at enormous scale. If you run a global enterprise network spanning plants, warehouses, offices, and field operations across forty countries, almost none of it applies to you. But that doesn’t mean AI has no impact on your network. AI workloads are changing what enterprise networks carry, where they carry it, and how tolerant the business is of degradation. That combination changes how these networks need to be operated, which I’d argue is the more important shift, and the one getting far less attention.
Inference is the traffic that matters
For a distributed enterprise, the AI traffic that impacts the network is inference: users sending prompts and context to models and getting responses back. Training lives inside the data centers of the model providers, while inference traffic can be found everywhere.
This traffic behaves differently from what most networks were sized and designed for. It’s unusually upstream-heavy, because documents, images, and context flow from the endpoint to the model, which cuts against the asymmetric assumptions baked into most access connectivity. Users notice delay in a way they don’t with ordinary web applications, because they’re typically mid-task and waiting on a response. And almost all of it traverses the Internet to cloud-hosted endpoints. The path from a factory in Vietnam to a model API is the same kind of path we’ve discussed throughout this series: local ISP, peering points, middle mile, cloud edge. As AI becomes embedded in daily workflows, that path becomes one of the most business-critical routes in the enterprise, usually without anyone formally deciding it should be. It may even change over time, as model providers build out new infrastructure and decommission older data centers.
Agents change the shape of this demand
The second shift is agentic AI: software performing multi-step tasks that previously required a person. The network implications are larger than you might expect; Cisco’s 2026 research on AI’s WAN impact found that handing a task from a human to an agent can generate up to 450% more network traffic for the same outcome, most of it inference, because the agent iterates, retrieves, calls APIs, and checks its work at machine pace rather than human pace.
Agents also fail differently. A human experiencing a slow application complains, retries, or works around it. An agent hitting a degraded path may time out, retry aggressively, produce a partial result, or just abandon a step inside a workflow nobody is monitoring. The traditional feedback loop for network problems, which was usually users telling the helpdesk that something is wrong, doesn’t exist for this traffic. If agentic workloads matter to the business, the network team needs to know about degradation before the workload does. That’s a monitoring objective that doesn’t even exist in most enterprises for human traffic.
Proximity starts to matter again
The third shift runs in the opposite direction. While general AI consumption pulls traffic toward cloud endpoints, a growing class of workloads is pulling inference toward the edge. Small language models and vision models have become remarkably capable, and Gartner projects that by 2027 organizations will use small task-specific models three times more than general-purpose ones. For enterprises in manufacturing, resources, and logistics, the drivers are practical: a vision model inspecting a production line can’t tolerate a round trip to a cloud region, OT data often can’t leave the site for regulatory or risk reasons, and a plant needs its AI-assisted manufacturing processes to survive a WAN outage.
This changes what a site is. A branch or plant stops being purely a consumer of centrally hosted services and becomes a (small) compute location again: local inference serving local processes, with the WAN carrying model updates, escalations to larger cloud models, and telemetry rather than every transaction. Most enterprises will land on a hybrid architecture, with routine inference running locally and complex reasoning escalating to the cloud. That split has consequences for how the network is designed – site-level resilience matters more, local breakout design matters more, and bandwidth sizing question becomes less about peak capacity and more about the right capacity, in the right direction, with the right amount of survivability, for each type of site.
None of this requires dramatic architecture decisions today. It does require that decisions being made today, on underlay provider contracts, site design templates, and security architecture, don’t rule out the adoption of these patterns tomorrow.
The operational model is what breaks
Networks have absorbed new traffic types before, and the industry is reasonably good at capacity. What AI workloads genuinely break is the operational model, because the methods most enterprises use to operate global networks were built around human-generated traffic, human-reported problems, and monthly reporting cycles. None of those assumptions apply in a future like I’ve described above.
Consider what operating this environment requires. You need to tell AI inference flows apart from general web traffic, because they now require different treatment. You need to learn usage and performance baselines per site, per path, and per workload class, because normal for an agent-heavy site doesn’t look anything like normal for an office, and a 40% traffic increase might be due to adoption or might be an agent stuck retrying failed requests. You need anomaly detection that works at this machine pace, because the most important consumers of the network are no longer users that will raise support requests. And you need correlation across layers, because when an agent workflow fails, the cause might sit in a local ISP, a peering point, an SSE, a hyperscaler’s cloud region, or the model provider itself. A team that can only see one of those layers will spend its time proving innocence rather than restoring service.
Most operations teams know they aren’t there yet. In EMA’s Network Management Megatrends 2026 study, only 35% of network professionals said their observability tools were fully ready to manage AI workloads. The gap won’t be closed by buying another tool. It gets closed through sustained discipline: integrating telemetry from underlay, overlay, security, and application layers, maintaining baselines, suppressing what doesn’t matter, and acting on what the data says. All of this needs to be done across hundreds of underlying providers and platforms that were never designed for these use cases.
Architecture advice and the incentive problem
One practical note on navigating all this. The right answers are layer-by-layer architecture decisions: where inference should run, how each class of site should be connected and protected, which traffic deserves engineered paths and which doesn’t. Enterprises will get recommendations on these questions from many parties, and most of those parties own infrastructure impacted by those recommendations. A provider whose business depends on their backbone will tend to find reasons why your inference traffic belongs on their backbone.
Our own view at Coevolve, and the reason we’ve structured ourselves to not own the underlying infrastructure we use for our clients, is that this moment in particular rewards independence. The optimum architecture for AI-era networks is still being worked out right now, site type by site type and layer by layer, and enterprises are best served by advice that has no asset to protect.
Where to start
The starting point is visibility: understanding what AI traffic is already on your network, where it goes, how it behaves, and what the business impact of its degradation would be. Most enterprises that look are surprised by what they find. From there, the architectural and operational decisions can be made deliberately rather than discovered during an incident. If you’re starting to see these patterns in your own environment, or suspect they’re there but can’t yet see them, that’s a conversation worth having, and we have the experience and toolsets to help with this.
