# Reducing Alert Noise with AI in Enterprise IT - with Dhrubojyoti Das Deb of JPMorganChase

- **Show:** The AI in Business Podcast
- **Published:** 9 Oct 2026
- **Source:** https://podcast.emerj.com/intelligent-operations-at-enterprise-scale-with-dhrubojyoti-das-deb-of-jpmorganchase
- **Transcript:** https://podcasts.opennash.com/shows/ai-in-business/reducing-alert-noise-with-ai-in-enterprise-it-with-dhrubojyoti-das-deb-of-jpmorg-1b4747/
- **Provider:** OpenNash Podcasts (machine-generated)

## In brief

IT teams are not short of data. They are buried in it, and most of it is noise. Dhrubojyoti Das Deb argues that adding more tools does not fix this. AI can group thousands of alerts into a few incidents and help find root causes, so people spend their attention only on the signals that matter.

The central tension is speed versus trust. AI can process far more than any team of people, but Das Deb insists humans stay accountable, like a pilot with an AI co-pilot. Trust is built through small, validated wins, clean structured data, and governance. He says full automation may take years, so leaders should start with their noisiest workflow.

## Key insights

1. **Alert overload comes from siloed, cascading systems** Applications built on different tech stacks each log their own data, and nothing joins it up. A red dashboard on application four may really be caused by bad data from application one, so analysts lose time chasing the wrong cause.
2. **AI grouping can shrink thousands of alerts to two** Das Deb describes feeding 5,000 alerts into AI, alongside past incidents and deployment history. It can spot that they are variations of two incidents, so people review two items instead of thousands.
3. **Humans stay accountable, with AI as co-pilot** Customers will not accept 'the AI did it', so the company and its people own every AI decision. He compares the human to the pilot and the AI to the co-pilot, with the human validating each step in a loop.
4. **Trust in automation is built through baby steps** Teams list their operational frictions, rank them by risk or ease, and automate a couple of easy ones first. Product and business groups must be involved, since they own the risk when customers are affected. Das Deb says end-to-end automation of a complex application may take years.
5. **Structured data and governance must come before AI** AI works best on data that carries timestamps, application names and sub-module names, otherwise it cannot tell where an error came from. He also says AI governance sits on top of data governance and needs clear boundaries for each group.

## Questions this episode answers

### What is alert overload in IT operations?

It means monitoring systems produce so many alerts, logs and messages that teams cannot tell which ones are real problems. Das Deb says about 99% of the data is noise, such as debug and informational messages that are not actual errors.

### How can AI cut the number of alerts a team has to look at?

AI can group related alerts into a few incidents using past incidents, deployment history and application dependencies. Das Deb's example is 5,000 alerts reduced to two incidents, which a person then checks.

### Who is responsible if an AI system gets an incident wrong?

A human and the company are, according to Das Deb. He says you cannot tell a customer the AI did it, so the AI works as a co-pilot while a person makes the decisions.

### How long does it take a team to trust IT automation?

He says it takes years for a complex application, not days or months. Teams earn trust by automating easy, low-risk problems first and being involved in every step, including the failures.

### Where should a business leader start if they want smarter IT operations?

Start by listing where the system hurts most, such as time lost diagnosing issues, poor logs or repeated incidents, and tackle them in priority order. Then make the data structured, add data and AI governance, and measure results.

## Facts

