1,368 AI Failures and What They Teach About Evals — Vishal Srivastava & Tanmay Sah, New York Life

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: 1,368 AI Failures and What They Teach About Evals — Vishal Srivastava & Tanmay Sah, New York Life · Channel: AI Engineer · 19:55 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, AI governance and regulation, AI safety

Summary

Vishal Srivastava and Tanmay Shah analyze 1,368 AI incidents to develop a framework for evaluating AI systems across technical strength, deployment controls, and business context. Their analysis finds that incidents often involve multiple dimensions and that deployment controls are especially associated with harm. They argue for risk-based, system-level evaluations that test the full deployment setup, including tools, human review, permissions, and monitoring. A failure-driven build-break-fix process can expose weaknesses, guide controls, and help determine where deployment is appropriate.

Key points

AI failures have risen sharply, making structured investigation more practical than reviewing every use case individually.
The framework considers three dimensions: technical strength, deployment controls, and business context.
Its 13 sub-dimensions cover factors such as data quality, system design, fairness, human mediation, monitoring, financial impact, legal consequences, and scale.
The framework covers almost 98% of the AI failures examined; incidents involve an average of six sub-dimensions.
Deployment controls are more strongly associated with harm than business impact or technical failures alone.
Risk depends on how a system is deployed, including its authority, human review, and the ability to detect errors.
Agentic-system evaluations should test the broader setup, such as retrieval, tool failures, permissions, human review, and recovery.
Evaluators, including AI judges, can make mistakes, so their reliability and evidence coverage also need governance.
Evaluations should be failure-driven: define a claim, try to falsify it, fix weaknesses, and repeat the tests.
The presenters recommend risk-based rather than frequency-based evaluations and deployment only in regions where confidence is sufficient.

Chapters

Start	Chapter	Summary
00:01	Why investigate AI failures?	The speakers introduce their incident-based research and argue that rapidly increasing failures call for a structured way to investigate AI systems.
03:08	A framework for classifying incidents	They present three system-level dimensions and describe sub-dimensions covering technical strength, deployment controls, and business impact.
06:17	What incident patterns reveal about harm	The analysis finds that the framework covers almost 98% of examined failures, which often involve multiple dimensions, and highlights the importance of deployment controls.
09:24	Materiality and system-level evaluations	The speakers propose prioritizing use cases by materiality and explain why evaluations must account for the deployment setup and the full agentic system.
13:38	Failure-driven evaluation	Drawing on confirmation bias research, the speakers recommend testing claims by trying to falsify them through an iterative build-break-fix process.
16:45	Airline chatbot case and closing recommendations	An airline chatbot failure illustrates how to test policy advice and add controls, followed by a recommendation to evaluate full systems according to risk.

Quotes

almost 98% of AI failures can be covered. — 06:17

controls that we have in deployment are more critically associated with harm — 08:53

any evaluation that needs to be done has to falsify, not to confirm. — 14:41

perform this build-break-fix loop — 15:42

evaluate the full AI system based on risk, not just one component. — 19:23

Concepts and entities

AI incident database, System-level evaluation, Materiality scale, Failure-driven evaluation, Confirmation bias, Vishal Srivastava, Tanmay Sah, New York Life, AI Engineer

Full transcript (original language)

00:01 [music] >> A big part of my research is looking into AI failures, investigating it, and then learning from it. And joining me is Tanmay Shah. >> Yeah, hi everyone. I’m Tanmay Shah. I’m a senior quantitative modeler and an AI researcher. This is my second time here, so it’s great to be back. So, I will hand it over to Vishal to get us a

00:33 started. >> So, we looked at AI incident database. It’s a publicly available AI incident database, and we looked at the AI failures and asked one simple question, what these failures teach us about how this is how the AI system should be evaluated, and if we can apply those learnings to system level evaluation. So, the first thing that we see is that

01:04 AI failures have been increasing exponentially. And if you look at the last four years of AI failures, particularly in the foundational model era, you see that the jump is almost vertical. And many of us feel that the number of AI use cases that we have in enterprises, they they are much larger than our capacity to review them each one by one. So, what

01:36 we argue is that we need a structured way to investigate these AI failures. And to do that, we look at the AI failures essentially into three dimensions. The first dimension is the development stage, when the model and or the AI system is developed. So, it could be issues with respect to data quality or tool architecture or system design. Any of these things

02:07 during the development phase can can break and once it happens, then those errors can be propagated to the next dimension, which is the deployment phase. Now, even if the model or the system has some faulty design issues, but if you have sufficient controls in deployment, those errors can be contained. And that is why it is very important to kind of understand what

02:37 kind of controls do we have in deployment and whether we can contain those failures from reaching from deployment production platform to the final stage, which is the context in which the AI system is being used from a business standpoint. It could lead to reputational risk. It could lead to legal or financial risk and all those business context really matters for the AI system in which it is being

03:08 used. And what we say what we propose is that the model alone or the technical strength of the model is just one part of the system. We have to look at the system holistically. So, after defining those three core dimensions, the technical strength where the system should be strong or in opposite way where the system can break, the second dimension is how do we ensure that the deployment controls

