I recently gave a talk built around a single question: when we move from observability to AIOps, where should the line between human and machine sit?

Most conversations about AIOps start with tooling. Which platform, which vendor, which AI model. I want to argue that this is the wrong starting point. AIOps is not a product category. It is a design choice about where the human/machine decision boundary lives, and that choice has to be made deliberately, per problem space, based on trust, reversibility, and blast radius.

This post walks through the argument the way the talk did: a definition, a mental model, and then a five-stage journey through a real (simulated) incident that shows exactly where the machine shines and exactly where it confidently gets things wrong.

What AIOps actually is

Here is the working definition: AIOps is the practice of using AI-driven processes to respond to observability signals, filter and triage telemetry, determine probable causes, and execute recovery actions through automation. The ambition is to close the operational loop with minimal or no human intervention.

The industry framing is compatible with this view. Gartner, which coined the term, describes AIOps platforms as tools that analyze telemetry and events to surface meaningful patterns that support proactive responses, and defines them by five characteristics: cross-domain data ingestion, topology generation, event correlation, incident identification, and remediation augmentation [1][2]. Gartner has also argued that IT operations has no future without AIOps, simply because data volumes and rates of change have outgrown human capacity to derive insights unaided [1]. Notice, though, what that framing describes: capabilities, not a decision boundary. The vendor conversation tells you what the machine can do. It does not tell you what the machine should be allowed to decide. That second question is the subject of this post.

Notice what my definition does not say either. It does not name a product. It does not promise a destination. Closing the loop is a direction of travel, and how far you travel, and under what supervision, is a choice you make per process, not a box you buy.

The four domains

A useful way to structure the space is as four domains: two internal to the AIOps system, two external dependencies it relies on.

Internal: Diagnostic Intelligence. What happened and why? This domain correlates telemetry across application, platform, and infrastructure layers, performs causal inference, and produces ranked probable causes with confidence scores.

Internal: Remediation Intelligence. What should we do, and how do we do it safely? This domain applies operational policy, selects recovery actions, and orchestrates execution with safety controls and rollback.

External: the Telemetry domain. Traces, metrics, logs, change events, topology and dependency context. This is what feeds Diagnostic Intelligence.

External: the Operations domain. Runbook automations, scaling and failover controls, deployment rollbacks, feature flags, ITSM workflows. This is what Remediation Intelligence executes against.

The dependency model matters more than the AI. Diagnostic Intelligence is bounded by telemetry depth and correlation quality. Remediation Intelligence is bounded by automation breadth and safety controls. Sophisticated AI on top of shallow telemetry and thin automations does not give you autonomous operations. It gives you very expensive alerting.

Maturity is two axes, not one ladder

I frame AIOps maturity on two axes: Data Governance (can the system see, and can it trust what it sees) and SDLC Integration (can the system act through your delivery and operations machinery). Both run from manual at level 0 toward autonomous at level 4.

The trap is advancing one axis without the other. Push automation without governance and you are automated but blind. Push observability without an action surface and you are observed but manual. And critically, maturity is assessed per problem space. Your certificate rotation might be ready for full autonomy while your database failover should stay firmly human-approved. There is no single maturity number for an organization.

One clarification I want to make explicit, because the maturity model can mislead: autonomy at level 4 is a statement of capability, not a recommendation of policy. The model describes what you can build toward. It does not say that every process should end up there. More on this when we get to the Act stage.

Five stages, one incident

The heart of the talk is a continuum of five stages: Observe, Filter, Analyze, Suggest, Act. At each stage, the machine can take on more of the work, and at each stage the question “who decides?” gets sharper.

To make it concrete, I ran the whole arc against a single simulated incident: a cascading failure across a payments platform, with payment-svc, card-service, transactions-service, user-service, and an external bank-api all lighting up at once. Keep that setup in mind. There is a twist coming.

1. Observe: can we see the system?

Everything starts with extraction and centralization of telemetry. In the demo environment that meant the Grafana LGTM stack (Loki for logs, Grafana for visualization, Tempo for traces, Mimir for metrics) with OpenTelemetry instrumentation across the services.

At this stage the machine’s role is humble: collect, correlate, display. But without it, nothing downstream works. If the system cannot be seen, no amount of intelligence can reason about it.

2. Filter: what counts as weird?

Raw telemetry is loud. The filtering stage is about separating anomaly from noise, and the key move is abandoning static thresholds in favor of dynamic bounds. In the demo, that meant flagging metrics that drifted beyond three standard deviations of their trailing 30-minute behavior. A latency curve can stay comfortably under a static SLO threshold while drifting in a way that screams trouble, and dynamic bounds catch that drift.

The stakes of getting this stage wrong are well documented. Industry research puts typical enterprise alert volume at 500 to 1,200 alerts per day, with only a small fraction requiring action, and PagerDuty has found that most responders receive more than 10 alerts per shift, the vast majority needing no immediate response [3]. The 2026 State of Production Reliability report, a survey of 1,039 SRE, DevOps, and IT operations professionals, found that 44% of organizations experienced an outage in the past year directly linked to suppressed or ignored alerts, and 78% had at least one incident where no alert fired at all [4]. In other words, teams are simultaneously drowning in noise and missing real signals. The Catchpoint SRE Report found that nearly 70% of SREs say on-call stress has contributed to burnout and attrition on their teams [3]. Filtering is not a convenience feature. It is where the human attention budget is either protected or destroyed.

