There’s a quiet assumption many of us have been carrying into AI projects. If performance is poor, if jobs take longer than expected, if costs climb faster than planned, the answer must be more compute. More GPUs. Bigger clusters. Faster accelerators.
Sometimes that’s true. Often, it isn’t.
It’s something else getting in the way. The network. Not because it’s broken, but because it’s been treated as a solved problem. And AI is very good at exposing problems we thought we’d already dealt with.
AI workloads behave differently. They move data sideways, not just north–south. Training and inference generate intense east–west traffic between GPUs. Latency spikes that were once tolerable suddenly matter. Congestion that used to be rare becomes constant background noise. The network stops being invisible, and starts shaping outcomes.
That shift is uncomfortable. Especially if you’ve invested heavily in compute and expected the rest to keep up.
What’s emerging, though, is a fairly consistent pattern. In enterprise environments, AI performance is now constrained less by raw processing power and more by how well data moves between systems. The research behind AI Strategy 2025–2028: The Ethernet Advantage makes that point clearly, even if it doesn’t quite say it so bluntly.
And it raises a more awkward question: have we been optimising the wrong thing?
Why this is happening now
AI has moved out of pilot mode. That’s obvious. What’s less obvious is what that does to infrastructure design.
Once AI becomes part of core operations, you stop dealing with isolated workloads. You get overlapping models, mixed accelerators, different teams running jobs at different times for different reasons. The environment becomes messy. Realistic. Human.
In that setting, networks designed for predictability struggle. Fixed assumptions about traffic patterns no longer hold. And if you’re running multiple fabrics, one for traditional workloads, another for AI, the operational drag starts to show. Skills gaps matter. Complexity compounds. Small issues become systemic.
This is where Ethernet quietly re-enters the conversation.
Not as a compromise, which is how it was sometimes framed in the past, but as a stabilising force. Open standards. A deep talent pool. Familiar operational models. And, increasingly, performance characteristics that are close enough to alternatives that the trade-offs no longer look obvious.
There’s also a timing issue. AI infrastructure isn’t static. Very few organisations will build once and stop. Over the next few years, most will layer new capabilities onto what already exists. Brownfield and greenfield side by side. Networks that don’t tolerate that reality tend to become blockers.
What many teams still misunderstand
I think the biggest misunderstanding is treating AI networking as a specialised corner of the data centre. Something separate. Something you’ll “deal with later”.
That mindset made sense when AI was experimental. It makes less sense when AI traffic is almost guaranteed to show up on networks built today, whether you plan for it or not.
Another misconception is that performance alone should drive decisions. Latency numbers, throughput benchmarks, headline speeds. Those matter, of course. But they don’t tell you how a network behaves over time, under pressure, with partial failures, or when teams have to operate it day after day.
Operational reality matters. So does resilience. So does the ability to evolve without stopping everything and starting again.
The research hints at this when it talks about unified fabrics, live patching, telemetry, and real-time protection. Read between the lines and the message is fairly stark: AI infrastructure will break in new ways, and you won’t always get the luxury of downtime to fix it.
That changes what “good enough” looks like.
A quieter shift worth paying attention to
One detail that stood out to me is the growing emphasis on interoperability and longevity. Not as abstract ideals, but as practical necessities.
Most enterprises won’t standardise on a single accelerator or supplier forever. They’ll mix generations. They’ll test alternatives. They’ll inherit decisions made years earlier. The network sits underneath all of that, for better or worse.
Ethernet’s advantage here isn’t that it’s perfect. It’s that it bends without snapping. It allows incremental change. It tolerates heterogeneity. And it aligns with how organisations actually behave, not how whiteboard designs assume they will.
There’s also a human angle that doesn’t get enough airtime. Ethernet skills are common. Debugging tools are familiar. When something goes wrong at 2am, that matters more than benchmark charts.
What this means for IT leaders right now
If you’re responsible for AI infrastructure, the takeaway isn’t “rip and replace” or “standardise on X”. It’s more reflective than that.
It might be worth asking:
Are we assuming the network will cope, or have we tested it under realistic AI loads?
Do we understand where congestion appears, and how quickly we can see and respond to it?
Are we building something that only works for today’s models, or something that survives the next three hardware cycles?
And perhaps the hardest one: if AI performance disappoints, will we know whether the problem is compute, or will we just buy more and hope?
These aren’t technical questions so much as governance ones. They sit at the intersection of architecture, operations, and risk.
Ending where this really begins
AI will touch every enterprise, whether deliberately or indirectly. That part is no longer controversial. What’s still open is how much friction organisations are willing to tolerate as it scales.
The teams that do well won’t necessarily be the first to deploy the biggest models. They’ll be the ones that build infrastructure with enough slack, visibility, and adaptability to absorb change without constant rework.
The recent 650 Group study explores this dynamic in more detail, particularly around why Ethernet is becoming the default choice for enterprise AI networking and what that signals for the next few years
But even without the research, the direction is becoming hard to ignore.
AI isn’t just testing your compute strategy. It’s testing how willing you are to rethink the parts of the stack you thought were already done.
Why partnership matters more than platform choices
There’s also a practical reality here that’s easy to overlook. Very few organisations want to work all of this out alone. Designing, running, and adapting AI-ready networks cuts across architecture, operations, and security, and it rarely fits neatly into one team. This is where working with a service provider like Damovo can make a real difference. Not by selling a fixed answer, but by helping you see the trade-offs more clearly, stress-test assumptions, and build something that fits your environment rather than an idealised one. Sometimes the value isn’t in a new technology choice at all, but in having an experienced partner who can challenge decisions early, simplify what’s already complex, and stay involved as the network evolves rather than disappearing once it’s live.