- **Dhrubojyoti Das Deb** [0:02:29]: "if you go back ten or fifteen years, we had systems running with very less logging, very less traceability, very less observability, very less telemetry."
- **Dhrubojyoti Das Deb** [0:03:32]: "when they generate the data that is in silo, that data is not getting fed to the next application, and that happens, and that can get cascaded down."
- **Dhrubojyoti Das Deb** [0:05:21]: "One is running on Java, one is running on Python, one is running on C, and then we have A W S coming in, then we have A I coming in."
- **Dhrubojyoti Das Deb** [0:05:21]: "with C I C D coming into picture, like continuous integration and deployment, applications are changing very fast."
- **Dhrubojyoti Das Deb** [0:06:33]: "this is particularly true for legacy applications. That knowledge may or may not be there because when people leave"
- **Dhrubojyoti Das Deb** [0:07:30]: "We normally try to keep it to a bare minimum of one and three."
- **Dhrubojyoti Das Deb** [0:09:13]: "I'm in the financial business, you know, for the last two decades, like twenty plus years."
- **Dhrubojyoti Das Deb** [0:09:13]: "we service big clients like Amazon and and Walmart and Target and whatnot."
- **Dhrubojyoti Das Deb** [0:08:38]: "company A, which is in investing in technology, they're investing in cloud, they're investing in modernization, they're investing in A I"
- **Dhrubojyoti Das Deb** [0:11:01]: "99% of the data is noise, which are kind of debug messages, which are inform messages, but those are not the actual errors."
- **Dhrubojyoti Das Deb** [0:12:12]: "feed them into A I, and you give A I the proper tools, like, you know, historical data of the prior incidents that were there"
- **Dhrubojyoti Das Deb** [0:12:12]: "it can go through those five, 5,000 messages and tell it like, oh, okay, um, all of them are kind of variation of two incidents."
- **Dhrubojyoti Das Deb** [0:13:14]: "when we do an R C A, what we do is we look at the logs, we look at the traceability, we look at the different me metrics from different places"
- **Dhrubojyoti Das Deb** [0:14:00]: "You cannot trust A I to solve everything for you right on the first day. And so you will have to take baby steps one at a time."
- **Dhrubojyoti Das Deb** [0:15:37]: "A I, we can think of it as a assistant or a co-pilot, and the main person driving the plane at that point of time will still have to be the human."
- **Dhrubojyoti Das Deb** [0:17:46]: "you start prioritizing them by risks or you may prioritize by which one are easy to pick up and then automate those pieces"
- **Dhrubojyoti Das Deb** [0:18:17]: "it will probably take years for a complex application to get automated end to end and take decisions amongst itself."
- **Dhrubojyoti Das Deb** [0:18:45]: "the first risk that has to be owned is not from the development team, but it's more of, you know, the product or the business"
- **Dhrubojyoti Das Deb** [0:20:16]: "whether the same incident is getting repeated over and over again, because that's also indicative of a failure."
- **Dhrubojyoti Das Deb** [0:21:35]: "A I works effectively and best when the data is structured."
- **Dhrubojyoti Das Deb** [0:22:22]: "A I governance is entirely different from data governance where data governance stop A I governance starts from there"

## Transcript

**[0:00:12] Narrator:** Welcome everyone to the AI in Business Podcast. Today's guest is Dhrubojyoti Das Deb, Senior Vice President of Global I T at JPMorganChase. Dhrubojyoti discusses why alert overload has become one of the biggest operational drags on enterprise I T teams, and how A I driven correlation can group thousands of alerts into a handful of actionable incidents. He outlines where human accountability still sits once A I takes on more triage and root cause analysis, and what leaders can do to start moving their teams from reactive firefighting toward more intelligent operations.

**[0:00:44] Narrator:** Today's episode is sponsored by BigPanda. A quick note for our audience that the views and opinions expressed by Dhrubojyoti on today's program are his own and do not reflect those of JPMorganChase or its leadership. In this episode, we cover how A I can help teams cut through alert noise. To go deeper on this topic and learn how to structure landing pages for higher conversion and how to use self-qualification systems to prioritize high-intent leads, download our free P D F report, B to B A I lead generation guide at emerj.com slash A I G one.

**[0:01:16] Narrator:** That's E M E R J dot com slash A I G one to download your copy. Now, the conversation with Dhrubojyoti.

**[0:01:44] Yoland:** Jyoti, welcome to the Emergent A I in Business podcast.

**[0:01:48] Dhrubojyoti Das Deb:** Thanks, Yoland. It's exciting to be here. Thanks for having me over. It's

**[0:01:53] Yoland:** Super exciting and I'm very excited about our conversation today because it's all about trust and alerts and noise and managing all of that. And I think something that comes up in almost every conversation that I have around this topic is that teams are drowning in alerts. And they spend half of their day trying to just figure out which of these alerts are real and need their attention and which is not really an an actual problem. And and you've kind of lived inside of this, so perfect person to ask, where does the friction actually show up for most teams trying to stay ahead of incidents?

