Splunk ITSI and Red Hat Ansible Automation Platform for AIOps

At Red Hat Summit 2026, I joined fellow panelists for an AIOps conversation in the Ansible Automation Platform and the shift toward AI-assisted operations in the Ansible Automation Platform product spotlight. From the Splunk perspective, the discussion centered on a problem our customers know well: when a single customer-impacting event fires, it can generate hundreds of alerts from dozens of different sources.

That is not a staffing problem alone. It is a signal problem. Operators spend critical minutes and sometimes hours chasing individual alerts across tools instead of acting on a clear picture of what broke and why.

The good news is that most Splunk customers are already partway there. Anecdotally, more than half of the customers I talk to already use Red Hat Ansible Automation Platform. The opportunity is not a new toolchain. It is connecting the intelligence Splunk delivers to the governed execution Ansible Automation Platform already provides so teams move from correlated insight to trusted action without starting over.

What Splunk Brings to the Stack

The biggest challenge our customers face is signal overload. Splunk Observability Cloud and Splunk IT Service Intelligence (ITSI) reduce that noise by correlating events into one actionable incident, with correlated root cause so operators are not chasing individual alerts across different tools. That is the foundation.

What we are building on top of that is the intelligence that connects detection to action. Today, operators can see similar past episodes and how they were resolved. Where we are heading—and this is where the partnership with Ansible Automation Platform is critical—is surfacing a specific playbook recommendation with a one-click path to execution.

Splunk provides the intelligence. Ansible Automation Platform handles the governed execution. For our customers, that means the path from alert to remediation runs through platforms many teams already operate.

Building Confidence in AI-Driven Operations

The shift from assisted insight to AI-assisted operations— and ultimately autonomous action —is real. But for Splunk customers, the boundary comes down to trust. And trust starts with signal integrity. AI is only as good as the data behind it. We reduce alert noise by up to 95% and correlate across domains. But if the underlying signal is not trustworthy, autonomous action at machine speed quickly becomes risky.

We draw a clear line: AI should act only when correlation is strong, the surrounding context is rich, and there is a governed path to execution. Confidence is not just about the decision before the action. It is about what you can prove after. When a CIO asks what happened at 2 AM, you need an auditable trail from alert to decision to remediation, especially in regulated industries.

Both Splunk and Ansible Automation Platform provide that evidence. Ansible Automation Platform provides the governed execution. Together, that is how you build automation that is reliable, explainable, and accountable.

Where To Start

Start with measurement and signal quality. Consolidate your alert sources and measure your real mean time to resolution rather than a summary metric in a dashboard. How long from alert to acknowledgment? Acknowledgment to diagnosis? Diagnosis to resolution? Most teams cannot answer this question precisely, and you cannot improve what you cannot measure.

Once you have that baseline, look at your top five alert types by volume. Those are costing you the most time, and they are your best candidates for event-driven automation with Ansible Automation Platform. Measure, focus your signal, and automate what matters.

Pick one high-volume alert pattern your team already knows how to resolve. Connect it to an Ansible Automation Platform playbook you already trust. Do not start by building new automation from scratch. That first closed loop — even with an approval gate in the middle—gives you the evidence to justify expansion.

What This Looks Like in Production

A common use case we see is Predictive AIOps with Splunk Observability Cloud and Splunk IT Service Intelligence (ITSI). Rather than waiting for static thresholds to breach, the system predicts service degradation and triggers remediation before users feel the impact. This pattern combines Splunk ITSI's Kalman Filter forecast model with automated remediation via the Red Hat Event-Driven Ansible add-on for Splunk.

Consider a large retail organization running its e-commerce platform on an ITSI service hierarchy. Business stakeholders track retail revenue at the top. Underneath, ITSI monitors the technical services that keep revenue flowing, including an on-premises database service that handles transaction processing. One of that service's critical KPIs is network throughput (Bytes In), normally operating in a predictable range. When throughput spikes from a traffic surge, a misconfigured load balancer, or a capacity bottleneck, the effects cascade. Connection pools saturate, latency increases, queries time out, and the retail application degrades for end users.

The KPI is a minimum health indicator with maximum importance. When it goes “critical", the entire service health score is forced critical, connecting a technical anomaly directly to business impact. Here is how the joint workflow changes the response:

1. Predict. ITSI's Kalman Filter forecast model detects the throughput spike before a static threshold breaches, giving operators lead time instead of notification after the fact.
2. Contextualize. Splunk creates an episode with rich context: the impacted service, KPI, predicted values, and affected entities, so the response targets the right problem rather than a generic alert.
3. Act. The Event-Driven Ansible component of Ansible Automation Platform triggers governed remediation automatically. Ansible Automation Platform runs a pre-tested playbook with role-based access control (RBAC), isolated credentials, and a full audit trail.
4. Validate and document. The incident closes with a documented record of what was predicted, what ran, and what changed, before any customer reports an issue.

^{Figure 1: Architectural diagram: Predictive AIOps with Splunk ITSI}

The result: service degradation is addressed proactively, not reactively. Teams move from waiting for thresholds to breach and paging an on-call engineer, to predicting, remediating, and documenting with an auditable trail from forecast to action.

Key Takeaways

• AIOps is not about generating more alerts. It is about turning a correlated signal into governed, auditable action.
• Splunk consolidates alert noise and delivers root-cause context so operators act on one incident, not hundreds of notifications.
• Red Hat Ansible Automation Platform is the execution layer that turns Splunk's intelligence into trusted remediation with RBAC, approvals, and audit trails built in.
• Trust in automation requires signal integrity first, then proof after the fact: a clear trail from alert to decision to remediation.
• The fastest win starts with measurement: baseline your real MTTR, focus on your top alert types by volume, and automate what matters with playbooks you already trust.