Why ITOps needs a governed automation foundation for AI

Lately I hear many customers saying the same thing in different words—they added an AI layer to their environment, expected everything to get better, but haven't really noticed anything different yet.

In practice, the addition I see first usually sits upstream, whether that's a copilot, an AIOps correlation layer, or an agent able to reason across tools. That part helps people draft, classify, and recommend faster. Getting that work into production still exists on a different layer, and it usually looks the same as before the AI addition, with the same handoffs, queues, and approvals. Red Hat's overview, AI vs. automation: What's the difference?, names that same split. One side interprets and recommends; the other runs predefined work with consistency and control. What I watch for in the field is whether teams architect the path to production with the same intent as the upstream AI work, or if they leave existing processes as they are.

I often explain it with a plumbing analogy. Pour more water into a building without adequate pipes, valves, and drains, and you don't get better flow, you get flooded. AI increases the pressure at the top of the stack. It doesn't build the pipes, valves, and drains needed to safely manage that increased flow.

Where teams treat those layers as the same capability, the same confusion shows up in client work.

Three mix-ups I see in client engagements

The line between AI assistance and true automation blurs quickly. When copilots generate playbooks, AIOps diagnoses incidents, and tools are labeled "agentic," teams assume production is running itself just because the amount of manual typing has dropped. From an automation architect's view, that feeling usually comes down to 3 mix-ups:

• Insight versus execution: It's easy to mistake upstream output for finished work, but production still requires governed execution you can trace, and conflating the 2 is the mix-up. The observability and AIOps case is a common example. The journey from observability to AIOps automation walks through how analytics and triage connect to governed execution on the automation platform, without stopping at insight alone.
• Authoring versus runtime: Generated playbooks and roles still need review, testing, and promotion before they're trusted automation. Drafting content isn't the same as running it under policy.
• The agent as the automation: Giving an agent broad production access so it can fix things looks like progress, but it often replaces manual handoffs with unaudited, nonrepeatable change where the model becomes the integration layer and every run can look different.

Once those collapse into a single idea called "AI," teams skip the hard questions: who may act, on what systems, under which approval, with what evidence if it goes wrong?

What that confusion costs

When AI is mistaken for automation, programs fail in predictable ways.

• Insight without closure: Recommendations land in chat, email, or ticket comments, and AIOps or observability can sharpen triage at the same time. Prompt volume and dashboard confidence rise, but work still closes through the same handoffs, and incidents often resolve no more quickly with no less manual effort.
• Speed without governance: Teams give the agent credentials to close the gap. The agent "fixes" incidents faster until something breaks and nobody can reconstruct scope, identity, or history. Rollback remains undefined.
• Automation of the wrong thing: Teams encode today's workaround into playbooks or generated content, then ask AI to optimize it. Throughput rises, but the underlying process doesn't improve.

I saw a compressed version of that pattern on a recent engagement. The observability stack and AIOps layer were doing real work: fewer duplicate alerts, better grouping, and clearer severity on recurring infrastructure faults. Leadership could see "AI helping ops," but incidents on the same fault types still took as long to resolve and still needed the same number of manual changes to production. Analysts still opened tickets, pasted suggested remediations, and waited on manual approval to run fixes.

The turning point wasn't upgrading the AI stack, it was wiring trusted signals into Event-Driven Ansible rulebooks. Those rulebooks triggered reviewed job templates and workflows to gather facts, enrich tickets, apply known fixes, or escalate. It was the exact same approved automation an operator would run manually, drawing a clear line where AI stopped and governed execution took over.

The common thread isn't about AI. It's about the missing plumbing between the AI-assisted decisions and the changes being made to production systems.

The pattern that works

The pattern that works is 2 layers, wired together on purpose. Upstream AI senses and decides. It classifies, correlates, and recommends. Downstream automation executes under the controls your operators already trust. A signal or recommendation goes in; governed change comes out; job history and approvals show that production closed. That's the operational loop I measure in reviews.

For IT operations, I point customers to Red Hat Ansible Automation Platform when they need that pattern to be explicit. In design reviews I add 3 constraints teams often overlook when they focus on the upstream stack first:

• One approved action vocabulary: The same job template and workflow run whether a person, Event-Driven Ansible, or an agent triggers them. The trigger changes; the governed content and audit trail don't.
• Authoring isn't runtime: Generative assistants can help draft playbooks and recommendations, but what runs in production is reviewed automation content, promoted like any other change, not a first draft straight from the prompt.
• Agents reach production through the platform, not around it: The Model Context Protocol (MCP) server on Ansible Automation Platform exposes inspect-and-launch tools tied to a real user's token and role-based access control (RBAC). The agent doesn't hold direct credentials to managed infrastructure; it calls the same controlled surface everyone else uses. We discuss that execution-side pattern in The journey from observability to AIOps automation, along with observability and AIOps.

Event-Driven Ansible is usually the bridge from observability or AIOps into that loop: signals match rulebooks, rulebooks start approved jobs, and there are limits on parallel runs and approval gates when the signal isn't clear enough to act on alone. Outbound, a workflow can still call upstream AI when the playbook needs a judgment. In both directions, only approved automation content or an operator closes the loop.

AI helps you scale whatever execution layer you already have, but these constraints are how you can strengthen that layer instead of working around it.

Closing thoughts

In reviews, I don't lead with AI model selection. I ask for production work that finished through the AI path with evidence you can audit. When that trail is thin, the blur above is usually the cause, not which AI they're using.

You need AI and automation, but for different jobs. Pick 1 path that must be completed under policy and considered "done" in production terms: a successful job, an updated ticket, and an audit record. Wire intelligence upstream where it helps, wire execution through approved automation downstream, then measure to see if outcomes improve.

And if your organization is still mapping informal processes and tightening AI governance, you can do that in parallel. It doesn't replace the execution layer, but it makes the loop safer to scale. 

When you're ready to anchor that loop on a platform, Ansible Automation Platform is where job templates, workflows, approvals, and job history can live and work together. If you're looking to incorporate agentic AI, start with the MCP server on Ansible Automation Platform so inspect-and-launch stays on the same RBAC-backed surface as everything else.