**[0:02:29] Dhrubojyoti Das Deb:** Yeah, that's a very interesting question. So right now, I think we have moved from less information or no information to too much information. Like going down the line, like if you go back ten or fifteen years, we had systems running with very less logging, very less traceability, very less observability, very less telemetry. But going forward, like as we had evolved, so has the data, so has the logging, so has the tracing, so has the volume coming in.

**[0:02:57] Dhrubojyoti Das Deb:** The business has evolved and so the data has evolved with it. And we have created intelligent applications to log data. But I think at one point of time, we never had too much thought given into how we are going to handle the data and how we are gonna line the applications in sequence so that we know where the point is coming from, where the issue injection point is coming from. So I would say, in two words, it's alert overload that we are dealing with right now, where we have a complex chain, like a complex chain of systems lined up.

**[0:03:32] Dhrubojyoti Das Deb:** And with different applications stack, like the tech stack that we call, different applications talk to different applications. Each application has their tech stack. And when they generate the data that is in silo, that data is not getting fed to the next application, and that happens, and that can get cascaded down. So, if you look at the whole picture, starting from top to the bottom, there are multiple applications, multiple levels of data, which are kind of sitting in silo.

**[0:03:59] Dhrubojyoti Das Deb:** And there is not a central point which is kind of marrying this data together. So if there is an incident, we are tracking incident at different points in the application, like point one, point two, point three, point four, but not on a holistic level. So much of the time gets into figuring out if the issue is actually coming from the application where the the alert is coming from. So let's say we have five applications which are talking to each other in a sequential manner or in a parallel manner.

**[0:04:28] Dhrubojyoti Das Deb:** And we we have a red dashboard on application number four, which is kind of sitting down at the bottom. Now it so might happen that the data that got generated in and fed into application four, it's impacting application four, but it's a problem with the data that got generated in application number one. So how do we know? Because no alerts came in application number one, it did it, it passed through application two, three, and when it went into four, something flipped, and then it's showing as red.

**[0:04:54] Dhrubojyoti Das Deb:** So how do we know that the issue is there in application four? So bunch of time it will take operations to find out like whether it's not a problem with application four, but it's it's, you know, going beyond and going at the top. So I would say the the main frictions of I D operations right now are one is alert overloading, where there is too much data to process. The second is it's a complex dependency stack because each application when it's talking to another application, it might be in a different stack.

**[0:05:21] Dhrubojyoti Das Deb:** One is running on Java, one is running on Python, one is running on C, and then we have A W S coming in, then we have A I coming in. So all those things create a difference in the dependency stack. So we need to take care of that. The third thing that I would say is with C I C D coming into picture, like continuous integration and deployment, applications are changing very fast. So we we have multiple installs in a week and multiple installs in a month.

**[0:05:48] Dhrubojyoti Das Deb:** So the state of the application that was a week before, it may not be the same as a week after. And all these changes are coming with tons of data which is going down the line. So new data is coming in, is that getting into the traceability? Is that getting into the telemetry like the way it used to? That's another bigger question that we need to deal into. And the fourth thing that I would say is the S M.

**[0:06:10] Dhrubojyoti Das Deb:** E. S. the people who actually know the application because there are engineers who know stuff on the application. And then there are engineers who know what they're doing, but they don't know how the application runs. Now, if there are people to guide those engineers to say like, hey, the application runs like this, they have the knowledge. Like the S M. E. S have the knowledge for the last ten years or twenty years till the application is running.

**[0:06:33] Dhrubojyoti Das Deb:** And this is particularly true for legacy applications. That knowledge may or may not be there because when people leave, that knowledge is getting transferred over. It's not getting transferred over properly. So I would say these are the four main friction areas right now in I T operations, which kind of leads us to have difficulty in filtering the signals from the noise, as I would say.

**[0:06:55] Yoland:** That is crazy. So I'm thinking about, especially your first and second point with the data overload also leads to application overload. And that sounds almost like a thick clutter. I imagine this very cluttered room full of things and you actually don't know where to touch and where to leave and where to find things. And I'm thinking two questions that I have on what you just said. First one is, on average, how many tools does a typical analyst have to open at once during a single incident?

**[0:07:25] Yoland:** Is it between one and three, or are we saying it between three and seven, seven and ten?

