AI in IT Operations

Where AI helps IT teams today

AI in an IT department is rarely one big system. It is a set of small helpers built into tools people already use: the monitoring platform, the ticketing system, the code editor, the network management system. Some are classic machine learning (statistics on metrics, clustering of logs), some are language models (summaries, drafts, chat). The AI in service management page describes the ITIL view of this; this page goes into the techniques. The table shows typical uses by role, as of 2026.

The pattern in the right-hand column is the theme of this page: AI narrows down and drafts, a person decides and answers for the result.

AIOps: less noise, faster cause

AIOps (AI for IT operations) is the umbrella name for applying machine learning to the metrics, logs and events of an IT estate. Its most valuable job is not prediction but noise reduction. One failing core switch can produce hundreds of alerts from everything behind it; an operator flooded with them suffers alert fatigue and misses the one that matters.

Classic event management already filters, deduplicates and correlates events with rules (see filtering and correlation). AIOps adds three things on top:

• Learned baselines instead of fixed thresholds: what is normal for this server on a Monday morning (next section).
• Learned correlation: alerts that tend to fire together, or that follow each other in the same order, are grouped into one incident even when nobody wrote a rule for it. Topology from the configuration management database makes this far more reliable.
• Summaries: a language model turns a group of 200 alerts and the matching log lines into a few sentences for the incident ticket.

AIOps only works as well as the data underneath it. If half the servers are missing from the CMDB, or every team names its hosts differently, correlation stays guesswork. Cleaning that up is usually the larger part of an AIOps project.

Anomaly detection

Anomaly detection means finding data points that differ significantly from the normal pattern of the data, without having a rule that says in advance what "wrong" looks like. A fixed threshold ("alert above 400 ms") is easy to set but blind to anything below it: a portal that usually answers in 210 ms and suddenly takes 240 ms has a problem long before it reaches 400 ms. And a portal that suddenly answers faster may be returning error pages.

The z-score idea

The simplest statistical method asks: how unusual is this reading, compared with the recent normal readings? You take the mean of a window of recent readings and their standard deviation (how much they normally vary). The z-score of a new reading is its distance from the mean, measured in standard deviations. If the readings are roughly bell-shaped, a value more than 3 standard deviations away happens by chance only about 3 times in 1,000, so it is worth a look.

The program below checks 30 response-time readings of a customer portal. The first 10 form the baseline; after that, each normal reading slides into the window and the oldest drops out, so the baseline follows slow changes. Anomalies are kept out of the window, so one spike does not make the next one look normal.

import statistics

# Response time of the customer portal in milliseconds, one reading per minute
latency_ms = [
    212, 205, 219, 208, 215, 210, 223, 207, 214, 211,
    209, 218, 206, 213, 241, 216, 212, 208, 221, 210,
    214, 209, 186, 217, 211, 215, 208, 212, 219, 213,
]

WINDOW = 10      # how many recent normal readings form the baseline
LIMIT = 3        # flag readings more than 3 standard deviations away
STATIC_ALERT = 400  # a typical fixed threshold: "alert above 400 ms"

baseline = latency_ms[:WINDOW]
for minute, value in enumerate(latency_ms[WINDOW:], start=WINDOW):
    mean = statistics.mean(baseline)
    stdev = statistics.stdev(baseline)
    z = (value - mean) / stdev
    if abs(z) > LIMIT:
        static = "yes" if value > STATIC_ALERT else "no"
        print(f"minute {minute}: {value} ms, z = {z:+.1f} "
              f"(baseline {mean:.1f} ± {stdev:.1f}) -> anomaly; "
              f"static alert: {static}")
    else:
        # only normal readings update the baseline, so a spike
        # does not make the next spike look normal
        baseline = baseline[1:] + [value]
print(f"checked {len(latency_ms) - WINDOW} readings")

minute 14: 241 ms, z = +5.5 (baseline 212.6 ± 5.2) -> anomaly; static alert: no
minute 22: 186 ms, z = -5.7 (baseline 212.7 ± 4.7) -> anomaly; static alert: no
checked 20 readings

Both anomalies are far below the static threshold, so a classic alert would never fire. Minute 22 is the interesting one: the portal became faster, which no "above X" rule can catch.

In practice

Real monitoring data is less tidy, and commercial AIOps tools use more robust methods for good reasons:

