AI in the IT helpdesk: what's actually working in 2026, and what isn't

There is a specific kind of tired that comes from reading logs.

Not the hard part of troubleshooting. The stupid part: scrolling a wall of timestamped text while your eyes go soft, hunting for the one line that is not like the other 600,000. I have done this at 2am with coffee going cold beside the keyboard, done it badly, missed the obvious thing, and found it the next morning in twelve seconds.

For most of last year I told anyone who asked that AI log analysis was a parlor trick. It finds the word "error." Congratulations. So does grep, for free.

I was wrong, and I can point at the exact detail that changed my mind.

616,277 lines, and the part that mattered

A team debugging a freeze in an audio production app pulled a five-minute log slice off the machine. North of 600,000 lines for five minutes of wall-clock time, which tells you something about modern logging before anyone reads a word. One runaway process accounted for 616,277 of them, about 84% of the file.

They scrubbed it, uploaded it, and asked a plain question: what caused this application to freeze at this timestamp, and were these two specific processes involved.

Back came a real-time audio engine CPU overrun, a plugin symbol-linkage error pointing at a corrupted third-party install, and a license verification stall from a USB dongle that hung for exactly fifteen seconds at 12:55. All correct. All findable by a patient human with a free afternoon.

Then it did the thing I did not expect.

A background sync process had gotten stuck and was writing the same error pair 2,500 to 3,000 times per second, non-stop, for four solid minutes, by far the loudest thing in the file. The model named it as a contributing background drag and then said flatly that it was not the cause, because it never touched the process that froze. It also cleared a second suspect that showed up ten times and looked harmless.

Finding errors in a log is a text search. Declining to blame the noisiest process in the file, and saying why, is troubleshooting. Capable junior admins take two or three years to get comfortable doing that.

A different team fed device-management push-profile logs to an internally hosted, data-protected model to chase declarative device management commands that arrived and then failed to apply without complaining about it. That failure is close to unobservable any other way, and their results reportedly impressed the vendor's own engineers.

The catch sits right there in both stories. Every one of those wins landed in the hands of someone who could have reached the answer alone, given time. AI in the IT helpdesk amplifies a skill you already have. It does not install one.

The short list of things that work

Ticket classification and routing. The least glamorous item here, and the one I would fight for. You cannot build auto-resolution on top of a free-text box, because prose does not sort itself, and every automation ambition your team has is waiting on this one capability. Models are genuinely good at it now.

Answering level-one questions from your own documentation. One team built an internal agent on their own help docs and it answered every single level-one Mac support question they threw at it. The load-bearing detail: that worked once they gave it explicit anti-hallucination rules, meaning answer from these documents or say you do not know. A knowledge base nobody could ever find in search became useful because the retrieval layer stopped being a search box.

Converting a support case into an engineering bug ticket. Boring, repeatable, well-scoped, and it saves real hours on work most support engineers dislike. If you want one project to prove value with, pick this one.

First-pass triage. One practitioner still log dives herself, but lets AI go first so she can go in and ask whether it was right. That posture is the whole game.

Auto-resolution needs an honest sentence. It works in a narrow band: the answer lives in a document, the action is reversible, and the request type is common enough to measure. Outside that band you are shipping confident guesses to colleagues.

Meet the prompt jockey

Here is the failure mode I now worry about more than any technical one.

Someone with zero expertise in a domain asks a model for a document in that domain and gets back something polished, structured, and confident, which omits the facts the author never knew to ask about.

Leadership at one organization asked AI to draft a PCI-compliant payment acceptance policy. The output was clean. It never asked about device entry methods, never asked what training staff would need, never asked which SAQ level applied. A compliance reviewer read it and flagged the whole thing as unworkable.

Leadership adopted it anyway. The stated reason was that the document had been written with so much polish.

Sit with that for a second. For most of my career, careful writing was a fair proxy for careful thinking, because it was expensive to produce. That proxy is worthless now. I do not think our organizations have absorbed that yet, because every approval process I have ever worked inside runs partly on "this looks professional, so someone must have thought about it."

The better word for this behavior is confabulation. Hallucination implies perception and lying implies intent, and this is neither. It is a system filling a gap in certainty with the most plausible-sounding thing available. Humans do it constantly, which is exactly why we are bad at spotting it.

Forty-five percent

The security numbers are worse than the marketing suggests and better than the doomers claim, which makes them unusually easy to ignore.

Across more than 100 tested models, roughly 45% of AI-generated code ships with an OWASP Top 10 vulnerability. Only about one in ten AI-generated code samples passes a security review, even though most of it runs fine, which is the trap. Functional and safe are different tests. Only one of them is easy to run.

