AI in IT operations: what is genuinely useful and what is noise
Most AIOps material is written by vendors. Here is what actually helps a support or infrastructure team, and what quietly makes things worse.
Every service management vendor now sells an AI feature, and most IT teams cannot tell which of them would help. This separates the things that reliably pay off from the ones that mainly generate a demo.
Start with the boring wins
The highest-return automation in most IT teams involves no machine learning at all. Before anything else, look at what your team does repeatedly, identically, many times a week:
- Ticket categorisation and routing. A large share of misrouted tickets follow predictable patterns. Even rule-based routing removes a meaningful chunk of handling time, and this is where classification models genuinely earn their place once the rules get unwieldy.
- Standard request fulfilment. Access grants, software installs, mailbox setup, new-joiner provisioning. These are pre-approved by definition, which is exactly what makes them safe to automate end to end.
- Health checks and evidence collection. Scripts that gather the diagnostics an engineer would gather anyway, attached to the ticket before a human opens it.
- Drafting knowledge base articles. Turning a resolved ticket's diagnosis into a first draft, for a human to correct and publish. This is where language models are unambiguously useful — the draft is the tedious part, the correction is fast.
If your team has not automated password resets and access requests, no AI feature will help you more than doing that will.
Where AI genuinely adds something
Three categories where the technology does something rules cannot:
Anomaly detection in monitoring. Static thresholds produce either alert fatigue or missed incidents, and tuning them is endless. Learned baselines that account for time of day and day of week catch the things that are wrong without being over a number, and stay quiet about the things that are merely busy.
Alert correlation. One failure produces forty alerts across the estate. Grouping those into a single incident with a probable cause is a real reduction in noise, and it is the feature most likely to survive contact with production.
Assisted diagnosis. A model that surfaces the three most similar past incidents and what resolved them turns institutional memory into something an L1 engineer can reach. This works well precisely because it suggests rather than acts.
Where it goes wrong
Four failure patterns worth recognising before you buy anything:
- Automating a broken process. Automation makes a bad process faster, not better. If change approval is theatre, an automated approval workflow is faster theatre. Fix the process first — this is exactly what service management practice is for.
- Automating what you cannot debug. When an automated action fires at 3am and something breaks, someone has to work out what it did and why. If the automation is not logged, reversible and understandable, you have traded a known problem for an unknown one.
- Trusting generated output without checking. A language model will produce a confident, well-written, wrong runbook step. In IT operations that is not an inconvenience — someone will run it. Every generated artefact needs a human owner before it enters the knowledge base.
- Buying the feature before having the data. Anomaly detection and correlation need a history of clean, consistently categorised events. Teams whose tickets are half-categorised and whose monitoring is inconsistent get nothing from these features, and the vendor is rarely the one who says so.
A sensible order of adoption
| Stage | What you do | Prerequisite |
|---|---|---|
| 1 | Automate standard requests end to end | A defined request catalogue |
| 2 | Attach automated diagnostics to tickets on creation | Monitoring that can be queried |
| 3 | Rule-based routing, then learned classification | Consistent ticket categories |
| 4 | Alert correlation and grouping | A reasonable event history |
| 5 | Anomaly detection replacing static thresholds | Stable monitoring coverage |
| 6 | Assisted diagnosis from past incidents | Resolution notes people actually write |
Almost every prerequisite in that right-hand column is a service management discipline rather than a technology. That is not a coincidence, and it is the single most useful thing to understand about this topic.
What this means for your career
The anxiety in support teams is that automation removes the jobs. What it actually removes is the most repetitive part of the L1 queue — which is the part that was never going to get anyone promoted.
What becomes more valuable is the work automation cannot do: diagnosing the fault nobody has seen before, designing the automation itself, judging whether a suggested resolution is right, and owning the process the automation runs inside.
The practical move is to be the person who builds the automation rather than the person it replaces. That is scripting, an understanding of your service management tool's API, and enough judgement about the process to know what should not be automated at all.
In short
- Automate standard requests before considering anything with a model in it.
- Anomaly detection, alert correlation and assisted diagnosis are where AI genuinely beats rules.
- Never automate a process you have not fixed, or an action you cannot log and reverse.
- Be the person who builds the automation, not the one whose work it absorbs.
Questions people ask about this
Will AI replace IT support jobs?
It is removing the most repetitive portion of first-line work — resets, standard requests, categorisation. Diagnosis of novel faults, judgement about risk, and designing the automation itself are not being replaced. The exposure is highest for people who only do the repetitive part.
What is AIOps?
A vendor term for applying machine learning to IT operations data — chiefly anomaly detection, alert correlation and assisted diagnosis. The useful parts are real; the term covers a wide range of maturity between products.
Do I need to be a data scientist to use AI in IT operations?
No. The valuable skill set is scripting, API integration with your service management and monitoring tools, and knowing which processes are safe to automate. You are integrating capabilities, not building models.
What should a small IT team automate first?
Password resets and standard access requests, then automated diagnostic collection on ticket creation. Both are low risk, high volume, and require no machine learning at all.
Is it safe to use a language model to write runbooks?
As a first draft with a named human reviewer, yes, and it saves real time. As a source of truth published without review, no — generated steps are confident and occasionally wrong, and in operations someone will run them.