• Seasonality: load at 09:00 on a Monday is not comparable with 03:00 on a Sunday. Tools learn a baseline per hour of the week, not one rolling window.
• Outliers in the baseline: the mean and standard deviation are themselves pulled by extreme values; the median and percentiles are more robust. See IQR fences for a robust method that flags outliers for review.
• Several metrics at once: CPU at 70% is normal, and so is low traffic, but both together at night may not be. Multivariate methods (isolation forests, autoencoders) look at combinations.

Libraries such as scikit-learn do this faster and with more options; the from-scratch version shows that the core idea is "compare with normal", not magic. Every method also produces false positives: a statistically unusual reading is not necessarily a problem (a planned backup, a marketing campaign). That is why an anomaly should open a question, not automatically an incident.

Log analysis

Log analysis is the work of turning large volumes of log lines into understanding: which errors occur, how often, since when, and which ones belong together. A busy web platform writes millions of lines a day; nobody reads them line by line. Two kinds of AI help:

• Clustering: grouping log lines that are "the same message with different values" into templates, then counting them. A new template that never appeared before, or a template whose count suddenly jumps, is a lead.
• Summarizing and explaining: a language model reads a few hundred relevant lines and writes "the database connection pool ran out at 14:02, after which every request timed out". Useful for the incident ticket, but check it against the lines themselves: the model can mix up cause and effect.

From log lines to templates

The first step of almost every log clustering method (Drain, a well-known algorithm, works this way) is normalization: replace the parts that vary — IP addresses, numbers, IDs, user names — with placeholders. Lines that then become identical are one template. The example uses only documentation addresses (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).

import re
from collections import Counter

log_lines = [
    "Login failed for user amara from 192.0.2.14",
    "Connection to 198.51.100.7:5432 timed out after 30 s",
    "Login failed for user joost from 192.0.2.88",
    "Disk /var/log at 91% on host web-03",
    "Connection to 198.51.100.7:5432 timed out after 30 s",
    "Login failed for user mei from 203.0.113.5",
    "Request 7f3a9c2e took 4180 ms",
    "Connection to 198.51.100.9:5432 timed out after 30 s",
    "Disk /var/log at 94% on host web-07",
    "Request 0b44e1d7 took 3925 ms",
    "Login failed for user amara from 192.0.2.14",
]

# Order matters: replace IP addresses before plain numbers
RULES = [
    (re.compile(r"\b\d{1,3}(?:\.\d{1,3}){3}\b"), "<IP>"),
    (re.compile(r"\b[0-9a-f]{8}\b"), "<ID>"),
    (re.compile(r"(?<=user )\w+"), "<USER>"),
    (re.compile(r"(?<=host )[\w-]+"), "<HOST>"),
    (re.compile(r"\d+"), "<NUM>"),
]

def to_template(line):
    for pattern, placeholder in RULES:
        line = pattern.sub(placeholder, line)
    return line

counts = Counter(to_template(line) for line in log_lines)
print(f"{len(log_lines)} lines -> {len(counts)} templates")
for template, n in sorted(counts.items(), key=lambda item: (-item[1], item[0])):
    print(f"{n:>3}  {template}")

11 lines -> 4 templates
  4  Login failed for user <USER> from <IP>
  3  Connection to <IP>:<NUM> timed out after <NUM> s
  2  Disk /var/log at <NUM>% on host <HOST>
  2  Request <ID> took <NUM> ms

Eleven lines become four patterns. On a real system, a million lines typically become a few hundred templates, and that list is something a person can read. Real tools learn which positions vary instead of using hand-written rules, and keep the original values so you can drill down: which IP addresses had failed logins? (Here: the same user and address twice — probably a typo, but a count that keeps climbing would be worth a look.)

AI-assisted triage on the service desk

AI-assisted triage means that a model suggests how a new ticket should be handled — its category, priority, assignment group and likely solution — and a service desk analyst accepts or corrects the suggestion. Typical pieces:

• Classification: a model trained on past tickets (or a language model with a good prompt) suggests "network", "account" or "hardware" and the matching team. The analyst's corrections become new training data.
• Suggested knowledge articles: semantic search finds articles that match the meaning of the ticket, not only its words ("can't get on the Wi-Fi" finds "wireless connection fails"); see embeddings and retrieval.
• Summaries: a long email thread or chat becomes a short problem statement when a ticket is escalated, so the next team does not have to read everything.
• Draft replies: the analyst edits and sends; the model never sends on its own.

Users meet the same techniques directly in a virtual agent, which answers routine questions and can complete simple requests. The rule from ITSM applies: users can always reach a person, and that person receives the whole conversation.