The premise I keep coming back to: the signal-to-question ratio matters more than signal volume. More dashboards do not help you. Fewer, sharper questions do.

3. Analyze: what happened?

Here the machine starts interpreting. Feed topology data, request rates, error distributions, and recent events into an LLM, and you get back something remarkable: a clear, legible incident report with ranked probable causes and confidence scores.

In our incident, the analysis was genuinely impressive. It correlated the error propagation across the service graph, identified card-service as the epicenter of the failure signature, and produced a coherent narrative of the cascade.

And here is where I planted a warning that pays off in the next stage: a confidence score is a statement about the model’s internal consistency, not about the world. Assisted is not authoritative.

This warning is not just rhetorical caution. It is one of the most consistent empirical findings about large language models. A Stanford study of confidence calibration found that LLMs are systematically overconfident: intervals the models labeled as 99% confident contained the true answer only about 65% of the time on average [5]. Research on verbalized confidence, the “how sure are you from 0 to 100” style of score that AIOps assistants surface in their reports, shows that models remain highly overconfident even when using self-consistency and chain-of-thought techniques [6]. A confidence score attached to an incident analysis should be read as a claim to be verified, never as a probability to be trusted.

4. Suggest: what should we do?

The machine now proposes a fix: restart card-service. Confidence: 77%. The rationale is fluent and well-evidenced. Error rates, incident timeline, service graph centrality. Everything points at card-service. It is the loudest thing on every dashboard.

It is also wrong.

The actual root cause was a v2.4.0 deploy that had gone out shortly before the incident, quietly changing behavior upstream. The deploy never showed up in the suggestion because it was not loud. It did not throw the most errors or sit at the center of the failure graph. card-service was the symptom amplifier, not the cause.

If this scenario feels contrived, consider the base rates. Google’s SRE organization has reported that roughly 70% of its outages are caused by changes to a live system, and that a majority of incidents are triggered by binary or configuration pushes [7][8]. A recent deploy is, statistically, the single most probable root cause in almost any incident. A suggestion engine that weights signal intensity over change correlation is therefore biased against the most likely explanation. This is exactly why change events and deployment metadata belong in the telemetry substrate: without them, the machine literally cannot see the thing most likely to be responsible.

This is the single sentence I most want people to take away from the talk, and from this post:

Loudness is not causality.

An AI suggestion system trained on signal intensity will reliably point you at the noisiest component. Sometimes that is the root cause. Often it is just the best megaphone. This is why the Suggest stage demands evidence over confidence: a suggestion should ship with its cause, its proposed fix, and the data linking them, in a form a human can actually verify. The human’s job at this stage is not to rubber-stamp a percentage. It is to be a verifier, and verification requires legibility.

Restarting card-service would have cleared the symptoms for a few minutes and taught the team nothing. Rolling back v2.4.0 fixed the incident.

5. Act: who pulls the trigger?

The final stage is authorization: who or what is allowed to change production? I describe this as a slider with three positions:

Suggestion. The machine proposes, the human decides and executes.
Approved. The machine proposes and prepares the action, the human reviews and approves, the machine executes.
Autonomous. The machine acts, the human is informed.

Where you place the slider is a per-process decision driven by two questions. Is the action reversible? And what is the blast radius if it goes wrong? Restarting a stateless service with health checks and automatic rollback: a strong candidate for autonomy. Schema migrations, failovers, anything touching money movement: keep a human in the loop.

The slider also has a research pedigree. Human factors researchers formalized this idea decades before AIOps existed: Parasuraman, Sheridan, and Wickens proposed a model of types and levels of automation in which each stage of information processing, from acquisition through analysis and decision to action, can be automated to a different degree, and showed that misallocating control harms both performance and accountability [9]. The same literature carries a warning for the middle position of the slider. Automation bias, the tendency to accept an automated recommendation without adequate verification, and automation complacency, the erosion of monitoring when a system has been reliable, are found in both novices and experts, and simple practice does not eliminate them [10]. A human in the loop is only a safeguard if the system is designed to keep that human genuinely engaged. This is why legibility of suggestions is not a nice-to-have: an approval step where the human cannot meaningfully verify the evidence is autonomy with extra steps.

For most teams and most processes today, the Approved position is the right operating default. That is not a failure to reach the top of the maturity model. Capability and policy are different claims. You build toward the ability to run autonomously, and you grant that autonomy selectively, process by process, as trust is earned through evidence. The v2.4.0 incident is exactly why: a fully autonomous system at 77% confidence would have restarted the wrong service, closed the incident, and buried the real cause.

The five questions

If you strip the talk down to its skeleton, it is five questions, one per stage:

Can the system be seen?
What counts as an anomaly?
What happened?
What should be done?
Who executes the action?

Every AIOps initiative, whatever the vendor logo on it, is an answer to these five questions. The first three are mostly engineering problems: telemetry depth, correlation quality, dependency mapping. The last two are trust problems, and trust is not a feature you can buy.

Closing thought

Observability is not a toolset. It is a method for understanding systems under pressure. AIOps, built on top of it, is not a product. It is a continuous design process: a series of deliberate choices about where the human/machine boundary sits, revisited as your telemetry deepens, your automations mature, and your trust is earned or broken.

Draw the line based on reversibility, blast radius, and evidence. Move it when the evidence says you can. And whenever a machine tells you, with great confidence, that the loudest service is the broken one, remember the deploy that never showed up on the dashboard.