1.368 falhas de IA e o que elas ensinam sobre evals — Vishal Srivastava e Tanmay Sah, New York Life

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: 1,368 AI Failures and What They Teach About Evals — Vishal Srivastava & Tanmay Sah, New York Life · Canal: AI Engineer · 19:55 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Governança e regulação de IA, Segurança de IA

Resumo

Vishal Srivastava e Tanmay Sah analisam uma base pública de incidentes de IA para propor um framework que organiza as falhas em dimensões técnicas, controles de implantação e contexto de negócios. A análise indica que controles de implantação estão mais associados a danos do que falhas técnicas isoladas, e que avaliações devem priorizar o risco e a materialidade de cada caso de uso. Para sistemas agênticos, defendem avaliar o sistema completo, incluindo ferramentas, revisão humana, monitoramento e limites de permissão, além de verificar a confiabilidade dos próprios avaliadores. A abordagem proposta é orientada a falhas: definir uma alegação, tentar refutá-la, corrigir problemas e testar novamente antes de decidir pela implantação.

Pontos-chave

Os pesquisadores organizaram as falhas de IA em três dimensões: força técnica, controles de implantação e contexto de negócios.
O framework tem 13 subdimensões e, segundo a análise apresentada, abrange quase 98% das falhas de IA examinadas.
Cada incidente analisado envolvia, em média, seis subdimensões de falha.
Os controles de implantação, como revisão humana e monitoramento, estão mais associados a danos do que as falhas técnicas isoladas.
A materialidade pode ajudar a priorizar casos de uso e direcionar recursos para os que apresentam maior risco de dano.
A avaliação de sistemas agênticos deve incluir respostas de ferramentas, sequências de ações, recuperação de erros e limites de permissão.
Os avaliadores também precisam ser avaliados: podem cometer erros e deixar de detectar falhas importantes.
Uma avaliação orientada a falhas busca refutar as alegações sobre o sistema por meio de ciclos de construir, quebrar, corrigir e testar novamente.
O exemplo do chatbot de uma companhia aérea mostra como um conselho incorreto pode levar um cliente a agir e resultar em consequências para a organização.
A decisão de implantação deve considerar o sistema completo e o risco, não apenas o desempenho de um componente.

Capítulos

Início	Capítulo	Resumo
00:01	Análise de falhas de IA	Os palestrantes apresentam o objetivo de analisar incidentes de IA e estruturar o aprendizado obtido com as falhas.
03:08	Dimensões do framework de falhas	A apresentação detalha dimensões técnicas, controles de implantação e impactos de negócios para classificar incidentes.
06:17	Cobertura, priorização e materialidade	Os pesquisadores relatam a cobertura do framework, comparam a associação entre dimensões e danos e propõem priorizar casos por materialidade.
10:27	Avaliação de sistemas agênticos	Tanmay explica como avaliar o sistema completo, incluindo ferramentas, supervisão humana, permissões e confiabilidade dos avaliadores.
13:38	Avaliações orientadas a falhas	A partir do viés de confirmação, Vishal defende testar alegações tentando quebrá-las e corrigir os problemas de forma iterativa.
16:45	Exemplo do chatbot de uma companhia aérea	Um caso de orientação incorreta sobre uma tarifa ilustra como testar requisitos, controles e escalonamento antes da implantação.
18:51	Conclusões: avaliar o sistema pelo risco	Os palestrantes recomendam avaliações baseadas em risco e a implantação apenas nas regiões em que há confiança suficiente.

Citações

Quase 98% das falhas de IA podem ser cobertas usando essas 13 subdimensões. — 06:17

Os controles de implantação são muito mais importantes do que olhar apenas para a falha técnica. — 09:24

O sistema de avaliação precisa ser orientado a falhas. — 15:12

Avalie o sistema de IA completo com base no risco, não apenas um componente. — 19:23

Conceitos e entidades