**[0:07:30] Dhrubojyoti Das Deb:** We normally try to keep it to a bare minimum of one and three. Because if there are ten applications and if we have a single tool, like for each of them, it becomes very hard for a single analyst to go through ten tools at once, given you know how many monitors that person has. So we try to keep it to a bare minimum and use one, two to service as many applications as can be. So I would say, like, it's in between one and three.

**[0:07:55] Dhrubojyoti Das Deb:** I mean, that that gives you the capability of using that tool to marry the data across different applications. And that way, it can find correlation in between the data that's there.

**[0:08:05] Yoland:** Okay, I I feel a bit better for the analyst having to deal with it because I thought, oh my goodness, if if I had to use ten tools just to diagnose a single incident or to just trace it, I don't know if if that we'll have enough hours in a day. And that takes me to the second question that I have on what you just said, and that is time. Obviously, we have to investigate the incidents, uh, decide what's real, decide what is not real.

**[0:08:29] Yoland:** So how much time do we actually spend on that? Is it worth it to have all of these tools and all of these alerts in consideration with the time that we spend to try and figure out whether they're real?

**[0:08:38] Dhrubojyoti Das Deb:** Well, if you think about it, it's definitely worth it to invest in technology. I would, I would say, like, as we grow with the data, as we grow with the business, we should have the proper tools in hand. And if you don't have, like, you compare a company A and compare company B, and let's say company A, which is in investing in technology, they're investing in cloud, they're investing in modernization, they're investing in A I, and versus company B, which is not investing in any new technology, then, you know, the the rate at which company A will grow will be much higher than company B.

**[0:09:13] Dhrubojyoti Das Deb:** And when I say grow, that, you know, includes everything, starting from the business, starting from, you know, sales, starting from marketing, uh, starting from operation operational effectiveness, and starting from servicing the customers. Because the end goal is to service the customer, like, no matter what business you are in. Like, I'm in the financial business, you know, for the last two decades, like twenty plus years. And our job is to service the transaction. Like, I'm in promotion, service, processing for J P Morgan, and we service big clients like Amazon and and Walmart and Target and whatnot.

**[0:09:47] Dhrubojyoti Das Deb:** And we have to be up all the time. So we have to be resilient, we have to be stable, we have to be high availability. And at the end of the day, what matters is a robust system which can give you the operational effectiveness to dive into issues real time and figure out which which are the false positive and which were the which one are the actual ones. So I would say it's very much needed for a company to have the proper insight, you know, for the leaders to have the proper insight to point their team into proper tools and the advancements that are going on to the system, enhance them, like harness them and put it back into the

**[0:10:21] Dhrubojyoti Das Deb:** application to get some tangible benefits in the future.

**[0:10:24] Yoland:** Oh, what a real answer, eh? Uh, the next part of the conversation is where we touch on the fact that, okay, what if a team admits, listen, we are drowning, we know that we're drowning in alert noise. The next question is then, okay, how do we fix it? And I think that is a a difficult thing all on its own. And we hear a lot about A I correlation and automated alert handling and things like that.

**[0:10:47] Yoland:** But hearing the terms and hearing what the capabilities are, but not so much about what that actually looks like on a day-to-day. So, from your perspective, which A I driven capabilities most reduce that noise and help the team to respond faster?

**[0:11:01] Dhrubojyoti Das Deb:** That's again a great question. Right now, the issue, as we established, it's with the volume and the volume of the data and the speed with which the data is getting generated. And the only task that we need to do is, you know, segregate the signal from the noise, because there's a lot of noise. 99% of the data is noise, which are kind of debug messages, which are inform messages, but those are not the actual errors.

**[0:11:23] Dhrubojyoti Das Deb:** So we'll have to, you know, use some tools to segregate those. And the best thing right now in the market is A I, because we can leverage A I. A I has the speed, um, it it has the mental power to do it, um, however, it doesn't have a mind of it, mind of its own. So what we need to give is a direction, we need to give it a purpose, we need to train the model.

