Govern Before It Acts

The day operations tooling started to act

For most of a decade, the artificial intelligence in IT operations did two things: it detected anomalies, and it recommended. A human remained in the loop, reading the recommendation and deciding whether to act on it.

That arrangement is ending. The leading platforms now ship agents that investigate and resolve incidents on their own. ServiceNow places generative agents inside IT operations that triage and remediate; BigPanda frames its direction as agentic IT operations; Vitria positions its platform around autonomous resolution across hybrid and network estates. The recommendation has become an action, and the human who used to stand between the two is being designed out of the path.

This changes the governing question. For a recommendation, the question was diagnostic: did the system predict the impact correctly? For an action taken autonomously, the question is one of permission: is this change allowed to happen at all? It must also be answered at the speed the action is taken: an autonomous operator does not wait for a change-advisory board, and a control that needs hours or days to return a verdict is no control at all. A probabilistic estimate of impact, however good, does not answer the permission question. Permission is not a prediction. It is a property of the change measured against intent — and intent is precisely what these systems do not hold.

Event Intelligence, described on its own terms

It is worth being exact about the category, because the argument that follows depends on characterizing it fairly rather than caricaturing it. In 2025, Gartner retired the label "AIOps Platforms" and renamed the market "Event Intelligence Solutions," after years in which the term had been applied so broadly, and promised so much, that infrastructure and operations leaders had grown skeptical of it. The rename was a narrowing, not a dismissal: it refocused the category on a real and valuable domain.

That domain is the application of machine learning and analytics to cross-domain events drawn from monitoring and observability tools, in order to reduce noise, correlate signals into incidents, and accelerate — and increasingly automate — the response. At this, the category is genuinely good. It collapses thousands of redundant alerts into a handful of actionable incidents. It surfaces problems earlier than static thresholds would. It is, for many operations teams, the difference between drowning and triaging.

Two facts about it matter here, and both come from the category's own definition rather than from any critique of it. First, Event Intelligence is designed to live inside a portfolio: Gartner is explicit that it depends on adjacent tooling — configuration databases, IT service management, automation — and that integration across that portfolio is essential to making it work. It does not own change control; it expects the surrounding stack to provide it. Second, the picture it holds of the estate is a discovered one: an assembled topology of services and dependencies, populated by automated discovery and a configuration database. That picture is a faithful record of what exists and how it connects.

None of this is a weakness. It is the category working exactly as designed. The question is what that design leaves unaddressed.

A model of what is, not what is allowed

Every model described in the previous section answers the same kind of question: what exists, what connects to what, what is happening right now. Not one of them answers a different kind of question entirely — what is permitted to change, by whom, and into what allowed state.

This is the authority gap, and it is easiest to see as a set of distinctions the existing tooling cannot make.

The market is beginning to sense that the model is the constraint. The clearest admission comes from inside the category itself: Vitria's chief technology officer has argued that conventional data structures give an AI statistical patterns where it needs genuine understanding, and that you cannot automate what you cannot explain. The diagnosis is correct. But the remedy on offer — a richer, more semantic model of what the estate is — does not close the gap. A better description of what exists is still a description of what exists. Understanding the estate more deeply is not the same as holding authority over change to it.

The gap is structural, not a question of maturity

It is tempting to assume the authority gap is temporary — that with enough discovery, a rich enough configuration database, and enough telemetry, the picture eventually becomes complete enough to govern from. It does not, and the reason is not a matter of fidelity.

Discovery enumerates what exists. A configuration database records how things are configured, whether discovered or declared. Telemetry streams what is happening from moment to moment. Each is a faithful empirical account — a statement of fact about the world as it is. Intent is not a fact about the world as it is. It is a statement of what ought to be permitted, which no quantity of observation contains. You cannot derive an "ought" from an "is," and stacking more "is," at higher resolution, never crosses into "ought." The missing layer is therefore not a better instrument in the existing stack. It is a different kind of artifact — a normative one, where everything in the Observe and Execute layers is empirical.

A concrete case makes the distinction tangible. Discovery can tell you that a security group permits inbound access from any address on a remote-administration port. That is a fact about the world as it is. It cannot tell you whether that configuration is permitted for this asset, in this environment, under this owner's intent — whether it is a sanctioned exception or a violation waiting to be exploited. The same observed fact is admissible in one place and forbidden in another, and only a model of intent can tell the two apart. Observation sees the rule; only authority knows whether it is allowed.

The Infrastructure Operating Model

An Infrastructure Operating Model is a maintained model of infrastructure, including context, approved intent, authority, verification, and reconciliation. Human-approved automation and workflow orchestration equip that model with a controlled way to operate through supported tools.

It is best understood by where it sits. Most enterprises have already matured two layers beneath it. The Execute layer changes the estate: infrastructure-as-code, continuous delivery, provisioning. The Observe layer watches the estate: monitoring, observability, and Event Intelligence. Both are essential, and neither decides whether a given change should be permitted. Execute will faithfully apply whatever it is told to apply. Observe will faithfully report whatever happens as a result. The decision in between has had no home.

The authority layer is the one most enterprises have never had.

Within the agreed operating scope, humans and AI request work through the IOM. The proposal is evaluated against current context, intent, permissions, and required approvals. Approved automation and orchestration coordinate execution through authorized integrations and return evidence. Access controls must prevent or manage bypass paths; model access alone does not enforce infrastructure permissions.

How AIOps runs on it

Place the two side by side and the relationship is not rivalry but layering. Event Intelligence observes the estate and, increasingly, triggers action within it. The Infrastructure Operating Model governs what that action is allowed to be. They occupy different layers and do different work; neither replaces the other.

The analogy is the processor and the laptop. A processor is the component a laptop runs on without being the laptop. In the same way, the operating model is the layer trustworthy AIOps runs on without being AIOps. AuthoriOM does not run your operations; it governs what your operations are permitted to do.

The category argument is functional: dependable AI-assisted operations need maintained context, declared intent, enforceable authority, and verification. The IOM brings those functions into a shared operating foundation. Evaluate implementations on source coverage, control enforcement, approved execution paths, and evidence rather than on the category label alone.

Adopt the premise of an operating model, and you have already accepted how trustworthy AIOps gets implemented — not as a feature inside the platform, but as a layer beneath it.

What the layer looks like when it runs

A supported pre-execution integration can evaluate a proposed operation against modeled context, approved intent, and current permissions. It may allow, deny, or require human review. The response and its evidence help the requester revise a proposal. Coverage depends on which execution paths are connected and enforced.

The model is built from the systems that already hold pieces of the truth — cloud and on-premises infrastructure, infrastructure-as-code and continuous delivery, identity, IT service management and the configuration database, observability, and Event Intelligence itself. It connects through their interfaces rather than through agents installed on hosts, and it begins read-only, so that nothing is gated until governance is deliberately turned on. In that posture, Event Intelligence becomes one of the model's richest sources of signal: the events and correlations it produces inform the model, and the model decides what may be done in response.

Evaluate the operating mechanism within its agreed scope: maintained context, explicit intent, enforced permissions, approved operations, and retained verification. Measure time, effort, exceptions, and outcomes against the customer baseline rather than assuming a universal saving.

Make intent authoritative

Most enterprises can now see their infrastructure in extraordinary detail and still cannot say, with authority, what is allowed to change it.

An AI agent with tool access can act; the operating question is whether the organization can explain and control that action. Maintain context and intent, enforce authority on enabled paths, and verify the outcome. This is the operating foundation the IOM is designed to provide.