When should an AI system be allowed to fix an IT problem without waiting for a human to approve the action?
In this episode of Tech Talks Daily, I speak with Matt Tuson, General Manager for Europe, the Middle East, and Africa at LogicMonitor, about the practical path from reactive IT operations toward autonomous IT. The promise is attractive: fewer repetitive tasks, faster incident resolution, less disruption, and systems that can correct familiar problems before users feel the impact. The difficult part is deciding when the available data, controls, and evidence are strong enough to trust an automated action.
Matt argues that observability is taking on a different responsibility. It once helped engineers answer what happened and why. In an autonomous environment, it must also give AI enough connected context to recommend or execute what should happen next. That means understanding how infrastructure, networks, cloud services, applications, and other operational signals relate to one another. A fast decision based on an incomplete view can resolve the wrong symptom, create duplicate incidents, or make the original problem worse.
Trust therefore begins with the information supplied to the system. Many IT environments contain separate monitoring and management tools introduced by different teams to solve specific problems. Those specialist products may continue to do useful work, but their signals often remain disconnected. Matt describes a business combining nine organizations, each bringing its own tools and operational practices. The challenge was not simply the number of products. It was the inability to connect their outputs into a reliable view of what was happening across the combined environment.
This matters because AI can process poor information as quickly as good information. Matt warns that adding autonomous remediation to incomplete, duplicated, outdated, or poorly contextualized data risks creating automated confusion. False positives multiply, root causes are missed, and teams repeatedly address symptoms while the underlying fault remains. His advice is to start with the business outcome, identify the information needed to support that outcome, and improve the quality and consistency of the data before increasing AI authority.
We also discuss how leaders can decide which actions belong with AI and which should remain under human control. Matt rejects the idea that organizations must choose between full autonomy and complete human approval. He recommends graduated levels of authority based on the action, confidence in the recommendation, business impact, and whether the change can be reversed easily. Ticket enrichment, alert correlation, and routine remediation may offer lower-risk starting points. A change affecting a major service should receive closer human oversight until the system has established a reliable record.
That creates a practical model for earning trust. If an AI recommendation repeatedly matches the action an experienced engineer would have taken, the organization gains evidence that it may be safe to automate that decision. The process can move gradually through support levels and operational complexity, with explainability, governance, and audit records maintained throughout. Human judgment remains where accountability and business consequences demand it.
Matt also addresses the difference between companies making progress with AI and those stuck in pilot purgatory. The stronger performers begin with an operational problem, such as reducing incidents, improving uptime, or accelerating resolution. They invest early in data quality, visibility, collaboration, and governance. AI becomes part of an existing workflow with a defined path from insight to action, rather than a detached experiment looking for a reason to exist.
For IT leaders who want greater autonomy but do not yet trust their environment, Matt's starting point is simple: establish broad visibility, improve operational data, connect isolated sources, and define the actions AI can take independently. Teams must also be able to understand why a system reached its conclusion and inspect what it did afterward. Autonomy should grow through repeated evidence, not through hope or one large leap.
There is a commercial reason to get this right. Faster resolution can reduce the cost of service, protect customer experience, and limit the business impact of downtime. There is also a human benefit. Engineers spend less time sorting duplicate alerts or joining war rooms to prove which team was innocent. They can concentrate on decisions that require experience, judgment, and knowledge of the business.
As observability starts supplying evidence to machines as well as people, what controls would make you comfortable allowing AI to take action inside your IT environment? Listen to the episode and share your thoughts.