**[0:11:45] Dhrubojyoti Das Deb:** And that is how we can feed the data into A I and and let it do wonderful things. So in terms of A I capabilities, I would say the first thing that hits my mind is, you know, use A I to do intelligent grouping of the events. So let's say there are 5,000 alerts that came in in a in a second, in or in a minute, in the in the application. And it's not possible, for, you know, to have employed 5,000 people to go through each of those alerts, or even like 10,000 people to go through those alerts every minute.

**[0:12:12] Dhrubojyoti Das Deb:** So feed them into A I, and you give A I the proper tools, like, you know, historical data of the prior incidents that were there, or maybe the deployment um incidents that happened over time so that it knows what changed in the system. Or, ah, or or even, you know, the graph in which the application in increased and it enhanced. And let it do the grouping. So what it can do is it can go through those five, 5,000 messages and tell it like, oh, okay, um, all of them are kind of variation of two incidents.

**[0:12:42] Dhrubojyoti Das Deb:** So it can group it into two incidents, and that is what we need to look. So that way, 5,000 incidents are getting reduced to two, and then somebody can go and check these two. So that's where the human in the loop comes in. So A I does the smart work for us, and we take the judgment and decision. So that's that's the combination that we want. Now, the second thing that comes to my mind is like once we have the assessment and the analysis done and we have kind of reduced the number of messages to unique groupings, then we can do a smart R C A because at every incident we have to go through an R C A

**[0:13:14] Dhrubojyoti Das Deb:** process and that is where A I can come in handy very much. And when we do an R C A, what we do is we look at the logs, we look at the traceability, we look at the different me metrics from different places, then we look at the deployment like whether the last change created the issue or you know the issue when it came from a certain file, what was the code structure at that point of time, um, what kind of data came in at that point of time.

**[0:13:36] Dhrubojyoti Das Deb:** We look at the historical data. So if we can have A I sit at top of all the data points, it can, and then it has access to the issue as well. It can go to into each of those points and pull out specific information related to the issue. And then it can correlate each of them at different point of time, saying like, hey, these are the changes that were done in each of these different points, which can lead to the issue.

**[0:14:00] Dhrubojyoti Das Deb:** So it can help with a smart and intelligent R C A. Apart from that, I think it can also help with intelligent remediation in terms of like detection, diagnosis, you know, recommendation, automation, and you know, self-healing. But that that's more of a uh, more of a future process like it will take time, especially the automation and the self-healing part. You cannot trust A I to solve everything for you right on the first day. And so you will have to take baby steps one at a time.

**[0:14:27] Dhrubojyoti Das Deb:** You have to train the system like you're training a child to become a man, right? So so that's that's the thing that we need to do, like handhold the A I, mature it into a system so that it's mature enough to take decisions for us. Uh, keep a human in the loop at every point of time and and slowly, you know, leave the hand so that it can walk along its own path, it can take its own decision and think more of like a human.

**[0:14:49] Yoland:** And if we're saying human in the loop, I'm wondering, obviously, a big part of this conversation is also going into trusting the automation that you eventually, you know, leave the hand of. Um, so, if we're keeping a human in the loop, does the responsibility still stay with the human if the A I gets it wrong during a real incident? So if there's a real incident, A I gets it wrong, who's accountable?

**[0:15:11] Dhrubojyoti Das Deb:** Yeah, I would say definitely somebody has to take the accountability, right? And we cannot say to the customer that, hey, A I did this for you, and we are taking hands off the matter and saying like, A I did this for you, and the customer will come back. They will be really, really annoyed at that point, right? And they will not trust A I anymore. So the company will have to take accountability and responsibility, and we as humans have to take accountability and responsibility for all the decisions that A I takes for us, right?

**[0:15:37] Dhrubojyoti Das Deb:** And that that is why it should be not only A I. I think A I, we can think of it as a assistant or a co-pilot, and the main person driving the plane at that point of time will still have to be the human. And A I will be the co-pilot so that, you know, we can give most of the manual work to be done with A I, which the human cannot do in a short period of time because of the overwhelming data.

**[0:15:59] Dhrubojyoti Das Deb:** And then take the decisions on your side and then it can be a cyclic loop as well. Like you take the decision, you send it to A I, ask A I to do specific stuff. A I does it for you, you validate it, then you send it down again and it will refine it for you, deploy it into production and then do the observability and traceability and met matrix and everything and feed that data again into A I.