AI coding assistants

An AI coding assistant is a tool, usually built into the code editor or terminal, that uses a language model to complete, generate, explain, test or review code. Well-known examples as of 2026 are GitHub Copilot, Claude Code, Cursor and Gemini Code Assist; most can also act as agents that edit several files and run commands (see AI agents and tool use). For IT operations they are just as useful for scripts, Ansible playbooks, SQL queries and regular expressions as for application code.

Reviewing generated code

Generated code looks confident whether it is right or not. It may call a function that does not exist, use an outdated library version, or handle the normal case and silently ignore errors. Treat it like code from a new colleague: read it, run the tests, and put it through the same code review and pipeline checks as anything else. You are the author of what you commit, whoever typed it.

Generated tests need the same scrutiny: a test that asserts what the code currently does will happily confirm a bug; see AI in testing.

Secrets and licensing

• Secrets: assistants read the files you have open, and agents can read the whole repository. A .env file or a hard-coded password ends up in the model's context. Keep secrets out of the repository and out of prompts; secret scanning and push protection catch what slips through (see securing repositories). Generated code sometimes contains placeholder credentials or disables certificate checks "to make it work" — look for that in review.
• Licensing: models are trained on public code, and occasionally reproduce a recognizable piece of it. If that piece is under a copyleft license, using it can carry obligations. Some assistants can block or flag suggestions that match public code; organizations usually decide this centrally, together with which assistants are allowed at all.

AI in network operations

Network teams use language models in two main ways, both safest when they fit into the existing automation rather than bypass it.

Configuration generation with validation

Asking a model for "an access list that allows SSH from the management network only" gives a plausible draft in seconds. The risk is a draft that is subtly wrong for your platform or version: a missing line, a wrong wildcard mask, a command that does not exist. The answer is the same pipeline that protects any change: the draft goes into the repository as a template or variable change, and automated validation (syntax checks, a network model such as Batfish, pre- and post-checks) runs before anything reaches a device. See validating changes in network automation with Git.

Natural-language questions over monitoring

"Which interfaces on the core switches had input errors in the last hour?" A model can translate that question into a query for the monitoring system and present the answer. This lowers the barrier for new engineers, but the query itself should be visible: a question that is translated slightly wrongly ("errors" versus "discards", "core" matched to the wrong device group) produces a confident but wrong answer. Read-only access is the safe default; a tool that can also change configuration is an agent and needs the controls described on AI security.

Where human judgment stays essential

AI can prepare almost any decision in IT operations. Some decisions must still be made by a person, for reasons that have little to do with how capable the model is:

• Change approval: a change authority weighs risk against business value and accepts responsibility for the decision. A model can assess risk from past changes and draft the change record; it cannot be held accountable.
• Incidents with safety impact: at an energy supplier like Kestrel Energy, an outage can affect heating, medical equipment at home or grid operations. Decisions about shutting down, switching over or informing authorities belong to trained people. Under the EU AI Act, AI used as a safety component in critical infrastructure is classified as high-risk (see AI regulation and governance).
• Anything that touches people: access requests, disciplinary questions from security monitoring, a user in distress on the phone.
• Novel situations: models are strongest on patterns they have seen many times. The incident nobody has seen before is exactly where they are weakest and where a fluent but wrong answer does the most harm.

A practical rule: the more an action is irreversible, affects safety or affects people's rights, the closer a human stays to it. Reading and drafting can be automated; approving and executing changes to production need a person in the loop.

Measuring the benefit honestly

Vendors' productivity claims are hard to compare and are often measured on their own demos. Studies of real work disagree: some report clear time savings on routine tasks, while a 2025 randomized study by the research group METR found that experienced open-source developers working in their own large codebases took about 19% longer with early-2025 AI tools, even though they believed the tools had made them about 20% faster. METR has since said that newer tools probably do better, which shows how quickly such results date. The honest conclusion is that the benefit depends on the task and the person, and that self-reported impressions are not enough. Measure it yourself:

• Use outcome metrics you already trust: mean time to restore, first-contact resolution, reopen rate, change failure rate, escaped defects — not "number of AI suggestions accepted", which is a vanity metric.
• Have a baseline: measure before introducing the tool, or compare a team with and without it over the same period.
• Count the hidden costs: review time, rework of wrong output, licenses and usage fees, and the time spent keeping the knowledge base and CMDB clean enough for AI to use.
• Watch quality, not only speed: faster ticket handling with more reopened tickets is not an improvement.