The innovation is real, but the ticket queue hasn’t noticed
Virtually every networking platform demo now touts AI: telemetry that correlates on its own, a single root cause identified out of a hundred symptoms, or an assistant that answers questions in plain language and offers clear next steps.
When the demo ends, persistent challenges continue. The network administrator is still getting pinged at 8 p.m. on a Friday about an outage. A single failure is still generating 20 tickets that someone triages one at a time. And in too many cases, the operating model still hinges on one engineer’s institutional knowledge and willingness to stick around.
Tom Wilburn, Global Vice President for Campus and Branch Networking at HPE, said it well: “Customers already have long to-do lists to deliver great networking experiences while keeping everything secure. HPE’s Self-Driving Network is designed to augment IT experts with trusted autonomous actions to keep users happy and secure.”
Two things are true: The new technology works, and the old problems are still sitting in the queue.
The disconnect looks different depending on where you sit. The administrator feels it when receiving an alert over the weekend. The CIO feels it as modernization that never starts because the team never stops firefighting. The CFO feels it as staffing fragility that hasn’t been fully accounted for.
The network and infrastructure leader sits in the middle, with responsibility for deciding which operating model closes the gap and then justifying their decision to everyone above them.
Are Self-Driving Networks Real?
Join CBTS and HPE on Thursday, November 12 for a live discussion on what AI-native networking really means,
what self-driving networks can do today, and why technology alone isn’t enough to achieve the outcome. Register now.
A platform decision is also an operations decision
If the AI-native networking technology is capable, why isn’t every organization forging ahead?
The constraint is typically operational. An AI-native platform is built to pay off for a team that can act on what it surfaces: tuning service-level expectations, validating the assistant’s recommendations before they reach production, and owning day-2 operations.
All of that requires a capable network operations (NetOps) bench, and the modern NetOps skill set has moved well past device configuration. It now runs through automation and infrastructure as code, data fluency, and the judgment to supervise AI-assisted systems and know when to override them. That bench is difficult and expensive to build. It’s also hard to keep, especially for mid-market organizations competing for a limited pool of engineering talent.
Without the right talent, the platform starts producing anomaly flags, recommended fixes, and service-level readouts. All of it is accurate. But there’s a risk that the team that has been drowning in tickets will now drown in intelligence. This isn’t a deficiency in an AI-native networking platform; it’s a mismatch between tech capabilities and team structures.
That’s why which platform? is only half the buying decision. The other half is who operates it, and who is accountable when it doesn’t work?
Every organization running an AI-native network ends up with one of three operating models: fully in-house, co-managed, or fully outsourced as a managed service. Each carries a different set of tradeoffs around control, coverage, cost predictability, and accountability.
For most mid-market and many enterprise teams, the fully in-house model means staffing for a capability that’s difficult to sustain. Co-managed and fully managed models exist to close that gap.
None of the three models require ripping out what’s already working. The strongest transition plans phase AI-native capability into the existing environment. That way, the cutover occurs in stages and doesn’t have to be absorbed all at once.
Three questions that separate AI native from AI enabled
If you’re looking to modernize, you may have found that AI is attached to nearly every networking solution on the market. Definitions and capabilities vary widely. While there’s real value in AI-enabled networking, the larger potential sits in an architecture designed around AI from the ground up.
Three questions will tell you quickly which one you’re looking at:
- Device health or service health? Plenty of platforms marketed as “AI-driven” watch access points and little else. Ask what the platform knows about the services your users depend on every day.
- Overlay required or built in? Ask what it takes to collect the telemetry. If the answer involves separate sensors, standalone software, or dedicated servers, consider that a second network to buy, deploy, and maintain.
- Reactive or proactive? Ask what the platform does on a Sunday night, and how many affected users it takes to trigger a flag. Traditional platforms tell you after a problem is detected and after the help desk phone starts ringing.
Pose all three questions directly and ask for a demo rather than a datasheet. A platform that can detect an issue should also be able to explain it in plain language, guide your staff to resolution, and, where appropriate, act to resolve it. If the answer arrives as a roadmap item, treat it as such.
As Tom Wilburn explains, “HPE’s Agentic AI is shipping today and capable not only of detecting a bad experience in real time but also acting to resolve problems. This requires deep, real-time telemetry and the right agents and models to act, which can’t be delivered without years of training and proven efficacy.”
Take a closer look at what’s possible
Ready to learn more about AI-native networking? Register today for our upcoming webinar, Are Self-Driving Networks Real? A Conversation with HPE, on Thursday, November 12 from 2 – 2:45 p.m. ET.