Will AI replace IT support?

No. It is replacing one specific part of it - the diagnostic loop - and it is genuinely good at that. It is not replacing accountability, access or judgement. Here is a week of faults on our own systems, including the one where the AI's own fix quietly broke something else.

The honest answer is no. The useful answer is that one specific part of the job has already gone, and if you buy IT support from anyone you should understand which part.

What AI replaces is the diagnostic loop: form a theory, test it, discard it, form the next one. That loop is most of the time in most faults, it is tedious, and a machine can run it far faster than a person can. What AI does not replace is deciding what to do about the answer, having the authority to do it, and being accountable when it goes wrong.

We are a managed intelligence provider, which means we run this arrangement ourselves rather than describing it in the abstract. Last week we rebuilt this website. Four things that happened on our own infrastructure are a fair sample of where the line actually falls.

The fault nobody could describe

The symptom was one sentence from a phone: the loading bar across the top never finishes.

No error. No alert. The page rendered fine. Nothing in any log said anything was wrong, because from the server’s point of view nothing was.

The first two theories were both wrong. A slow asset? No, the page finished in 770ms. Something in the new code? No, it reproduced on a clean build. The answer turned out to be that a privacy-focused browser was silently swallowing a third-party analytics request without formally cancelling it. The browser sat waiting for a script that was never coming, so the page never reached “loaded”.

That is a genuinely hard fault to reason about, and the thing that settled it was not cleverness. It was running the experiment: deliberately stalling that request and watching the page’s load event never fire. Then stalling a different one and watching it fail even earlier.

This is what the machine is for. Three theories, each properly tested, in the time it takes a person to make a coffee. A human engineer would have got there too. It would have taken most of an afternoon, and on a fault this obscure most businesses would simply never have chased it.

The fault buried in 29,000 lines

The first example was a fault with no signal at all. The more common problem is the opposite: far too much of it.

After the migration we needed to know what the world was still asking the old site for. The access log held 29,014 requests. Inside it, 1,016 distinct URLs returning “not found”.

A person can read a log. What a person cannot do is read 29,000 lines and be as accurate on line 28,000 as on line 12. That is not a competence problem, it is an attention problem, and it is the one thing machines are unambiguously better at than we are. Cross-referencing those failures against the old site’s database and sixteen months of search data identified 285 genuinely dead addresses, which we then retired deliberately instead of leaving them to rot.

One entry in that log is the whole argument. A path called /not_found appeared 53 times. It reads exactly like a broken link on our own site, the sort of thing you would raise a ticket for and send someone off to fix.

It was nothing of the sort, and the path alone will never tell you that. Three fields to the right the picture inverts: 25 separate addresses, most sending no referring page at all, and the ones that do arriving either from /wp-login.php or from a Google search for the word “wordpress”. A broken link on your own site does not behave like that. Real visitors arrive from your own pages, not from 25 addresses with no referrer. This was a scanner sweeping for an administrator panel that no longer exists.

That is the difference between reading a log and analysing one, and it is where people quietly lose hours to faults that were never faults.

The same file then answered a question nobody had asked. Counting the user agents showed AI crawlers had requested pages 893 times that week, against 465 visits from all the search engines combined. That number was sitting in a file we had only opened to chase broken links, and it changed what we built next.

None of this is intelligence. It is patience at a scale people do not have, and it is available continuously rather than when someone finally has an afternoon free. What it still took a person for was deciding what to do with 285 dead addresses. Retire them, redirect them, or leave them alone. That is a judgement about the business, not about the log.

The fix that broke something else

The repair created a second problem, and this is the part worth paying attention to.

Moving the analytics onto our own domain fixed the loading bar, and fixed a separate issue where phones on the office network were being asked to grant a permission the site should never have needed. Both real wins.

It also silently broke visitor counting. Every visitor started being recorded as the same person.

Nothing failed. The tracking request returned a success code the entire time. Every dashboard said healthy. The only way to catch it was to load the site twice from two different connections and check whether the analytics recorded one visitor or two. It recorded one.

The cause was a proxy in the middle rewriting the visitor’s IP address with its own. The fix was to pass the address in a header that particular proxy had no reason to touch.

Two things matter here. The first is that an automated fix introduced a regression that every success signal reported as healthy. The second is that it was caught by someone deciding to verify a claim rather than accept it. Anything that can make changes can make wrong ones, and confidence is not evidence.

This is exactly why we will not let the platform remediate on its own. It watches, correlates and investigates at machine speed. A person approves the change. Not because the machine is stupid, but because the machine is convincing, and convincing is the dangerous failure mode.

The root cause we could not reach

The real fix for that IP problem was two lines of configuration on a different server. We did not have access to it.

No amount of intelligence solves that. Access is granted by people to people, on the basis of trust and accountability, and it should stay that way. So the work went into a route around the problem that did not require touching a system we had no business touching.

That constraint is a feature. “The AI has access to everything so it can fix anything” is not a service model, it is an incident waiting for a date.

So what does not transfer

Four things, and none of them look like getting smaller:

• Accountability. When your systems are down and money is going out the door, you need someone answerable. Not a vendor, not a model, a person whose name you know.
• Authority. Deciding what a system is permitted to change, and when, is a judgement about risk to your business. That is not a technical question.
• Trade-offs. Degraded analytics versus a browser permission prompt on your own site is a business decision, not a correct answer waiting to be computed.
• Presence. Someone still has to stand in front of the rack, and someone still has to sit across from you and explain what happened.

What this actually means if you are buying IT support

Be sceptical of two claims.

The first is “we use AI” as a feature on its own. Ask what it does. If the answer is a chatbot on the support portal, that is not operations, that is deflection, and you will feel the difference at 3am.

The second is any provider promising autonomous remediation. Ask them what happens when the automated fix is wrong and every dashboard still reads green. We have watched that happen on our own systems, in a week, on a change we made deliberately and carefully.

The honest version is less exciting and more useful. AI does the watching and the diagnosis, continuously, across everything, at an hour when nobody is awake. A person decides and answers for it.

That is not IT support being replaced. It is IT support finally getting the thing it has always been short of, which is attention.

If you want to know what is actually running in your environment and what state it is in, we do a 30-minute review and you get the findings in writing whether or not you go any further. Book a review.