The AI SRE Files is a series where we turn conversations with SRE leaders into practical lessons you can apply to your own systems.
This article comes from AISRENext Bengaluru, held on June 12, 2026. During the session Killing the 90-Minute War Room, the conversation turned to a problem every team runs into sooner or later: data quality.
Lalit Mittal, an Enterprise Tech Ops leader, shared a perspective that resonated with many in the room.
The question was:
If the telemetry feeding your AI is noisy, incomplete, or misconfigured, automated RCA is going to be wrong. How do you deal with that, especially in a regulated industry where data quality isn't optional?
Lalit's answer focused on the work that happens long before AI enters the picture.
The first phase of incident response used to be about understanding what was happening before anyone could start fixing it. An alert would fire, the right people would join the call, and the team would piece together enough context to form a hypothesis.
That usually meant answering a handful of questions first:
Only after those answers started coming together could the investigation move forward.
Today, much of that groundwork can happen before an engineer even joins the incident. AI agents can reduce alert noise, correlate signals, form an initial hypothesis, and help route the issue to the right team. By the time someone opens the incident, they're often starting with a prioritized view instead of a blank slate.
That changes the role of the war room, but it also raises the bar for the data behind it.
If the telemetry is noisy, incomplete, or outdated, the agent has very little to work with. Better automation starts with better data.
Most enterprise environments have years of monitoring data spread across different tools. Over time, new telemetry gets added, older alerts remain in place, and the overall picture becomes harder to understand.
It's common to find alerts coming from tools such as:
Over time, some alerts become essential, others become redundant, and some continue to exist simply because nothing ever required them to change.
Lalit's advice was to start with an inventory.
He shared a simple example. In many banking environments, a batch job runs every 15 minutes. If it completes successfully, it generates a success alert. Years later, that alert may still be part of the workflow, even if operational teams no longer rely on it.
Reviewing alerts like these often starts with a few practical questions:
Those conversations help reduce unnecessary noise and make the remaining telemetry more meaningful for both engineers and AI systems.
Cleaning up alerts helps, but it doesn’t solve everything. The other part is making sure your telemetry still reflects how the business operates today.
Business priorities evolve. New products are launched, clients have different expectations, and regulatory requirements change over time. Monitoring often stays the same, even when the systems and processes around it have moved on.
Lalit shared an example from banking. A 2 AM SLA for a London business may require specific uploads and downloads to complete on time. If that workflow is delayed, the right people need to know, but "the right people" depends on the business.
Different stakeholders care about different outcomes:
Those requirements are driven by business context and the specific outcomes each stakeholder cares about.
It's worth revisiting whether existing telemetry still answers the questions people need answered today. That context helps determine what should be monitored, who should be notified, and when an alert is actually actionable.
Every team wants a clearer view of its operational data. Getting there, however, is a gradual process.
Lalit spoke about the reality he sees in banking. It's common to find 30 or 40 different data sources spread across Excel files, databases, proprietary platforms, and embedded tools. Each one exists for a reason, often because of decisions made over many years.
Rather than trying to solve everything at once, he suggested taking a structured approach:
To explain the idea, Lalit used an IIT analogy. You don't prepare for the entrance exam the night before. You understand what's required, build a plan, and make steady progress over time.
He sees data quality the same way. The important thing is having a clear direction and taking consistent steps toward it.
The discussion eventually came back to AI, but with a different perspective.
Much of the conversation around AI for incident response focuses on what happens after an alert is generated. How quickly can an agent correlate signals? Can it identify the likely root cause? Can it reduce the time spent in a war room?
Lalit believes those capabilities depend on something more fundamental.
Over the years, organizations have adopted different observability tools based on changing requirements, team preferences, and acquisitions. It's common to see multiple platforms working side by side, each storing part of the operational picture. As more tools get added, so does the effort required to connect the pieces.
Improving data quality isn't a one-time project. It happens gradually through cleaner telemetry, better documentation, stronger business context, and, where possible, simpler tooling.
Every organization starts from a different place. The important question is whether the data feeding AI reflects how the business operates today. The closer those two stay aligned, the more useful AI becomes during incident response.
One thing the discussion made clear is that reliable investigations start with reliable context. Aiden for SRE brings together infrastructure, observability data, and operational knowledge from the tools you already use, helping reduce alert noise and investigate incidents faster. The more complete that operational picture is, the easier it is to identify what changed, what broke, and where to look next.
Here's the easiest way in: Aiden for SRE Community Edition is free to try - Connect your Grafana or Datadog instance, fire an alert, and watch Aiden investigate and generate an RCA in a quick few minutes. That's it!
Disclaimer: The perspectives shared in this article are Lalit's own, offered in his personal capacity as a technologist. They do not represent the views, policies, or official position of his employer or any affiliated organization.