AI incident database (conceito): Base de dados pública de incidentes de IA usada pelos pesquisadores para analisar padrões de falhas.
System-level evaluation (conceito): Avaliação que considera o sistema de IA completo, incluindo sua implantação, controles e contexto de uso.
Materiality scale (conceito): Escala proposta para ordenar casos de uso de IA conforme a materialidade e o dano associado.
Failure-driven evaluation (conceito): Abordagem de avaliação que tenta refutar as alegações sobre um sistema e identificar onde ele falha.
Confirmation bias (conceito): Tendência a buscar ou interpretar evidências de modo a confirmar uma hipótese, em vez de tentar refutá-la.
Vishal Srivastava (pessoa): Pesquisador que apresenta a análise de incidentes de IA e o framework de avaliação baseado em risco.
Tanmay Sah (pessoa): Pesquisador que apresenta a avaliação de sistemas agênticos e o exemplo do chatbot de uma companhia aérea.
New York Life (empresa): Organização mencionada no título como afiliada aos palestrantes.
AI Engineer (empresa): Canal do YouTube que publicou a apresentação.

Tradução completa (pt-BR)

00:01 [música] >> Grande parte da minha pesquisa consiste em analisar falhas de IA, investigá-las e aprender com elas. E está aqui comigo Tanmay Shah. >> Sim, olá a todos. Sou Tanmay Shah. Sou modelador quantitativo sênior e pesquisador de IA. Esta é minha segunda vez aqui, então é ótimo estar de volta. Vou passar a palavra para Vishal para que ele dê início a

00:33 >> Então, analisamos uma base de dados de incidentes de IA. Ela é pública, e examinamos as falhas de IA fazendo uma pergunta simples: o que essas falhas nos ensinam sobre como os sistemas de IA devem ser avaliados e se podemos aplicar esses aprendizados à avaliação em nível de sistema. A primeira coisa que vemos é que

01:04 as falhas de IA têm aumentado exponencialmente. E, se olharmos para os últimos quatro anos de falhas de IA, especialmente na era dos modelos fundacionais, veremos que o aumento é quase vertical. Muitos de nós sentimos que o número de casos de uso de IA que temos nas empresas é muito maior do que nossa capacidade de analisar cada um deles individualmente. Então, o que

01:36 defendemos é que precisamos de uma maneira estruturada de investigar essas falhas de IA. Para isso, analisamos as falhas de IA essencialmente em três dimensões. A primeira dimensão é a etapa de desenvolvimento, quando o modelo e/ou sistema de IA é desenvolvido. Pode haver problemas relacionados à qualidade dos dados, à arquitetura das ferramentas ou ao design do sistema. Qualquer uma dessas coisas

02:07 durante a fase de desenvolvimento pode falhar e, quando isso acontece, os erros podem se propagar para a dimensão seguinte, que é a fase de implantação. Mesmo que o modelo ou sistema tenha problemas de design, se houver controles suficientes na implantação, esses erros podem ser contidos. Por isso, é muito importante entender

02:37 que tipos de controles temos na implantação e se conseguimos impedir que essas falhas avancem da implantação para a plataforma de produção e cheguem à etapa final: o contexto em que o sistema de IA é usado do ponto de vista empresarial. Isso pode gerar riscos reputacionais, jurídicos ou financeiros, e todo esse contexto empresarial realmente importa para o sistema de IA em que ele está sendo

03:08 usado. O que dizemos, o que propomos, é que o modelo sozinho, ou a força técnica do modelo, é apenas uma parte do sistema. Precisamos analisar o sistema de forma holística. Então, depois de definir essas três dimensões centrais — a força técnica, isto é, em que o sistema deve ser forte ou, pelo contrário, em que ele pode falhar; a segunda dimensão é como garantimos que os controles de implantação

03:39 estejam implementados; e, em terceiro lugar, o contexto empresarial em que o sistema de IA é usado —, dividimos cada uma dessas dimensões centrais em várias subdimensões. Do ponto de vista da força técnica, há seis subdimensões principais que podem afetar a força técnica do sistema de IA. A primeira pode estar relacionada à qualidade dos dados que usamos para criar o sistema de IA. Como o sistema foi projetado para a