03:39 are in place? And third, the business context the AI system is being used. We divide each of these core dimensions into several sub dimensions. So, in the from the technical strength point, right? There could be six major sub dimensions which could be affecting the technical strength of the AI system. It could be first related with the data quality that we use for to build the AI system. How the system has been designed for the

04:11 appropriate task that it is supposed to accomplish. How is the predictive validity or outcome analysis of the out of of the AI system? Does that system perform as we intend? Um there could be fairness related um checks. Um failure modes essentially looks at where when, how, and for whom the uh system can break. Uh so, basically mapping out all the failure modes of the system. And finally, can we explain for

04:43 uh explain the decisions for the regulators or other bodies uh so that we know how the system is arriving at its decision. So, these six sub dimensions are essentially part of the technical strength of the AI system. The next four are essentially looking at how we are using the model. Um what kind of authorities we have given to the AI, right? Is the AI for informing us or it it is out there to act on our behalf.

05:14 What kind of decision authority are we associating with respect to AI? Uh second one, human mediation. Um how effective is human in the loop process is, right? That’s really important. The third one, exposure control. Who’s actually using the uh system? Is it internal employees so that they see the error and they can contain it or it is exposed to the out there in the wild external customers so that any small issue can really propagate fast. And finally, what kind of monitoring uh controls that we have

05:46 so that we see some uh issues in production and we detect it and we can contain it. Finally, in the financial or the business impact phase, we see these three core sub-dimensions. What kind of financial impact it would make if there is an error? There could be legal consequences and how many users would get affected? That’s the the last one, the scale sub-dimension. So, we

06:17 we we look at this this as one framework which has 13 dimensions and three core questions as we explained. Once we define these 13 sub-dimensions and look back at AI incident retrospectively, we find that using these 13 sub-dimensions, almost 98% of AI failures can be covered. Meaning that AI failures are are associated with some of these dimensions, in some cases multiple of

06:48 these dimensions, and in some cases few of these dimensions. But, these dimensions are involved. So, failure AI failures have structures. We need to map it and we need to act accordingly according to these sub-dimensions. Now, as I mentioned that some of these failure sub-dimensions can be present in these failures simultaneously. Meaning that when something goes wrong with respect to a particular failure, there may be multiple things going wrong. What

07:20 we find is that on average, there are six failure sub-dimensions that can be present in each of these AI incident failures that we we we have investigated. Now, the question comes to our mind is that are all of these sub-dimensions are equal or some are more important than others. And the answer is that some of the sub-dimensions can be more critical than others. And what I’m

07:51 showing you here in the in the plot on the Y-axis is the association to harm when these sub-dimensions are present. And on X-axis, we have the frequency of these sub-dimensions being present. What we see on the left upper side of the plot, sub-dimensions like human mediations or effectiveness of human in the loop, harm detection, meaning that whether we have monitoring control in place. On on X-axis, we see things like scale and system design. Although they are present

08:22 in many cases, but they are not associated so much with harm as some of the some of some of the earlier sub-dimensions that I have mentioned. So, when we are really looking at the AI systems, some of these sub-dimensions can be really critical. So, we need to prioritize these sub-dimensions by the potential of making harm, and then allocate appropriate resources to the to the investigation of these sub-dimensions rather than looking at all the failure

08:53 sub-dimensions equally. And when we club the when we group these sub-dimensions together, we see that controls that we have in deployment are more critically associated with harm, followed by the business impact, and followed by the technical failure. So, this plot is essentially telling us that once once we have deployment controls taken care of for the high-risk system,

09:24 that gives us some level of assurance that we can take care of the failures in in advance in contrast to just looking at the technical failure alone. So, all these sub-dimensions are important, but deployment controls are far more important. And what in the next phase what we did was we we designed a materiality scale, meaning that if we can understand which AI use

09:55 cases are more risky compared to some others, we can we can prioritize these AI use cases based on materiality because materiality directly rank orders with respect to the harm associated with this AI use cases. Meaning that we can spend suppose we know which AI cases are more more material then we can allocate more resources to much higher material AI use cases than compared to some other AI use cases which may not be

10:27 as material. With that, I would hand over to Tanmay who would explain how we can use those learnings to build system-level evals. >> Thanks, Vishal. Uh so, so far as we have seen what these failure teach us, so now let us use those lessons to build system-level evaluations. So, first first of all, what we did is that we have decomposed risk into four components, which are how often the

10:58 model fails, whether that failure reaches a real decision, whether it goes whether it goes uncaught, and how severe the consequences are. So, in this scenario, the deployment setup matters, how much authority does the system have, does someone review its output, can monitoring catch error before it causes harm? So, this same model can create different risk depending on how we deploy it. So,

11:32 what we are saying is that if risk depends on the whole deployment system, our evaluation needs to cover that setup, too. So, that brings us to the next question. What should we test in an agentic system? So, see, in traditional machine learning, we already know how to challenge models. We test their assumptions, input data, and behavior under stress. Now, when we extend that discipline to the whole deployment system, then, like, does retrieval bring

