What “AI-assisted” should mean in IT operations

Every vendor in this category now claims AI. The claims are largely uninformative, because they describe a technology rather than a task. A useful claim names the specific piece of work the model does, what it is grounded in, and who is accountable when it is wrong.

Here is how we think about it, including the parts that constrain what we are willing to build.

Judgement versus transcription

Most operational work in an IT team divides into two kinds. There is judgement: deciding what happened, deciding what to do, deciding whether a risk is acceptable. And there is transcription: writing down the judgement so other people can act on it, review it, or be reassured by it.

Transcription is a large share of senior time and almost none of the value that senior time is paid for. Writing up a root-cause analysis after the analysis is finished. Drafting a quarterly review narrative from data everyone already has. Summarising a forty-message incident thread for someone who joined late. These are all necessary, none of them require the expertise of the person usually doing them, and because they are perpetually urgent-adjacent rather than urgent they get done at eleven at night or done badly under pressure.

This is the boundary we work to. Generative models are genuinely good at transcription and genuinely unreliable at judgement, and the industry's enthusiasm has consistently run in the opposite direction to that competence.

What that rules in

Drafting root-cause analysis on a ticket, where the facts are in the ticket and the surrounding data. Summarising tickets and incidents. Generating quarterly business review narrative for a client from that client's actual operational record. Producing executive and board-level summaries. Surfacing security and compliance recommendations from findings that already exist. Searching a knowledge base in language rather than keywords.

The quarterly review is the clearest case. QBR preparation is genuinely valuable to clients, universally disliked internally, and therefore either skipped or done badly at the last minute. Turning it from a writing task into an editing task is the difference between a QBR that happens and one that gets postponed twice and then quietly cancelled.

What that rules out

Acting. AegisOne does not execute anything on the strength of a generated recommendation. A generated remediation suggestion is a suggestion; a person decides whether it happens.

This is not caution for its own sake. An agent that can act on a machine has real-world consequences with no undo, and the failure mode of a confidently wrong model is not an error message — it is a plausible action taken on four hundred production endpoints. The value of automating that decision is modest. The cost of getting it wrong is not.

Grounding is not correctness

Everything generated in AegisOne is grounded in your own operational data. This matters — it is the difference between a summary of your incident and a summary of incidents in general — but it is routinely oversold, including by us if we are not careful.

Grounded output can still be wrong. It can attribute a fault to the wrong cause because the data supports both readings. It can summarise accurately and omit the one detail that changes the conclusion. It can state something with a confidence the underlying evidence does not support, because fluency and certainty are correlated in generated text in a way they are not in careful human writing.

So the review obligation is real and it does not transfer. Anything going to a client or an auditor is read by someone who knows the account well enough to catch a wrong detail. In practice this still saves most of the time, because reviewing a draft is far quicker than producing one — but it is a saving of eighty per cent, not a hundred, and a vendor implying otherwise is selling you a liability.

The questions worth asking a vendor

Which specific task does the model perform? If the answer is a category rather than a task, there is usually not much there.

What is it grounded in — my data, or a general model with my terminology sprinkled on top?

Can it take an action on an endpoint without a human approving that specific action? If yes, what happens when it is wrong, and what is the rollback?

What is your position on review? A vendor claiming their output needs no checking is either not thinking about it or hoping you are not.

Where does my data go, who processes it, and is it used to train anything?

The honest summary

AI in this category is a labour-saving device for writing, not a replacement for operational judgement. That is a smaller claim than most of the industry is making and a considerably more useful one, because it is true and because it points at work that is actually worth automating.

The senior engineer who now spends forty minutes editing a QBR draft instead of four hours writing one has been given back most of an afternoon. That is a real and unglamorous benefit. We would rather promise it and deliver it than promise autonomous operations and deliver a review queue nobody trusts.