AI in networking
Published 17 September 2026
Almost everything written about this is either a vendor describing a roadmap in the present tense or a sceptic describing a demo from two years ago. What follows is a category-by-category account of what is shipping, what is not, and the questions that separate them.
Three different things share one word
Most confusion here is vocabulary. "AI in networking" covers three technologies with different maturity, different failure modes, and about fifteen years between them.
| What is meant | What it really is | Maturity |
|---|---|---|
| Anomaly detection and baselining | Statistics and classical machine learning on telemetry | Shipping for years |
| Assistants that read and explain | Language models over docs, configs and output | Real and useful now |
| Agents that change the network | Models with tool access and write permission | Early, and the risky one |
When a vendor says AI, the first question is which of those three. The answer is usually the first: respectable, genuinely useful, and around since long before the current wave.
What is genuinely working
Finding the unusual in telemetry
Baselining what normal looks like and flagging deviation is a solved-ish problem, and it predates the acronym. It works because the question is statistical and the data is abundant. It is also where most shipped "AI networking" features actually live.
Its weakness is the one every monitoring engineer knows: an anomaly is not an incident. Systems that flag deviation without ranking consequence produce noise, and noise trains people to ignore alerts.
Vulnerability queues fail the same way when automation treats every CVE or high score as the same event. The operational distinction in KEV vs CVE is a good example of where a model may summarize evidence, but asset exposure and patch priority still need explicit, reviewable rules.
Reading things for you
Language models are strong at explaining unfamiliar output, translating configuration between vendors, and drafting the automation you were going to write anyway. This is knowledge work, and it is where the current technology is strongest.
It is also checkable, which matters more than it sounds. You can read a generated script before running it. That single property is why this category is safe and the next one is not.
Getting models access to real systems
In 2026, the Model Context Protocol became the common way to give a model access to real tools and data: Anthropic moved it under the Linux Foundation, Cisco and Red Hat have shipped support, and dozens of production servers now cover devices, monitoring platforms, source of truth and ITSM.
This is the shift that makes the rest plausible, because it addresses the fundamental limitation: a model that cannot see your network can only generalise about networks.
What is still a demo
- Self-healing networks. Detecting a condition and running a pre-written remediation is automation with a trigger: worth having, and not new. "The AI fixed it" almost always describes a runbook somebody wrote.
- Natural language as the operational interface. Asking for a VLAN in English demos beautifully. In production the question is not whether it parses the request but what happens when it parses it slightly wrong on four hundred devices.
- Autonomous operations. Every credible deployment keeps a human between proposal and change. The gap is not model capability, it is that nobody has solved accountability.
The questions that cut through a demo
These are worth asking in any vendor conversation, and the hesitation is usually more informative than the answer.
- "Is this a language model, or statistics you renamed?" Both are fine. Only one is new, and the pricing usually assumes it is.
- "What does it do when it is wrong?" Any system that cannot be wrong out loud is one that will be wrong quietly.
- "Can it write, and who approves?" The difference between an assistant and an agent, and the only question that changes your risk profile.
- "Where does my configuration go?" Configs contain topology, addressing, and sometimes secrets. Whether they leave your estate is a compliance question, not a technical one.
- "Show me it failing." The most useful request you can make, and the least often granted.
The failure mode to design around
A model asked about something it cannot see does not decline. It produces a fluent, well-structured, entirely plausible answer about a network that does not exist. In a field where output is already dense and half-understood, plausible-and-wrong is more dangerous than obviously wrong.
Networking is full of results that are routinely misread by people, and those misreadings are now in training data. Asterisks in a traceroute get reported as a broken path when they usually mean a router declining to reply. A host that ignores ping gets called down. An SPF record that looks perfect can be silently invalid because it spends one DNS lookup too many. A machine confidently repeating a common mistake is still a mistake.
Check the answer against the network. Whatever a model tells you about a domain, the record itself is a second away. The DNS lookup and SSL checker run in your browser and report what is actually published.
What to take from this
Treat AI in networking as three separate conversations. The statistical layer is mature and you probably already own some. The assistant layer is genuinely useful today and costs you little to adopt, because everything it produces can be checked before it matters. The agent layer is where the interesting work is, and it should be entered with the same caution as any other system that can change production at scale.
The engineers who will do well are not the ones who adopt fastest. They are the ones who can tell which of the three they are looking at, and whether the answer in front of them is true. On what that means for the job itself, see will AI replace network engineers.
For how much of this the industry is actually asking newcomers to learn, the CCNA v2.0 blueprint is a useful reality check: AI is about three per cent of it.