Best practices for AI-assisted IT operations

There is a useful distinction at the centre of every AI operations project: the difference between interpretation and authority. Language models are genuinely good at interpretation — reading unstructured text, recognising a pattern, summarising a situation, matching a description to a known case. They should not hold authority over what is permitted to happen to production systems. Most things that go wrong in this space come from collapsing those two roles.

Where models earn their place

Four categories of operations work benefit clearly, and they share a shape: unstructured or high-volume input, a well-understood output space, and a cheap way to check the result.

• Request interpretation — turning prose descriptions of symptoms into structured intents, assets and urgency.
• Signal correlation — recognising that twelve alerts describe one event, and summarising what that event appears to be.
• Runbook matching — connecting an observed pattern to the procedure your team already wrote for it.
• Drafting — writing the reply, the incident summary or the change description, grounded in retrieved findings.

Notice that none of those are decisions about what to do to a system. They are all transformations of information, and each one can be checked.

Where they should not hold authority

Permission decisions, blast radius, and verification should all be deterministic code, not model output.

Whether a requester may restart a production service is a policy question with a correct answer that your organisation has already decided. Encoding it as a rule means it is auditable, testable and identical every time. Asking a model means it is none of those things, and the failure mode is a confident wrong answer during an incident.

The same applies to verification. If the model both performs the action and judges whether it worked, you have no independent check. Verification should be a separate assertion against measured state.

Ground every claim in retrieved state

A model asked about your infrastructure from its own knowledge will produce something plausible. A model given the current output of a query about your infrastructure will produce something useful. Design every operational use as retrieval-grounded: fetch the state, then reason over it.

In practice this means the model's context should contain the monitoring query result, the relevant runbook section, the asset record and the recent change history — and the output should cite which of those it relied on. When a conclusion is wrong, you then find out whether the reasoning was wrong or the input was stale.

Design the escalation path first

An AI operations system is judged on its worst behaviour, not its average. The most valuable thing you can build early is a clean, well-understood path for 'I do not know'.

• Carry confidence forward explicitly and gate actions on it.
• Make escalation carry everything gathered so far, so a human starts ahead rather than from scratch.
• Treat a correct escalation as a successful outcome in your metrics, not a miss.
• Alert on the rate of unverified outcomes — it is the earliest signal that the system is drifting.

Controls that actually constrain behaviour

Instructions in a prompt are not a security boundary. Anything that must not happen needs to be prevented by the architecture rather than discouraged in text.

1. Registered action catalogues. The model selects from a list of operations you defined; it cannot construct new ones. No general shell, no arbitrary HTTP.
2. Parameter validation. Each action validates its inputs against a schema and against policy before executing, independently of how convincing the request looked.
3. Scope binding. Every run is bound to a tenant, an environment and an asset set, resolved outside the model's influence.
4. Approval gates. Operations above a risk threshold pause for a named human, with the specific parameters rendered for review.
5. Server-side credentials. Secrets are resolved at execution time and never enter a model's context.
6. Immutable run history. Inputs, retrieved context, decisions, actions and outcomes recorded for every run.

Keep humans in the loop where judgement is the work

Some operations decisions are genuinely judgement calls: whether to fail over during a partial outage, whether to accept a risk to meet a deadline, whether a customer's situation warrants an exception. These are not automation gaps to be closed later. They are the part of the job that requires accountability.

Design for those decisions to arrive well-prepared rather than to be made automatically. The measure of a good AI operations system is often how much better-informed the human decisions are, not how few of them remain.

Evaluate continuously, not once

Treat classification and matching quality as something you measure on an ongoing basis, with a held-out set of real cases and a review cadence.

• Maintain a labelled set of representative requests and alerts, refreshed as new patterns appear.
• Re-run it whenever you change a model, a prompt, a taxonomy or a retrieval source — these are all behaviour changes.
• Review the lowest-confidence decile of real decisions weekly. That is where your taxonomy gaps live.
• Review the highest-confidence errors separately. Those are the dangerous ones.

Being honest about what it does not do

AI-assisted operations does not remove the need to understand your infrastructure, and it does not make an undocumented procedure safe to automate. It compresses the repetitive interpretation and execution work that sits between a known problem and a known fix. That is a substantial, measurable benefit — and it is a different claim from autonomous operations, which is not what a responsible platform should be selling.