What an AI Can — and Cannot — Tell You About Your Own Network

Suppose your network is connected to an AI. The next question is what it can genuinely answer.

Here is a straight list, both halves of it.

Questions it answers immediately

What is connected right now? A list of the devices actually attached, with names, addresses and when each was last seen. It sounds trivial, and in an organisation without a system it takes someone the better part of an hour to assemble.

What changed overnight? A comparison of current state against what was recorded, summarised in a sentence — not two config dumps to diff by eye.

Why is this segment slow? Per-device traffic, the outlier consuming bandwidth, and a hypothesis you can go and verify.

Who uses what, and when? Usage patterns over time, which is the data you actually need to plan capacity.

Write up the current state. Documentation generated from what the equipment reports today, rather than from a file written last year.

Questions it cannot answer, and should not pretend to

The credibility of a system like this rests entirely on it admitting its edges.

Anything the equipment does not report. If a device does not expose a piece of information, the AI does not know it. Guessing in order to sound competent is the most dangerous failure mode in infrastructure work.

Problems outside your network. A degraded upstream link or a failing remote service is beyond what your equipment can see.

The future. An AI can extrapolate a trend from history. That is not the same as knowing which device will fail on which day.

Architecture decisions. How to segment, where to invest first — these need business context, budget, and the three-year plan. AI assembles the evidence for the decision. It does not make it.

Why admitting the limits makes the system worth more

Because a system that answers every question confidently — including the ones it has no basis for — is a system whose every answer is unusable. Once you know it will say "I don't know" when it doesn't, the answers it does give become something you can act on.

Frequently Asked Questions

Q1: Do I need to write technical commands?
A1: No. Ask in ordinary language, Thai or English; the system translates that into the read operations it needs.

Q2: What about automatic alerting?
A2: Possible, but it is a separate concern from question-and-answer. Automated monitoring should run on explicit rules rather than on a model's interpretation.

Q3: How long is historical data kept?
A3: It depends on the storage we design together and on your organisation's data policy. It is worth agreeing at the start rather than discovering later.

Curious how much of this your current network could answer? Consultations are free — LINE @tectony or hello@tectony.co.th