**[0:16:20] Dhrubojyoti Das Deb:** So it's kind of a cyclic loop at different processes and that is how we refine the system.

**[0:16:25] Yoland:** Yeah, okay, that makes a lot of sense. And I think that's also a way to get our humans to trust it more because they are hands-on working with it and seeing how it reacts every time that it keeps on feeding it the information. And that's where I wanted to ask you if I'm gonna tell a team, okay, we now have A I integrated into the workflows and certain workflows will be completely automated and we need you to trust it, but you will still be held accountable if something goes wrong.

**[0:16:49] Yoland:** How long realistically does it take for a team to adapt to that idea and to actually start to trust the automation?

**[0:16:55] Dhrubojyoti Das Deb:** That's a pretty good question. In order for a team to trust the automation, they will have to be hands-on and be a part of the process of automating it. If I'm not not a part of the team, like, so that's where the different groups come in, not only the dev development team, because it's mainly the development team who does the automation, then they hand it off to the product, right? And the product hands it off to the business or the sales and or it can go in front of the customer, right?

**[0:17:23] Dhrubojyoti Das Deb:** But if the product does not know what the automation was or i is not a part of the process, then they will not have any trust in the system. Now, as I said, like, we'll have to take baby steps at a time, and that goes true for the development team. So, you know, start from the beginning, try to figure out what are the different frictions that are there, like, what are the operational FRI frictions in the system?

**[0:17:46] Dhrubojyoti Das Deb:** And then you list out all the operation friction and then you start prioritizing them by risks or you may prioritize by which one are easy to pick up and then automate those pieces which are easy to pick up which can go into production like which can be deployed into production and once you take those baby steps that would take you give you enough confidence in in you know to go into larger set. So let's say you have ten operational frictions and you have already targeted two, those are working well, and then you can think about migrating the rest eight.

**[0:18:17] Dhrubojyoti Das Deb:** So it will take time, like it's not a thing that can be done in a matter of days or months. Uh, it will probably take years for a complex application to get automated end to end and take decisions amongst itself. But it's a journey that we have to start with all the leaders and all the groups in it, starting from business, from product, from tech team, so that everyone is at the same page on what the automation is happening and what A I is capable of doing and what are the risks associated with it.

**[0:18:45] Dhrubojyoti Das Deb:** And it's it's kind of a shared risk, I would say. But the first risk that has to be owned is not from the development team, but it's more of, you know, the product or the business because they are they are the ones who are selling it out to the customers. So, they should be more aware of what the automation is and, you know, what the risks associated can be.

**[0:19:04] Yoland:** So it's very much a grab the team and say, listen, team, we're going on a road trip. Everyone get in the bus. And as we go down this road, we're gonna get a flat tire at some point. We might run out of gas. We might get into a small little bumper bash. And we fix it as we go. And the next time the team has to go down the same road without navigation, without. They're already prepared for what could go wrong and how to handle it and trust the process and know what the end goal is.

**[0:19:28] Yoland:** That's the image that we're picturing, right?

**[0:19:30] Dhrubojyoti Das Deb:** Absolutely. I mean, kind of replaying the same stuff over and over again and trying to list out all the possibilities, all the risks that are associated with it. So that at one point of time, you are so much familiar into the process that you can drive along the road with your eyes closed, and that's the ultimate goal.

**[0:19:47] Yoland:** That's exactly where we wanna be. The last one before we say our goodbyes today, but I know you're coming back for one more episode, so it's just goodbye for now. But last one for this episode. Say a a leader is listening to this, and there are sold on the idea that, okay, you know, automation can be trusted. There is a way to do this, but they have no clue to actually start, or where to start. What practical steps can they take to move from reactive workflows to more intelligent operations?

**[0:20:16] Dhrubojyoti Das Deb:** In that scenario, what I suggest is we'll have to start with knowing the system pretty well and then figuring out what the issues are with the system, ask questions on what the operational frictions are there, as I called out before, list them in in order of priority, in order of risks, uh, wha- what, what things, what they are getting bitten by more, like whether is is it the time that they're investing to figure out an issue, or whether it's the like logs are not properly evaluated, whether the same incident is getting repeated over and over again, because that's also indicative of a failure.