04:11 tarefa adequada que deve realizar? Como são a validade preditiva ou a análise dos resultados do sistema de IA? O sistema tem o desempenho que esperamos? Também pode haver verificações relacionadas à equidade. A análise dos modos de falha examina onde, quando, como e para quem o sistema pode falhar. Basicamente, mapeia todos os modos de falha do sistema. E, por fim, conseguimos explicar

04:43 as decisões aos órgãos reguladores ou a outras entidades, para que saibamos como o sistema chega às suas decisões? Essas seis subdimensões fazem parte da força técnica do sistema de IA. As quatro seguintes analisam essencialmente como usamos o modelo. Que tipo de autoridade demos à IA? Ela serve para nos informar ou está ali para agir em nosso nome?

05:14 Que tipo de autoridade decisória associamos à IA? A segunda é a mediação humana. Qual é a eficácia do processo com participação humana? Isso é muito importante. A terceira é o controle de exposição. Quem está usando o sistema? São funcionários internos, que podem perceber o erro e contê-lo, ou o sistema está exposto a clientes externos em geral, de modo que qualquer pequeno problema possa se propagar rapidamente? E, por fim, que tipo de controles de monitoramento temos

05:46 para identificar problemas em produção, detectá-los e contê-los? Por fim, na fase de impacto financeiro ou empresarial, vemos estas três subdimensões centrais. Qual seria o impacto financeiro de um erro? Pode haver consequências jurídicas. E quantos usuários seriam afetados? Essa é a última: a subdimensão de escala. Então,

06:17 analisamos isso como uma estrutura com 13 dimensões e três perguntas centrais, como explicamos. Depois de definir essas 13 subdimensões e analisar retrospectivamente os incidentes de IA, descobrimos que elas conseguem abranger quase 98% das falhas de IA. Isso significa que as falhas de IA estão associadas a algumas dessas dimensões — em alguns casos, a várias delas

06:48 e, em outros, a poucas delas. Mas essas dimensões estão envolvidas. Portanto, as falhas de IA têm uma estrutura. Precisamos mapeá-la e agir de acordo com essas subdimensões. Como mencionei, algumas dessas subdimensões de falha podem estar presentes simultaneamente nesses incidentes. Ou seja, quando algo dá errado em relação a uma falha específica, várias coisas podem estar dando errado. O que

07:20 descobrimos é que, em média, há seis subdimensões de falha que podem estar presentes em cada um dos incidentes de falha de IA que investigamos. Então, surge a pergunta: todas essas subdimensões são iguais ou algumas são mais importantes do que outras? A resposta é que algumas podem ser mais críticas do que outras. E o que estou

07:51 mostrando aqui no gráfico é a associação com danos no eixo Y, quando essas subdimensões estão presentes. No eixo X, temos a frequência com que elas aparecem. No canto superior esquerdo do gráfico, vemos subdimensões como a mediação humana, ou a eficácia da participação humana no processo, e a detecção de danos, isto é, se temos controles de monitoramento implementados. No eixo X, vemos aspectos como escala e design do sistema. Embora apareçam

08:22 em muitos casos, eles não estão tão associados a danos quanto algumas das subdimensões que mencionei antes. Portanto, ao analisar os sistemas de IA, algumas dessas subdimensões podem ser realmente críticas. Precisamos priorizá-las de acordo com seu potencial de causar danos e, então, alocar recursos adequados à investigação dessas subdimensões, em vez de analisar todas as subdimensões de falha com a mesma prioridade.

08:53 E, quando agrupamos essas subdimensões, vemos que os controles implementados na implantação estão mais fortemente associados a danos, seguidos pelo impacto empresarial e, depois, pelas falhas técnicas. Portanto, este gráfico está essencialmente nos dizendo que, se cuidarmos dos controles de implantação para sistemas de alto risco,

09:24 teremos algum nível de garantia de que podemos lidar com as falhas com antecedência, em vez de olhar apenas para as falhas técnicas. Todas essas subdimensões são importantes, mas os controles de implantação são muito mais importantes. Na etapa seguinte, o que fizemos foi criar uma escala de materialidade. Ou seja, se conseguirmos entender quais casos de uso de IA são mais arriscados do que outros, poderemos

