The Questions to Ask Before You Let AI Touch Your Network

Every vendor at every networking event this season has an AI story. If you have been anywhere near AutoCon lately you will have heard plenty of them. Some are genuinely useful. Some are a chat box bolted onto a dashboard. And a few are quietly promising autonomous network operations in a way that should make any experienced engineer ask a second question before the demo moves on.

This is that second question, written down. Not a philosophical piece on whether AI belongs in network operations, that argument is mostly settled, the tools are here and they are useful. This is the practical checklist for separating a tool that will actually help your team from one that will create a new class of problem you did not have before.

Use it on any vendor, including us.

Start with what it is allowed to do

The first and most important question is the one demos tend to skip past: what can this AI actually change, and what can it only read?

There is an enormous difference between a tool that reads your configurations and explains them, and a tool that writes to your devices. The first can be wrong and the cost is a misleading answer you can catch. The second can be wrong and the cost is an outage across every device it touched before anyone noticed. Those are not the same product and they do not carry the same risk, even when the marketing puts them under the same word.

So ask plainly: in its default state, does this tool have write access to my network? If yes, ask how that is gated. If the answer is vague, that is your answer.

The questions that matter

Once you know where the read and write boundary sits, the rest of the checklist follows from it.

What does it do when it is wrong? Every AI is confidently wrong sometimes. The question is what the system does around that. Is there a validation step before anything is applied? Is there a rollback path, and is it automatic or manual? A vendor who has thought hard about being wrong will have a clear answer. A vendor who only demos the happy path will not.

Where does my configuration data go? When the AI analyses your configs, where does that data physically travel? To the vendor's cloud? To a third-party model provider? Out of your country? For a lot of regulated and security-conscious teams this single question rules tools in or out before any feature discussion. If the answer is "trust us, it is encrypted," keep asking.

Who approves an action, and is that enforced or optional? Human in the loop is easy to say and easy to design badly. Ask whether approval is a hard gate the system cannot bypass, or a setting someone can switch off under deadline pressure. Ask who, by role, is allowed to approve what.

Can it prove what it did? When an auditor or a post-incident review asks what the AI was asked, what it produced, and who approved it, can the tool produce that record? An AI action with no audit trail is a liability wearing a productivity costume.

What is it grounded in? An AI that answers from general internet knowledge will confidently recommend a feature your hardware does not support. Ask what the tool actually knows about your specific estate, your configs, your conventions, your vendors. Grounding is the difference between a network engineer and a chatbot doing an impression of one.

How do I start small? Any tool worth buying lets you prove it on a slice of your network before it touches the rest. If the only path is all-in, that is a risk in itself.

The pattern behind the checklist

If you read those questions back, they share a shape. Every one of them is really asking the same thing: how much is this AI allowed to do, can I see it before it does it, and can I undo it. That is not anti-AI. It is the same discipline good engineers have always applied to change management, pointed at a new kind of tool.

It is also why staged adoption beats a leap. A tool that starts read-only, earns trust by being useful and accurate, and opens up write capability later under explicit human control is a tool you can actually reason about. A tool that arrives promising autonomous operations on day one is asking you to skip the trust-building step entirely, on your production network.

We have written up that staged approach in full as the network AI maturity model, which maps where a tool actually sits against the levels of network autonomy, and where it is safe to start. It is the framework behind this checklist.

The short version

If you only remember one thing from this, make it the first question. Find out what the AI is allowed to change before you find out what it can do. Everything else, the rollback, the audit trail, the data handling, the approvals, follows from that one boundary. Get a clear answer there, and the rest of the evaluation gets a lot easier.

And if a vendor cannot give you a clear answer to "what is it allowed to do," you have learned the most useful thing the demo was going to teach you.

Want to put these questions to rConfig directly? Book a 45-minute walkthrough with our team, or read the network AI maturity model that sits behind this checklist.