12:04 back the right information? Or what happens when a tool fails? Does human review catch mistake? Or does the agent stay within its permission or boundary? And can the system finally recover? So, here the logic stays the same. The boundary of what we test gets bigger. So, now the question is, how should we test an agentic system? So, on the right, we have the familiar traditional ML. We test a model on held-out data, calculate metrics like

12:36 accuracy and AUC ROC, use those evidence to inform deployment. But, we still need to check the data and assumptions behind those metrics. But, on the left-hand side, we have an agentic system which adds new complexity. So, the deployment system, like, it has many possible inputs, tool responses, and action sequences, or trajectory, or rollout, whatever you dis- say. So, we test selected scenarios. Sometimes, another

13:08 AI uh agent or AI judge generates those tests or judges the result. So, but that judge can make mistakes, and the test can miss important failures. So, this is where we need to check whether the evaluator is reliable, what the evidence covers, and whether it applies to the system we are actually deploying it. That’s why the evaluator is the part of the system we govern. So, now I will

13:38 hand it over to Vishal to explain how we can check whether an evaluation is reliable and what to do when it is not. >> Thank you, Tanmay. So, we have seen the system level evaluation for evaluator as well as you know, the whole AI system. The question is that how should we really And when I was looking at some of the previous research, particularly in the area of cognitive neuroscience, what I

14:09 found was the um this the scientist Peter Wason, he’s the one who coined this term confirmation bias. And essentially what he did was he did a bunch of experiments, but essentially uh in this case here, the series that you see 2 4 6, right? He was asking people to predict the next number, and more often than not, they were predicting 8 10, like even numbers. But those answers was those answers were incorrect because essentially the correct number was any increasing

14:41 number. Essentially proving that all humans, like most humans, um in this case it 79% of people tested wrong. Um may have some sort of confirmation bias. And AI systems, as we know, uh are trained on human-generated data. So, what what he proposed was that any evaluation or any any evaluation that needs to be done has to falsify, not to confirm. And that that’s the way to go about it. And we

15:12 take that learning from his research and propose that eval system needs to be failure-driven. So, if the eval systems are failure-driven, what would that mean? That would mean that you would start right from looking at your system claim and testing it and trying to break it and then identify where the system claims are breaking, right? And then what you do for fix? Either you uh don’t let the AI system run in you know,

15:42 in the in the in the territory where uh there are failures or you come up with uh supporting systems, right? Which you are confident of. And you keep doing it iteratively uh until you get um you to the to the level of confidence, right? This is essentially the first principles based approach that we propose for any evaluation system. So, essentially you take take your AI systems, perform this build-break-fix loop, understand where the AI systems

16:14 could be trusted in terms of its uh uh final outcomes, and also a map out uh the uncertain region and high-risk region where you can not be very sure of the system’s performance, and you map out the entire failure region map and route it based on the reliability and materiality, meaning that particularly if you’re using AI for any high-risk rated system, make sure that your AI is only being

16:45 used for um the the the region that you’re confident of. And with this, I will hand over to Tanmay who who who who would apply this approach to a real uh AI failure case. >> Okay, I sure. So, uh so, uh let’s make this framework concrete and see how a narrow evaluation can miss failures uh that matters in the real world. So, I will quickly go through the story behind it. So, a

17:16 customer needed to travel after a death in the family. He asked an Airlines chatbot about a discounted fare. The chatbot said he could buy a regular ticket and claim the discount afterwards within 90 days. So, he relied on that advice, but the airline later refused because its policy uh did not allow that request. Then finally, the tribunal held the airline responsible. So, through this example, we we are seeing the failure chain. So, it’s crystal clear. So, incorrect advice

17:48 reaches the customer, the customer acts on it, and the organization faces the consequences. So, if we apply our build, break, fix, and break again approach, uh that could have exposed the failure way before the deployment. So, we Ideally, we would start with a clear requirement like advice must match the approved policy. Then we would challenge the chatbot with questions about refunds after travel. If those tests exposed incorrect advice, then we could add a

18:20 policy check or human escalation. Then we would test again to see whether those controls caught the errors before it reached the customer. So, that’s our framework in practice. We have to define the claim, actively challenge it, and use the evidence guide changes and make a deployment decision. So, finally, I will hand it over to Vishal to bring the pieces together and conclude. >> Um this is our final slide. So,

18:51 essentially, what we are saying is that your evals should be risk-based um rather than frequency-based. You should look at your uh entire system and then break it into the core components like technical uh failure, deployment controls, and business context. And then assess your AI use cases materiality with some uh scale, uh and that could be your company specific scale and risk should that risk could change. And then once you have that,

19:23 apply the system level stress testing on the AI use case. And then once you are confident about the region, then only make the deployment decision. Otherwise, it may be too expensive. Our final takeaway message is evaluate the full AI system based on risk, not just one component. Thank you so much for your time and attention. You can feel free to reach out to us outside. We’d be happy to take any questions later.

19:55 >> [applause]