AI for IT operations: what agents can safely take on

I sort IT operations work by one question: what is the AI allowed to change? A model that suggests a category for a ticket can be wrong at almost no cost, because an analyst sees the suggestion before it matters. A model that restarts a service or grants access can be wrong at three in the morning with nobody watching. The table ranks the common jobs by that exposure, lowest first.

The first three rows are where I would start almost any IT team. They save analyst time from the first week, and when they go wrong, they go wrong where people can see it. The last three are where the savings get larger, and where every control in the sections below has to exist first.

Vendors sell part of this as AIOps: machine learning over monitoring and event data, to group alerts, spot anomalies and suggest likely causes. The label covers the alert-grouping row and some of the incident work. It says little about the rows that change systems, and those are the ones a CIO ends up answering for.

Google's site reliability engineering book defines toil as work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows, and Google's SRE organisation aims to keep it below half of each SRE's time [1]. That definition is a good filter for where AI goes first, because toil is the work people are glad to give away.

A good share of IT toil needs no model. When a client's IT team was over capacity, we built an identity provisioning system for more than 1,000 users on explicit rules: access follows the HR record, each run applies only the difference between intended and actual state, changes can be inspected before they land, and a person is matched across systems by rule rather than by fuzzy matching, because a wrong match grants the wrong person access. If a job can be written down as rules, write the rules. Save the model for the part that needs judgement across messy text, such as working out what a badly written ticket is actually asking for.

The same test applies to automations that already run on a no-code platform. If one is straining, our guide to when Zapier is not enough sets out the signs and what to try before rebuilding.

An agent that can act on your estate is a new operator, and it should meet the bar you set for a new engineer with production access, plus a few checks that exist because it is a model. OWASP calls the failure these controls prevent excessive agency: damaging actions taken in response to unexpected, ambiguous or manipulated model output, caused by too much functionality, too many permissions or too much autonomy [2].

Where NIST's security and privacy control catalogue, SP 800-53, already words a control well, I cite it [3]. For a private company it is guidance rather than law. I use it because its wording is precise.

If you run ServiceNow or Jira Service Management, some of this arrives with the licence, and it is worth knowing what before anyone proposes a build. I describe each from the vendor's own documentation or, for ServiceNow, articles its employees publish on its community site, read on the date at the top of this page. This is not a ranking.

ServiceNow lets each tool an AI agent uses run in a supervised mode, where the agent asks the user to confirm its reasoning, or an autonomous mode, where the user sees only the output [4]. An article on access controls by a ServiceNow employee recommends supervised mode for agents that can take sensitive or critical actions. It describes two identities an agent can run as: a "dynamic user", the default, which inherits the permissions of the person who invoked it, or a dedicated AI user with its own preconfigured roles. It adds that role masking, introduced in the Zurich Patch 4 release, limits an agent to a subset of the invoking user's roles [5].

Atlassian lists AI features in Jira Service Management that include a virtual agent that answers questions from your linked knowledge base, grouping of related alerts, drafted post-incident reviews, incidents created from alerts, and suggested actions on service requests and incidents [6].

My view is to use the platform's own AI for work that lives entirely inside the platform, such as summaries, suggested routing and knowledge answers, because it already holds your tickets and your permission model. Build a layer of your own when the work crosses systems the platform does not own, such as your cloud accounts, your identity provider and your deployment pipeline, or when you need checks the platform cannot express. Either way, the controls above still have to exist. A vendor's supervised mode is one of them, not all of them.

Your ticket history is a test set you already own. Take a few months of closed tickets and replay them: what would the agent have suggested, and does it match what actually happened?

Score triage against the group that finally resolved each ticket, not the one it was first sent to, because a ticket that bounced between teams was misrouted at the start. Score knowledge answers on whether each one cites a current article and whether that article supports the answer. Score alert grouping on the groups your on-call staff later split by hand, because a wrong merge can bury a real incident inside a noisy group.

Then run in shadow. The agent makes its suggestion or prepares its action alongside the analyst, who does the work as normal, and you compare the two. Agree the pass mark before anyone sees a score, move a job to the next stage only when it clears that mark on real tickets, and rerun the whole set whenever the prompt, the model, the tools or the knowledge base change.

Measure the service as well as the model. Reassignment rate, reopened tickets, time to resolve and the number of escalations tell you whether staff and users are better off, and that is the number a budget holder will ask for. If your risk team works to NIST's AI Risk Management Framework, which NIST describes as intended for voluntary use and is currently revising [7], these results are the evidence to take to it.

Each stage earns the next. The table sets out the order I would use and what should be true before a team moves on.

Security incidents sit outside this ladder. An agent can gather evidence and draft the timeline, but the decisions in a security incident belong to the people your incident response plan names. NIST's incident response guidance, revised in April 2025 and now written as a profile of its Cybersecurity Framework 2.0, is a sound reference for that plan [8].

The order matters more than the speed. I would rather a team spent an extra month at stage three than skipped to stage four and spent the next quarter rebuilding trust after one bad night.

This is the work our AI integration and automation services do: AI built into the tools your IT team already runs, with the dry runs, rollback, audit logs and identity handling that let it write to live systems, and with agentic workflow design supplying the checks on each action. We would start with one queue or one runbook, test it against your ticket history, and take it through the stages above. The provisioning system described earlier is the standard we build to: deterministic where it can be, reversible and logged.

If you are not yet sure which jobs to start with, a fixed-scope AI Opportunity & Feasibility Sprint settles that and sets out what the build involves. A fixed-scope build can start within a day of the scope being signed, and if you already have a scoped job and need people to deliver it, we can resource it on contract from the collective of associates who work with 1AYM, held to the same standard. The first step is a 30-minute call about the queue or runbook you have in mind.