Then dependency hallucination. Up to one in five package references from some models point at packages that do not exist. Major commercial models do better at around 5%, which sounds tolerable until you remember it is 5% of every install command it ever hands you. Attackers noticed first. They register the fake package names and fill them with malware, an attack called slopsquatting, which is great terminology for a bad problem.

Real incidents, from real teams. An AI agent deleted a live user account during an onboarding and offboarding automation project, while the dry-run safety feature was working correctly on that same code. An enterprise Copilot deployment entirely deleted a C-suite executive's mailbox, recovered from backup, which is the only reason it is a story instead of a resignation. A generative calendar feature duplicated recurring events geometrically: one became two, two became four, four became eight, into perpetuity.

Every one of those came down to the same missing piece. Hands, granted without a gate.

The model checking the model is not a gate

I want to be precise about guardrails, because much of what gets sold as one is not.

When your coding assistant warns you before you hardcode a key, or helpfully adds .env to .gitignore, that is useful and it is probabilistic. The same system that produces the mistake is being asked to catch the mistake, at whatever accuracy it happens to have that day. A real gate is deterministic. It blocks every time, regardless of how confident anything felt.

The deterministic list is short and unexciting: secret scanners and push protection on your repos, Semgrep or Sonar or CodeQL in the pipeline, Dependabot and npm audit against the hallucinated-package problem. Somebody described the relationship as the difference between a seatbelt and an airbag. You keep both.

The posture that goes with it: whatever the model hands back is a hypothesis, not a verdict. Confident does not mean correct. You run the test, you run the linter, you check the claim against reality before it reaches anyone else.

Redaction discipline, since we started with logs. Never upload a raw log to a third-party AI tool. Logs carry hostnames, usernames, and IP addresses, and your data processing agreement almost certainly does not cover whatever somebody has open in a browser tab. Script the scrub first, then verify the scrubber, because scrubbers fail in ugly ways. One model redacted some IPv6 addresses and left others alone, purely because it did not know about compressed IPv6 notation or the interface prefixes that get prepended in log output. Partial, unannounced, exactly the kind of failure nobody catches by glancing.

The best trick I picked up here: hash your identifiers instead of deleting them. An MD5 of a username or an IP preserves the diagnostic fact that this is the same user throughout the file, without exposing who. Deletion destroys the thing that made the log useful.

The verification method people actually use is a 100-line check line by line, then a 500-line check, and if both are clean, trust it. That is statistical spot-checking rather than proof, and it is also what everyone does, including me.

One prompt-level trick worth stealing. Put anti-sycophancy instructions in your standing rules. Something close to: do not gaslight me, you are not here for my emotional security, tell me the truth, if this sucks then tell me it sucks. Then ask for a pre-mortem on every plan before it runs. Teams doing this report measurably better output, and the mechanism makes sense: that default agreeable tone comes from training on raters who reward confident agreement.

Works today, needs a human, do not

The part everyone is actually asking about

Twelve months ago, AI use in this industry got discussed in hushed tones and nobody wanted to admit they had vibe coded anything. Now near-everyone admits to daily use. In one cross-year survey of IT admins, the share saying they definitely do not find AI useful in their own job fell from 30% to 11%. "Yes, very much" went from third-most-common answer to first, and combined with "yes, somewhat" it reached 84%.

That is not gradual. That is a norm collapsing.

The fear is not irrational, and I refuse to wave it off. One team was told their director planned to cut all but two support staff in favor of a chatbot. That team ended up larger than before the rollout, which is the reassuring half. The unreassuring half is that some people in this industry will lose their jobs to AI, and anyone telling you it is only ever a tool and nothing changes is selling something.

The question I have not heard a good answer to gets asked far less often than the layoff one. Level-one work is where level-two engineers get made. Nobody learns how a system actually behaves from documentation. They learn it from four hundred password resets and one afternoon where the resets stop working. If the agent takes all of that, where does the next senior engineer come from?

I do not know. I have asked a lot of smart people and none of them know either.

The skill that pays has moved, though. It used to be doing the task. Now it is knowing what the task is for, and which gap in an answer matters. Finding the missing question inside a polished document is a craft, and for decades this profession got to treat polish as evidence that the craft had already happened.

That shortcut is gone. We are all editors now, of a very fast writer who has never once been embarrassed.

---

Foqal builds conversational IT support in Slack and Microsoft Teams, with the structured intake that makes any of this automation actually possible.