09:55 priorizar esses casos de uso de IA com base na materialidade, porque a materialidade os ordena diretamente de acordo com os danos associados a esses casos. Isso significa que podemos investir — suponhamos que saibamos quais casos de IA têm maior materialidade — mais recursos nos casos de uso de IA com materialidade muito maior do que em outros casos de uso de IA que talvez não sejam

10:27 tão materiais. Com isso, passo a palavra a Tanmay, que vai explicar como podemos usar esses aprendizados para criar evals em nível de sistema. >> Obrigado, Vishal. Até agora, vimos o que essas falhas nos ensinam. Agora, vamos usar essas lições para criar avaliações em nível de sistema. Antes de tudo, o que fizemos foi decompor o risco em quatro componentes, que são: com que frequência a

10:58 o modelo falha, se essa falha chega a uma decisão real, se ela passa despercebida e qual é a gravidade das consequências. Então, neste cenário, a configuração de implantação importa: quanta autoridade o sistema tem? Alguém revisa a saída dele? O monitoramento consegue detectar o erro antes que ele cause danos? Portanto, esse mesmo modelo pode criar riscos diferentes dependendo de como o implantamos. Então,

11:32 o que estamos dizendo é que, se o risco depende de todo o sistema de implantação, nossa avaliação também precisa abranger essa configuração. Isso nos leva à próxima pergunta: o que devemos testar em um sistema agêntico? Veja, em machine learning tradicional, já sabemos como desafiar modelos. Testamos suas premissas, os dados de entrada e o comportamento sob estresse. Agora, quando estendemos essa prática a todo o sistema de implantação, a recuperação de informações traz

12:04 as informações corretas? Ou o que acontece quando uma ferramenta falha? A revisão humana detecta o erro? O agent permanece dentro das permissões ou dos limites? E, por fim, o sistema consegue se recuperar? Então, a lógica continua a mesma. O escopo do que testamos é que fica maior. Agora, a pergunta é: como devemos testar um sistema agêntico? À direita, temos o machine learning tradicional, que conhecemos. Testamos um modelo com dados separados para teste e calculamos métricas como

12:36 acurácia e AUC ROC, e usamos essas evidências para orientar a implantação. Mas ainda precisamos verificar os dados e as premissas por trás dessas métricas. Já à esquerda, temos um sistema agêntico, que adiciona uma nova complexidade. O sistema de implantação tem muitas entradas possíveis, respostas de ferramentas e sequências de ações, ou trajetórias, ou execuções, como você preferir chamar. Então, testamos cenários selecionados. Às vezes, outro

13:08 agent de IA ou juiz de IA gera esses testes ou avalia o resultado. Mas esse juiz pode cometer erros, e o teste pode deixar passar falhas importantes. É aí que precisamos verificar se o avaliador é confiável, o que as evidências abrangem e se elas se aplicam ao sistema que estamos realmente implantando. É por isso que o avaliador é a parte do sistema que governamos. Agora vou

13:38 passar a palavra a Vishal para explicar como podemos verificar se uma avaliação é confiável e o que fazer quando não é. >> Obrigado, Tanmay. Vimos a avaliação em nível de sistema, tanto do avaliador quanto, como vocês sabem, de todo o sistema de IA. A questão é: como devemos realmente… E, quando eu estava analisando algumas pesquisas anteriores, particularmente na área da neurociência cognitiva, o que

14:09 descobri foi que o cientista Peter Wason cunhou o termo viés de confirmação. E, essencialmente, ele fez vários experimentos. Neste caso, a sequência que vocês veem é 2, 4, 6, certo? Ele pedia às pessoas que previssem o próximo número e, na maioria das vezes, elas respondiam 8, 10, ou seja, números pares. Mas essas respostas estavam incorretas, porque o número correto podia ser qualquer número crescente.

14:41 Isso provava que todos os seres humanos — ou, pelo menos, a maioria — podem ter algum tipo de viés de confirmação. Neste caso, 79% das pessoas testadas erraram. E os sistemas de IA, como sabemos, são treinados com dados gerados por humanos. Então, o que ele propôs foi que qualquer avaliação precisa refutar, não confirmar. E essa é a maneira de proceder. E nós

