We didn’t lose control of our networks overnight – we traded it away, gradually, rationally, one technology decision at a time. And for most of that journey, the trade-offs made sense: cloud migration accelerated everything – resulting in lower costs, greater flexibility and faster deployment. The consequences were invisible, buried in architecture decisions that nobody flagged as risks at the time. AI has changed that – not because it introduced a new problem, but because it made an old one impossible to ignore.
Everyone reaches for bandwidth first
When enterprise networks start struggling under AI workloads, the instinct is immediate and familiar: buy more bandwidth. This is understandable as it’s the lever teams have always reached for. Traffic grows, circuits get upgraded, and the problem is solved. This worked for SaaS, it worked for video conferencing, and worked through two decades of steady, predictable traffic growth. But this approach doesn’t work for AI.
AI doesn’t spike traffic – it resets it permanently. Baseline demand lifts by 20–50% following AI rollout. Traffic between internal systems doubles or triples. Short bursts, sometimes as brief as five minutes, overwhelm circuits that look perfectly healthy on average utilisation dashboards. But the real issue isn’t capacity – it’s latency. Within these burst patterns, latency becomes unpredictable, even when bandwidth appears sufficient. Performance degrades not because the network is full, but because it can no longer guarantee consistent outcomes. Just adding bandwidth is becoming the most expensive way to solve the wrong problem.
The Network Control Model
To understand why bandwidth alone fails, you have to understand how enterprise networks have actually evolved, and what has been quietly lost along the way. I think about this through what I call the Network Control Model. MPLS networks (private, managed circuits that were once the enterprise standard) were expensive and rigid. But they were predictable. You knew exactly where every packet went because performance was engineered end-to-end. Every path was known and every outcome was predictable. Control was total, centralised, and deliberate. CIOs who managed networks in this era understood exactly what they had, and exactly what they were paying for.
When SaaS arrived, enterprises made a rational decision: move traffic onto the public internet and cut the cost of private circuits. Predictable performance was traded for economic scale. As a result, costs dropped and flexibility increased. But traffic left the private network and disappeared from enterprise visibility. You could no longer see where it went, how it performed, or what was competing with what. The perimeter dissolved. Control didn’t disappear immediately, but it started leaking.
The shift to cloud fragmented things further. Compute scattered across providers and regions. Traffic between workloads running in different clouds exploded. There was no longer a single control layer to manage from. Visibility fractured across tools that didn’t talk to each other – and costs became harder to attribute. But fragmentation didn’t just increase complexity, it made predictable performance impossible under the existing model.
Each of these decisions (SaaS adoption, internet breakout, cloud migration) was correct in isolation. Yet together, they dismantled the thing that made networks reliable: engineered control. AI didn’t create the problem – it has exposed it. Latency-sensitive AI workloads arrived into networks already running on borrowed time. Unpredictable burst patterns overwhelmed circuits designed around averages. Cloud data transfer costs escalated without clear cause. And for the first time, the network could no longer absorb the consequences.
Most enterprises are in the wrong state for AI workloads.
The Network Control Model maps enterprise networks across three states. Engineered networks deliver predictable performance with full end-to-end visibility, architecture designed deliberately for what it carries. Traffic is steered by policy, performance is predictable and costs are understood.
Managed networks have partial visibility and reactive controls. Teams are on top of today’s problems, mostly. But the architecture wasn’t designed for what it’s being asked to carry, and tomorrow is one traffic spike away from crisis.
Reactive networks run you. Congestion is discovered when users complain and bandwidth gets purchased under pressure. AI initiatives stall not because the technology is wrong, but because the network underneath can’t support what’s being asked of it.
This is where AI finds most enterprise networks today. Not because the teams managing them failed – but because the architecture was never redesigned to keep pace with what it was being asked to carry.
What rebuilt control actually looks like
The path forward isn’t back to MPLS, that world is gone and returning is not an option. MPLS does not extend into cloud or SaaS environments, and as a result cannot meet the distributed, latency‑sensitive demands of AI. The leading enterprises I speak to are doing something else: re-engineering control deliberately, at the network level, for the demands that AI places on infrastructure.
That means end-to-end visibility: knowing where traffic goes, how it performs, and where pressure is building before users feel it. You cannot control what you cannot see. So, the required approach needs dynamic traffic steering, the ability to route AI workloads intelligently across paths based on latency, performance, and cost in real time. It also means designing for diversity upfront, using multiple carriers and routes so capacity can shift as conditions change, rather than being locked into rigid, single‑carrier contracts. Finally, it requires a clear view of the cost consequences of every routing decision, particularly around cloud data transfer charges, before they surface as unexpected line items on the bill.
The question every CIO should ask is not which state they believe their network is in, but which state it demonstrably is in. Can you see end-to-end traffic performance in real time? Can you steer AI workloads to the right path without manual intervention? Do you know what your network will look like under the AI demand your organisation is planning in the next eighteen months? If the honest answer is no, the time to act is now.
Enterprises that treat this as a bandwidth problem will keep reacting. Those that treat it as a control problem will define what enterprise networking looks like for the next decade. The difference is not technology, rather it is the decision to re-engineer deliberately, rather than upgrade reactively. This is what practitioners are beginning to call the Deterministic Internet: predictable, policy-driven performance delivered at internet scale, across cloud, SaaS, and on-premise environments alike.
