EMA IT & Data Management Research, Industry Analysis & Consulting

The Evolution of Autonomous ServiceOps — Part 3

Nov 13, 2026, 2:00:27 PM

PART 3 OF 6

Who Gives AI Permission to Act?
ServiceOps at the Point of Action

On November 10, the Australian government announced plans to strengthen oversight of artificial intelligence following an incident in which an OpenAI agent gained unauthorized access to a government medical statistics portal. The agent had been conducting research into public medical spending when it accessed information beyond its intended scope. OpenAI described the incident as unintentional and reported finding no evidence that the agent accessed patient records.

Australia's response includes plans for mandatory AI incident reporting, stronger security requirements, and a new AI safety regulator with proposed enforcement powers. The government also intends to consider legal reforms addressing serious misconduct. Reuters reported the announcement, which raises a question extending well beyond cybersecurity: Who determines what an AI agent has permission to do, and who remains accountable when its actions produce unintended consequences?

That question is becoming increasingly important as enterprises move from AI-assisted operations toward autonomous ServiceOps.

Authorization Is Not the Same as Accountability

In my previous blog, The ServiceOps Shakeout: Which Tools Still Matter?, I examined how AI may change the value of enterprise management software without eliminating the specialized capabilities those technologies provide. As AI assumes more responsibility for coordinating and executing operational work, the next challenge is determining the boundaries of that authority.

Traditional IT service management relies on established processes for approving changes, assigning responsibility, and escalating operational risk. AI agents introduce a different execution model. They can interpret conditions, select actions, invoke tools, and coordinate workflows with limited human intervention. But an agent’s ability to execute a technically valid action does not necessarily mean that action is appropriate for the business.

In EMA’s October 2026 research, ITAM in the Age of AI: EMA’s 2026 Maturity Benchmark, we surveyed 203 qualified IT professionals from North American organizations with at least 1,000 employees. The findings reveal an important distinction. While 71.9% of respondents reported broad operational AI adoption or more advanced deployment, only 22.2% reached the study's AI-Ready ITAM maturity level. These measures assess different dimensions of enterprise readiness, but their contrast raises important questions about whether the operational foundations supporting AI are keeping pace with its adoption. Among organizations classified as Optimized, 32.1% expressed very high confidence in their AI governance controls. That figure increased to 77.8% among AI-Ready organizations.

Consider a hypothetical situation in which an AI agent receives authorization to remediate a database performance problem. It identifies a resource constraint, determines that restarting a service will restore performance, and executes the change successfully. Yet the restart interrupts a business-critical transaction process that depends on the affected service. The agent completed its technical objective. The business experienced a disruption.

Three distinct responsibilities come into focus. Technical authorization determines whether the agent has permission to restart the service. Operational risk acceptance determines whether the potential disruption is acceptable under the circumstances. Business accountability establishes who owns the consequences when the action affects service delivery. These responsibilities may involve different teams, but they must operate within a common framework of decision rights and service ownership.

An agent may satisfy the first requirement without meeting the second. Neither eliminates the third.

Who Decides Whether an Action Is Safe?

Permissions, access controls, and human approvals establish important safeguards, but they cannot substitute for an understanding of business impact. An agent may have valid credentials and permission to execute a change while lacking sufficient information about the services that depend on the affected infrastructure. Authorization establishes what an agent may do. Operational context helps determine whether it should. The organization must decide which consequences are tolerable, under what conditions, and who has authority to accept those risks.

Our ITAM research reinforces the importance of understanding operational consequences before executing changes. Among Optimized organizations, 43.4% reported automated pre-change impact analysis, compared with 82.2% of AI-Ready organizations. This substantial difference highlights the greater availability of automated impact analysis capabilities among organizations at the highest ITAM maturity level.

For autonomous ServiceOps, effective impact analysis requires more than accurate asset inventories. Organizations need reliable configuration information, dependency relationships, service ownership, and an understanding of how technical changes affect business operations. An AI agent that can restart a server but cannot identify the business services depending on it has execution capability without sufficient operational context. That is not a sound foundation for autonomy.

Accountability Cannot Be Delegated to an Agent

The Australian incident illustrates why organizational responsibility remains essential even when AI systems act without direct human instructions. The government's response focuses on the obligations of organizations that develop and deploy AI systems. Its proposed reporting and oversight requirements reflect a broader principle: Autonomous execution does not eliminate institutional accountability.

As organizations grant AI agents greater operational authority, they must distinguish between the teams that configure and authorize AI execution, the service owners who establish acceptable operational risk, and the leaders accountable for business outcomes. These responsibilities may span ITSM, IT operations, security, application owners, and business service leaders. Organizations need explicit decision rights, defined escalation paths, and evidence linking an agent's actions to their operational consequences. Assigning an agent permission to execute a workflow does not transfer accountability for the resulting service outcome.

Nor can organizations assume that adding human approval to every decision provides an adequate long-term solution. Excessive approval requirements can undermine the speed and efficiency that autonomous operations promise. The more sustainable approach is to align the level of AI authority with the potential business impact of its actions. Low-risk, well-understood activities may support greater autonomy. Changes affecting critical services may require additional validation, approval, or human intervention. Organizations must also maintain the ability to trace decisions, verify outcomes, and intervene when agents behave unexpectedly.

From Permission to Operational Trust

The transition toward autonomous ServiceOps will require organizations to rethink how they establish operational authority. The central question is not simply whether an AI agent can perform a task or whether its execution follows an approved procedure. It is whether the organization understands the consequences, accepts the associated risk, and can demonstrate accountability for the outcome. EMA research shows that organizations at the highest ITAM maturity level report substantially greater confidence in AI governance and more extensive use of automated pre-change impact analysis. Those capabilities provide important foundations for granting AI greater operational responsibility. But permissions alone cannot create operational trust.

Trust depends on the quality of the information informing decisions, the safeguards governing execution, and the organization's ability to verify that actions produce acceptable business outcomes. The Australian government's response underscores the urgency of establishing those responsibilities before autonomous systems operate beyond their intended boundaries.

What's Next: The CMDB Isn't Dead. AI Just Made It More Important.

If AI agents need reliable operational context to make appropriate decisions, where does that information come from?

As AI takes greater responsibility for enterprise operations, accurate asset intelligence, configuration data, and service dependencies may become more important than ever. The next blog examines the increasingly important role of the CMDB and discovery capabilities in providing the operational context that autonomous ServiceOps requires.

← Previous Part 2 — The ServiceOps Shakeout: Which Tools Still Matter?
Next → Part 4 — The CMDB Isn't Dead. AI Just Made It More Important. — coming Nov 27

Parker Hathcock

Written by Parker Hathcock

Parker leads the IT Service/Operations (ServiceOps) practice at EMA, focusing on the convergence of IT service management (ITSM), IT operations management (ITOM), IT asset management (ITAM), enterprise service management (ESM), business service management (BSM), and AIOps in ways that help enterprises align business objectives with technology strategies. With over a decade of senior-level experience in product marketing, competitive research, and analyst engagement, Parker led teams in enterprise information management, process automation, discovery, observability, and digital accessibility at top companies, including Dynatrace, Redwood Software, and others.

  • There are no suggestions because the search field is empty.

Lists by Topic

see all

Posts by Topic

see all

Recent Posts