15:12 pegamos essa lição da pesquisa dele e propomos que o sistema de evals seja orientado a falhas. Então, o que significaria um sistema de evals orientado a falhas? Significaria começar examinando a afirmação sobre o sistema, testá-la e tentar refutá-la; depois, identificar onde as afirmações sobre o sistema falham, certo? E o que fazer para corrigir isso? Ou você impede que o sistema de IA opere

15:42 na área em que há falhas, ou cria sistemas de apoio nos quais confia. E continua fazendo isso de forma iterativa até chegar ao nível de confiança desejado. Essa é, essencialmente, a abordagem baseada em primeiros princípios que propomos para qualquer sistema de avaliação. Então, você pega seus sistemas de IA, executa esse ciclo de construir, quebrar e corrigir e entende em quais situações os sistemas de IA

16:14 podem ser considerados confiáveis em relação aos resultados finais. Você também mapeia a região de incerteza e a região de alto risco, onde não é possível ter muita certeza sobre o desempenho do sistema. Mapeia toda a região de falhas e a classifica com base na confiabilidade e na materialidade. Isso significa que, principalmente se você estiver usando IA em qualquer sistema classificado como de alto risco, precisa garantir que sua IA só seja

16:45 usada na região em que você confia. Com isso, vou passar a palavra a Tanmay, que aplicará essa abordagem a um caso real de falha de IA. >> Certo. Então, vamos concretizar essa estrutura e ver como uma avaliação limitada pode deixar passar falhas que importam no mundo real. Vou contar rapidamente a história por trás do caso. Um

17:16 cliente precisava viajar após uma morte na família. Ele perguntou a um chatbot de uma companhia aérea sobre uma tarifa com desconto. O chatbot disse que ele poderia comprar uma passagem normal e solicitar o desconto depois, dentro de 90 dias. Então, ele confiou nessa orientação, mas, mais tarde, a companhia aérea recusou o pedido porque sua política não permitia isso. Por fim, o tribunal responsabilizou a companhia aérea. Com esse exemplo, vemos a cadeia de falhas. Está muito claro: uma orientação incorreta

17:48 chega ao cliente, o cliente age com base nela e a organização enfrenta as consequências. Então, se aplicássemos nossa abordagem de construir, quebrar, corrigir e testar novamente, poderíamos ter identificado a falha muito antes da implantação. Idealmente, começaríamos com um requisito claro, como: a orientação deve corresponder à política aprovada. Em seguida, desafiaríamos o chatbot com perguntas sobre reembolsos após a viagem. Se esses testes revelassem uma orientação incorreta, poderíamos adicionar uma

18:20 verificação da política ou um encaminhamento para atendimento humano. Depois, testaríamos novamente para ver se esses controles detectaram os erros antes que chegassem ao cliente. Essa é a nossa estrutura em prática. Precisamos definir a afirmação, desafiá-la ativamente e usar as evidências para orientar mudanças e tomar uma decisão de implantação. Por fim, vou passar a palavra a Vishal para reunir as partes e concluir. >> Esta é nossa última apresentação. Então,

18:51 essencialmente, o que estamos dizendo é que seus evals devem se basear em riscos, não em frequência. Você deve analisar todo o sistema e dividi-lo em componentes essenciais, como falhas técnicas, controles de implantação e contexto de negócios. Depois, avalie a materialidade dos seus casos de uso de IA usando alguma escala — que pode ser específica da sua empresa — e considere que o risco pode mudar. E, depois de fazer isso,

19:23 aplique testes de estresse em nível de sistema ao caso de uso de IA. Só tome a decisão de implantação quando tiver confiança na região. Caso contrário, pode sair caro demais. Nossa mensagem final é: avalie todo o sistema de IA com base no risco, não apenas um componente. Muito obrigado pelo seu tempo e atenção. Fiquem à vontade para entrar em contato conosco depois. Teremos prazer em responder a quaisquer perguntas mais tarde.

19:55 >> [aplausos]

Transcrição original

[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]