**[0:20:52] Dhrubojyoti Das Deb:** So those are the things that needs to be figured out and listed somewhere before, you know, the leaders take the decision of, you know, addressing things one by one. If they try to do all things at once, it will not be possible. So, we need to have a game plan. We need to start with baby steps at a time, but we need to know what the system is doing, what is what is wrong in the system.

**[0:21:13] Dhrubojyoti Das Deb:** And then have a kind of a project plan for the bigger time to have two or three things done, one things at a time and then integrate the whole thing from bottom up. So that would be the first thing like figure out the oper operational friction frictions and then segregate the ones and come up with a game plan. The second thing that they can do is they will have to build the data architecture so that can be fed into A I.

**[0:21:35] Dhrubojyoti Das Deb:** And A I works effectively and best when the data is structured. So if they produce like if their applications produce unstructured data, like, let's say, an application is running and a sub-module is running in it, and the sub-module produces the data, but it doesn't have the timestamp, it doesn't have the name of the sub-module, it doesn't have the name of the application, and it doesn't have any relation to what the data is is about, like, what the error is about.

**[0:22:01] Dhrubojyoti Das Deb:** When you feed it to A I, it will not have a freaking clue of what where it's coming from, where it's coming from, application A, where it's coming from, application B, or even what the sub-module name is. So those are the things that needs to be set at the basic ground level. And once we do that, we have to change the system to have a structured data that can be fed into A I. So that's the second thing.

**[0:22:22] Dhrubojyoti Das Deb:** And the third thing I would say is we we have to have guardrails and governance in it. The data governance as well as the A I governance because A I governance is entirely different from data governance where data governance stop A I governance starts from there because A I governance hopes or rather it assumes that the data governance is already in place and that is on top of it you can do A I governance so we need to have proper guardrails we have to have proper boundaries set for each of the applications or each of the groups in place so that they know that we are not going beyond what needs to be you know beyond our scope of where

**[0:22:57] Dhrubojyoti Das Deb:** we are going and the last thing I would say is measurability

**[0:24:05] Yoland:** Great and so comprehensive, such a comprehensive starting kit of information that you just shared with our audience. I think that's gonna be extremely valuable. To wrap up our discussion today, I think what our listeners really need to understand is that alert fatigue is not solved by adding more tools. In fact, it's quite the opposite. It's it's kind of solved by deciding which of the noise and the alerts actually deserves human attention. And then for the second part of our conversation, I think the theme was very much A I earns trust in the operation very gradually.

**[0:24:37] Yoland:** It's not an overnight thing. We will have small wins, but we will have to get the team involved in those wins and also involved in the failures and keep on feeding it the same information until you are completely satisfied that the return information is exactly what you needed to be for your team. And then, like you just said, for our leaders, start with the most noisy workflow almost and not a company-wide overall. Because, like you just said, if you're gonna try and do everything all at once, everything's gonna fail all at once.

**[0:25:03] Yoland:** So it was great having you on the show. Great conversation. I'm very excited for uh the next time I get you to be on the show, which is gonna be very soon. Thank you so much.

**[0:25:14] Dhrubojyoti Das Deb:** Thank you. Thanks for having me again.

**[0:25:30] Narrator:** Wrapping up today's episode, let's look at the three key takeaways from our conversation with Dhrubojyoti. First, alert fatigue isn't solved by adding more tools. It's solved by deciding which signals deserve human attention in the first place. Second, A I earns trust in operations gradually, through small validated wins, rather than full automation on day one. And finally, leaders should start with their noisiest workflow, not a company-wide rollout, to build the data foundation and confidence automation requires.

**[0:25:58] Narrator:** In this episode, we covered how A I can help teams cut through alert noise. To go deeper on this topic and learn how to structure landing pages for higher conversion and how to use self-qualification systems to prioritize high-intent leads, download our free P D F report, B to B A I lead generation guide at emerj.com slash A I G one. That's E M E R J dot com slash A I G one to download your copy.

**[0:26:22] Narrator:** For further executive level analysis and to join our network of leaders delivering workflow impact with A I, visit emerj.com. On behalf of the team at Emerge, we'll see you on the next episode.