From Anomaly Detection to Remediation: Closing the Last Mile of AIOps

AIOps platforms have become genuinely good at telling you something is wrong. Anomaly detection over time-series metrics, clustering on log streams, correlation across noisy alert feeds: these are mature enough that a well-tuned enterprise monitoring stack now produces far fewer and far better-aimed alerts than the same stack did five years ago. What has not moved at the same speed is everything that happens after the alert fires. Detection terminates in a ticket, and a ticket is just a formal request for a person to go and do something. 

Detection Was the Easy Half

There are structural reasons the detection side matured first. It is a read-only problem. A model that watches CPU saturation, request latency, or disk queue depth never changes the system it observes, so the cost of being wrong is bounded. A false positive produces noise and some irritation. A false negative produces a missed incident, which is worse, but neither outcome breaks anything by itself.

The data also cooperates. Operational telemetry arrives continuously, at high volume, in consistent shapes, and it carries an implicit label in the form of the incidents that were eventually declared. That is close to an ideal setup for statistical learning. Acting on the system is a different category of problem entirely, because every action carries write access, a blast radius and, frequently, no clean way back.

Where the Handoff Breaks

The gap shows up in how incidents are measured. Most organisations track mean time to detect and mean time to resolve as separate figures, and the first has been falling steadily while the second has been stubborn. That is not a coincidence. The interval between those two numbers is almost entirely human: someone reads the alert, reconstructs the context the detection system already had, decides what to change, finds the credentials to change it, and then changes it.

Context loss is the expensive part of that sequence. The detection layer knew which service degraded, which host, which deployment preceded it, and which similar incidents resolved how. Almost none of that survives the transition into a ticket body. The responder starts again from a summary. Runbooks are supposed to bridge this, and in practice they drift out of date faster than anyone maintains them, because the systems they describe change weekly and the documents do not.

What Remediation Actually Demands

Closing that gap needs a different class of component, not a better classifier. An IT real-time resolution system for enterprises has to do things a monitoring platform never has to do: authenticate as something with real permissions, reach the specific endpoint or service involved, apply a change that may be irreversible, confirm the change produced the intended effect, and write down exactly what it did and why.

 Each of those requirements pulls in identity management, network reachability, change control, and audit. That is the actual last mile, and it is an integration and governance problem dressed up as an AI problem.

The Standards Work Predates the Marketing

This asymmetry is old news to the people who build network management protocols. In June 2002, the Internet Architecture Board convened a workshop that brought network operators and protocol developers into the same room, and the resulting report, published as RFC 3535 in May 2003, recorded fourteen operator requirements. 

The operators flagged the gap early: their complaint was that existing standards work did not address what they actually needed, and configuration management was named specifically. Monitoring was adequate. Changing things safely and repeatably was not. That workshop is why NETCONF, YANG and RESTCONF exist.

Twenty years on, the same distinction is being formalised again for AI-driven operations. The ITU has standardised the architecture in Recommendation Y.3061, dated December 2023, which sets out an architecture framework for autonomous networks covering requirements, the components themselves, and sequence diagrams describing how those components interact with one another. The presence of sequence diagrams is the informative detail. A framework for autonomy is largely a specification of handoffs, because the difficult questions are about which component is permitted to act, on whose authority, and what happens when the action fails.

Measuring Whether the Loop Actually Closed

If detection metrics no longer distinguish good platforms from mediocre ones, the useful measurements sit downstream. The share of incidents resolved with no human touch at all is the blunt one, and it should be reported by incident class rather than as a single average, because a platform that automatically restarts stuck workers and does nothing else will post a flattering number.

Rollback rate is more revealing than success rate. A system that acts and never needs to reverse itself is almost certainly acting only in cases that were never risky. Time from detection to verified fix matters more than time to action, since an unverified change is a guess with better logging. And the proportion of automated actions that a human later had to repeat by hand tells you whether the automation is trusted, which is a separate question from whether it works.

None of these are hard to instrument. 

They are simply unflattering in a way that detection accuracy is not, which is most of the reason they appear less often in vendor material. They also have the useful property of being difficult to game. You can improve a detection score by retuning thresholds; you cannot improve an unattended resolution rate without genuinely handing more decisions to the system and accepting the consequences when it is wrong.

The Part Nobody Can Buy Outright

The realistic path here is narrow and boring rather than dramatic. Pick the incident classes that are frequent, well understood and cheaply reversible. Automate those end to end, including verification and the audit record. Leave everything else alone until the record of the automated cases is long enough to argue from. 

The organisations that get furthest with this are not the ones with the best anomaly models; they are the ones that did the unglamorous work of making their systems addressable and their changes reversible. Detection is something you can procure. Remediation is mostly something you have to have already built the conditions for, and the platform only closes the final stretch.