O que um erro bancário de US$ 900 milhões nos ensina sobre agentes de IA — John Feminella, Two Sigma

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: What a $900M Bank Error Teaches Us About AI Agents - John Feminella, Two Sigma · Canal: AI Engineer · 18:35 · Assistir no YouTube

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

Resumo

John Feminella usa o erro de processamento da Citibank em 2020, que enviou cerca de US$ 900 milhões a credores da Revlon por engano, para discutir segurança em agentes de IA. Ele argumenta que controles eficazes devem permitir autonomia com limites e visibilidade, em vez de bloquear tudo ou depender apenas de instruções em documentos. Apresenta cinco controles: registro de agentes, revisão proporcional ao risco, acesso a ferramentas conforme a finalidade, evals compartilhados e decisões de runtime com classificadores e revisão humana seletiva. A ideia central é que controles bem projetados tornam possível operar com mais autonomia e velocidade, sem abrir mão da segurança.

Pontos-chave

Em agosto de 2020, um erro no Flexcube fez a Citibank enviar cerca de US$ 900 milhões em principal a mais de 300 credores da Revlon, em vez de apenas cerca de US$ 8 milhões em juros.
A autonomia de agentes traz riscos, mas humanos também cometem erros; a resposta não precisa ser bloquear todas as ações.
Segurança e inovação podem coexistir quando há limites claros, visibilidade e controles adequados.
Um agent registry torna os agentes visíveis e registra informações como responsáveis, ferramentas e endpoints acessados.
A revisão deve ser proporcional ao risco e à finalidade do agente, evitando que experimentos simples enfrentem o mesmo processo de sistemas de produção.
Os agentes devem declarar sua finalidade e as ferramentas necessárias, para que o acesso possa ser concedido de forma específica e aplicada no runtime.
Evals compartilhados ajudam equipes a avaliar mudanças nos modelos e na qualidade das respostas sem impor uma revisão centralizada a cada alteração.
A aprovação humana de cada ação pode causar fadiga; classificadores podem tratar decisões rotineiras e encaminhar casos ambíguos ou importantes às pessoas.
Os cinco controles apresentados são registro, avaliação de risco, guardrails de acesso, evals e governança do runtime.

Capítulos

Início	Capítulo	Resumo
00:01	O erro bancário de 2020	John Feminella apresenta o caso em que um erro no processamento do empréstimo da Revlon levou a Citibank a enviar cerca de US$ 900 milhões aos credores.
05:10	Autonomia com controles	A palestra relaciona o erro bancário aos riscos de agentes autônomos e defende combinar limites, visibilidade e liberdade para trabalhar.
07:14	Tornar os agentes visíveis	O primeiro controle é um agent registry que registra agentes e permite descobrir seus responsáveis, ferramentas e acessos.
09:48	Revisão proporcional ao risco e acesso específico	Feminella defende diferenciar agentes por finalidade e risco e permitir que declarem as ferramentas necessárias, com políticas aplicadas nos ambientes gerenciados.
15:01	Evals compartilhados	Evals comuns à empresa ajudam as equipes a avaliar mudanças sem obrigar cada ajuste a passar por um processo centralizado demorado.
16:33	Reduzir a fadiga de aprovação	O palestrante explica por que pedir aprovação humana para cada ação falha em escala e propõe usar classificadores para decisões rotineiras.
18:04	Cinco controles e a analogia dos freios	A conclusão reúne os cinco controles e compara os freios dos carros às salvaguardas que permitem aos agentes operar com segurança.

Citações

Damos limites, visibilidade e sistemas e controles que permitem que façam seu trabalho com eficácia. — 05:40

Não é possível governar aquilo que não se consegue enxergar. — 08:47

Um navio no porto está seguro, mas não é para isso que os navios servem. — 12:55

Os carros não têm freios apenas para parar; eles têm freios para poder ir rápido e parar com segurança. — 18:35

Conceitos e entidades

John Feminella (pessoa): Palestrante que trabalha com arquitetura e engenharia de IA na Two Sigma.
Two Sigma (empresa): Empresa de investimentos sediada em Nova York onde John Feminella trabalha com arquitetura e engenharia de IA.
Citibank (empresa): Banco que atuou como agente administrativo no empréstimo da Revlon e, em 2020, enviou pagamentos por engano.
Revlon (empresa): Empresa de cosméticos cujo empréstimo esteve no centro do erro de pagamento discutido na palestra.
Flexcube (ferramenta): Software interno de processamento usado na transação que resultou no envio indevido do principal do empréstimo.
Agent registry (conceito): Registro que torna os agentes identificáveis e permite consultar seus responsáveis, ferramentas, endpoints e produtos associados.
evals (conceito): Avaliações usadas para verificar o comportamento e a qualidade dos resultados de agentes, inclusive quando os modelos mudam.
classifiers (conceito): Classificadores independentes que podem decidir sobre ações rotineiras e encaminhar casos ambíguos ou relevantes para revisão humana.
Claude Code (ferramenta): Exemplo de agente de programação de propósito aberto citado para contrastar com agentes empresariais de finalidade específica.
Pi (ferramenta): Exemplo de agente de programação de propósito aberto mencionado na comparação com agentes empresariais especializados.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é John Feminella. Trabalho com arquitetura e engenharia de IA na Two Sigma, que é um fundo de hedge aqui em Nova York. Antes de avançar muito, tenho um slide de aviso legal que preciso mostrar a vocês. Ele diz duas coisas. Primeiro, prometo não vender, comercializar nem oferecer a vocês quaisquer valores mobiliários em nenhum momento desta palestra. E, segundo, tudo o que está aqui é minha

00:33 opinião pessoal, e não a opinião da Two Sigma. Certo, obrigado por me acompanharem nessa. Se eu não disser essas palavras mágicas, os microchips 5G implantados em mim vão explodir. Então, esse slide é um bom exemplo, na verdade, de como nosso setor é regulamentado. E, como uma empresa regulamentada, com muitos controles, acho que uma coisa sempre interessante é explorar o que acontece quando os controles falham, porque isso dá uma boa ideia do motivo pelo qual eles existiam em primeiro lugar. Então, gostaria de contar uma história sobre isso mostrando a vocês outro slide legal

01:03 Depois de agosto de 2020, uma cláusula contratual muito interessante começou de repente a aparecer em vários contratos de empréstimo comercial. E essa cláusula tenta essencialmente impedir que certo cenário aconteça. É complicado, mas vou explicar assim. Digamos que você tenha um negócio de barraca de limonada e pegue dinheiro emprestado de um credor para financiar sua barraca. E o banco que supervisiona essa transação, que fica no meio entre o tomador e o credor, envia ao credor todo o dinheiro que

01:35 você deve, por engano catastrófico. Você provavelmente ficaria furioso e iria querer o dinheiro de volta, mas o credor também poderia dizer: “Não, obrigado. Você nos pagou e está tudo certo, então preferimos ficar com o dinheiro.” Algo assim aconteceu em agosto de 2020. A Revlon, a empresa de cosméticos, havia tomado dinheiro emprestado por meio de um grande empréstimo a prazo de 2016. E esse empréstimo foi dividido em várias partes entre mais de 300 credores: fundos de hedge, fundos de crédito, CLOs e outros bancos. E, no meio, estava o Citibank, o agente administrativo. Ser o

02:05 agent nesse tipo de transação significa cuidar da infraestrutura que conecta os tomadores aos credores e gerenciar o ciclo de vida do empréstimo. Então, nessa transação, a Revlon paga ao Citi, e depois o Citi paga aos credores. E o Citi não está emprestando o próprio dinheiro; está apenas no meio, movimentando o dinheiro de outras pessoas. Então, este era o plano para 11 de agosto de 2020. A Revlon pagaria cerca de 8 milhões de dólares de juros acumulados aos dois grupos, e o principal dos credores seria transferido para essa nova linha de crédito. Isso é uma troca de papéis, não de dinheiro. Então, o

02:35 principal dos credores restantes permaneceria onde estava. A ideia era que apenas os juros fossem pagos; o principal não deveria se movimentar. E o banco tinha um software interno de processamento chamado Flexcube. Não é um nome divertido para um software empresarial? Então, no Flexcube, a maneira mais fácil de fazer esse tipo de transação é registrá-la como se a Revlon estivesse quitando o empréstimo inteiro. Isso aciona os cálculos corretos de pagamento de juros para todos. Provavelmente dá para adivinhar o que está prestes a acontecer. Então, você deveria enviar

03:07 a parte do principal para uma conta de passagem interna que pertence ao banco, para que ela seja contabilizada e registrada corretamente, mas nunca saia dos limites do banco. Então, prestem atenção nessa conta de passagem. O que deveria acontecer era que as caixas rotuladas como “front and fund” e “principal” incluíssem o número da conta de passagem e tivessem todas as caixas de seleção ao lado marcadas. Infelizmente, descobriu-se que era isso que precisava acontecer, mas, por vários motivos obscuros, as caixas não foram marcadas. E, embora o Flexcube

03:38 exiba um aviso dizendo: “Ops, o dinheiro está prestes a sair do banco. Tem certeza de que quer fazer isso?”, o aviso estava correto. O dinheiro deveria sair do banco, porque eles estavam fazendo os pagamentos de juros. Então, os três aprovadores que deveriam aprovar a operação olharam e disseram: “Sim, é isso mesmo que deveria acontecer.” E, embora o aviso tenha aparecido, os operadores humanos que estavam realizando a transação o ignoraram. Lembrem-se: a Revlon estava fazendo aquele pagamento de juros. Então, o principal não foi para a conta de passagem e, em vez disso, o Flexcube enviou todo o principal ainda pendente do empréstimo

04:09 a todos os 300 credores: cerca de 900 milhões de dólares, em vez de 8 milhões. Então, cada credor recebeu o valor que teria recebido se a Revlon tivesse quitado o empréstimo por completo, mas a Revlon não queria quitá-lo. Queria ficar com o dinheiro. Foi um ótimo negócio para os credores, porque, lembrem-se, a Revlon estava passando por dificuldades na época, então os empréstimos dela não estavam sendo negociados pelo valor de face. Receber todo o seu dinheiro de volta em um negócio que você achava que valia apenas 60 centavos por dólar é um ótimo negócio para você. Então, eles não quiseram devolver o dinheiro, mesmo depois que o Citi ligou e disse: “Por favor, isso foi um erro. Devolvam

04:39 o dinheiro.” E o argumento deles foi: “Não deveríamos ter que devolver o dinheiro porque vocês nos pagaram integralmente, e é assim que os empréstimos funcionam. Em algum momento, vocês os pagam de volta, e o fato de terem pago em um momento diferente do previsto não significa que deveríamos ter que devolver o dinheiro agora.” Então, para impedir que isso acontecesse, contratos de empréstimo comercial por toda parte começaram a incluir uma cláusula como aquela. Então, o que um erro de pagamento em um banco tem a ver com agentes de IA? Bem, o banco tinha esse procedimento, tinha esses controles, e todo mundo fez o que achava que era certo. Esse é o problema sobre o qual quero falar no resto desta palestra. Todos os dias,

05:10 damos autonomia real a agents reais sobre sistemas como o Flexcube. E como podemos evitar acidentes como aquele sem bloquear tudo ou simplesmente torcer para ter sorte e que eles não aconteçam? Então, aqui está o cerne da questão. Não dá para saber de antemão o que um agent vai fazer, certo? São sistemas não determinísticos. E isso parece assustador até você se lembrar de que os humanos também são sistemas não determinísticos e que também vão cometer erros. E, por isso, a maioria das empresas não escolhe dizer: “Bem, para reduzir o risco de os humanos cometerem erros, vamos

05:40 trancá-los em salas e impedir que conversem entre si, e todos vão conferir o trabalho uns dos outros, certo?” Nós lhes damos certa autonomia e também uma quantidade adequada de controles. Estabelecemos limites, damos visibilidade e os equipamos com sistemas e controles que lhes permitem fazer seu trabalho com eficácia. Então, nesse tipo de modelo, segurança e inovação não são extremos opostos de um espectro entre os quais você precisa escolher. Há coisas que você pode fazer ao mesmo tempo. Então, acho que dá para ficar com o bolo e também comê-lo. E, quando pensamos nos controles que queríamos aplicar aos agents, também analisamos algumas abordagens que não

06:11 funcionaram para nós. Não queremos colocar tudo em um sandbox nem bloquear tudo, porque um sandbox sem acesso real aos sistemas é seguro, mas não é muito interessante nem útil. Se você deixar os agents à solta, fazendo o que quiserem, isso talvez seja poderoso e libertador do ponto de vista cognitivo, mas o isolamento é muito fraco, e essa abordagem geralmente não é adequada para empresas altamente regulamentadas. E, se você tiver apenas documentos de políticas que os agents consultam ou que fazem parte da especificação dos prompts, isso também não é muito

06:42 possível de aplicar em tempo de execução. Você não pode garantir que isso fará parte dos controles de aplicação. Então, o que funcionou para nós foi pensar em que combinação de controles nos daria segurança e inovação ao mesmo tempo. Como podemos estabelecer limites e impedir problemas, sem atrapalhar as pessoas para que operem corretamente? Temos vários desses controles, mas hoje vou falar sobre cinco deles. E, quando digo controles aqui, quero dizer as proteções e capacidades compartilhadas que permitem às equipes avançar sem atrapalhar o que estão tentando fazer. E queremos… Não queremos

07:14 queremos chegar a algum abismo que precisamos atravessar para permitir que as pessoas façam seu trabalho antes disso e, então, fazer todo mundo esperar enquanto construímos uma ponte para chegar lá. Então, esses controles são combináveis. Cada um faz uma coisa, e, juntos, permitem que executemos agentes com autonomia real e um nível adequado de segurança. Então, o primeiro problema é que os agentes estavam surgindo por toda parte. Temos equipes grandes com muitos agentes em execução. Temos equipes pequenas com alguns. Temos pessoas trabalhando individualmente, executando coisas de maneira

07:44 descontrolada. E eles aparecem em todos os formatos. Podem ser chatbots aleatórios. Podem ser servidores MCP colados uns aos outros nessa mistura toda, uma espécie de Frankenstein. Podem ser experimentos interessantes em notebooks. Podem ser ferramentas web realmente úteis para as pessoas. Mas é difícil responder a algumas perguntas simples quando olhamos para isso, como: quem é responsável por isso? A quais ferramentas isso tem acesso? O que deveria estar fazendo? O que deveria estar fazendo? Se não conseguirmos responder a esse tipo de pergunta, se não pudermos governá-los, também não conseguiremos reutilizá-los de verdade. Então, ficamos tentados a criar várias

08:15 soluções para o mesmo problema se não soubermos o que já existe, e a empresa também não consegue governá-las de nenhuma maneira clara. Então, uma coisa que as empresas às vezes fazem nesse caso é criar algum tipo de barreira, como não deixar nada ser executado até que tudo esteja registrado e aprovado e tenha passado por um processo muito oneroso. Isso parece seguro, mas, se observarmos o que acontece, todo o trabalho, toda ideia, até mesmo um simples experimento em notebook, vai esperar na fila atrás de algo realmente arriscado. E não queremos, sabe, submeter todas as pessoas, dada a diversidade de

08:47 agentes, exatamente ao mesmo processo. Então, a maioria das pessoas vai desistir, ou será empurrada para algum caminho de TI paralela, menos governado e menos visível; aí não conseguiremos ver nada. Foi isso que motivou o primeiro controle: um registro de agentes. Não é possível governar aquilo que não se consegue ver. Então, o registro de agentes torna os agentes compreensíveis e registra, recupera e identifica os principais fatos sobre os agentes que queremos conhecer. Isso inclui coisas como quais ferramentas ele implanta, com quais endpoints vai se comunicar, a qual produto pertence

09:17 e quem é responsável por ele. Então, as pessoas, outros programas e outros agentes podem usar o registro de agentes para decidir o que está disponível na empresa, se isso é útil para eles e para consultar essa fonte de verdade quando tiverem outras dúvidas. Isso não exige nenhum esforço extra da sua parte. Simplesmente acontece quando você usa uma das estruturas aprovadas pela empresa para criar agentes; o agente é registrado automaticamente e todas essas informações são armazenadas para você. E, se quiser fazer um registro manual, certamente pode. Então, o segundo problema é que agora

09:48 que temos todos esses agentes fazendo todas essas coisas, logo percebemos que o que eles fazem é muito diferente. E isso significa que nossos agentes envolvem riscos muito diferentes, certo? Uma coisa que resume tickets do Jira ou do Linear é muito diferente de um agente de deploy em produção que pode afetar um sistema em execução. E, se usarmos o mesmo processo de revisão para cobrir todos esses agentes, todos ficarão na mesma fila por semanas, esperando pela revisão humana. Se as pessoas contornarem processos lentos, acabaremos na mesma situação em que

10:20 estávamos antes. Então, de novo, você pode se sentir tentado a dizer que a resposta é algo como uma revisão manual, detalhada e rigorosa por todos esses diferentes grupos envolvidos. Mais uma vez, isso parece seguro, mas agora temos um resumidor trivial esperando dois meses pelas mesmas aprovações que um agente que afeta sistemas de produção. E a maioria das boas ideias para agentes, a maioria das que geram valor imediatamente, começa como pequenos experimentos. Você não quer que essas pessoas esperem na mesma fila que as coisas que afetam a produção desde o início. Então, os revisores ficam afogados em solicitações de baixo risco, e as de alto risco precisam dividir com elas a mesma atenção.

10:51 Então, se pudermos evitar, não queremos abrir mão dessa velocidade. Mais uma vez, como nem todo agente precisa da mesma revisão e a maioria dos agentes é criada para uma finalidade específica, em vez de ser aberta. Quando digo aberta, você pode imaginar agentes de programação como Pi ou Claude Code. Quando você os abre e começa a digitar, Claude Code ou Pi não sabe o que você está prestes a pedir. Eles não delimitam sua finalidade de nenhuma maneira específica, mas a maioria dos agentes implantados em empresas tem finalidades muito específicas. Quando você

11:22 interage com esse agente, é para fazer algo específico, bem conhecido e bem compreendido. Então, eles têm uma razão muito específica para existir e uma finalidade muito bem delimitada. E é possível diferenciá-los observando o que declaram de antemão: suas ferramentas, os endpoints que acessam, os controles aplicados a eles e assim por diante. Então, o terceiro problema é que, quando você conhece seus agentes e o que estão fazendo, logo percebe que muitos agentes não se comunicam entre si — ou, melhor, não se comunicam com apenas uma coisa

11:53 nem atuam em apenas uma capacidade. Quanto mais aberto é o agente, quanto mais ele se parece com Claude Code ou Pi, mais variedade e diversidade de coisas ele pode fazer: chamar uma API interna, executar uma ferramenta como uma busca na web e coisas desse tipo. E cada uma dessas ações abre uma porta diferente para um tipo diferente de risco. Se você der a um agente uma permissão para uma conta de função, ele pode causar muito mais dano do que algo que só vai ler uma página pública na web, por exemplo. Então, a pergunta não é se esse agente pode fazer X, mas qual é a

12:24 granularidade que precisamos definir para que o agente consiga agir com sucesso? Mais uma vez, uma resposta tentadora é adotar uma abordagem rígida ou dar a todos os agentes a mesma lista curta de permissões para coisas seguras e bloquear todo o resto. Isso é seguro, mas também é inútil. Um agente que não consegue pesquisar, chamar uma API ou fazer qualquer uma dessas coisas sem antes pedir a alguém não consegue realizar o trabalho para o qual foi criado. Então, as equipes desistem desses agentes ou encontram uma maneira de contornar a barreira, e os dois resultados

12:55 são custosos. Então, um bloqueio amplo e generalizado de tudo sacrifica a inovação que queremos preservar e evita que tomemos uma decisão real sobre o risco. E, como escreveu o autor John Shedd: “Um navio no porto está seguro, mas não é para isso que os navios servem.” Então, a solução aqui é permitir que os agentes declarem sua finalidade de antemão e digam quais ferramentas vão usar ou às quais precisam ter acesso. Na segunda coluna, por exemplo, podemos dizer que um resumidor de pesquisas terá permissão para usar uma ferramenta web para acessar pesquisas, mas não vamos permitir que um agente de

13:27 deploy de lançamentos faça isso, porque ele não tem motivo para usar essa ferramenta. Então, se tentar solicitá-la, não terá acesso por padrão. Não precisamos tomar esse tipo de decisão para cada ferramenta. Os agentes só precisam dizer quais ferramentas querem. Certo? E você, como autor do agente, está na melhor posição para dizer: “Preciso destas quatro coisas entre as 500 disponíveis.” Então, para aplicar isso, quando os agentes são executados em nossos ambientes gerenciados,

13:59 eles consultam o registro de que falamos antes para verificar quais políticas se aplicam a eles no momento da inicialização. Essa política é então traduzida em instruções aplicáveis, como quais endpoints você tem permissão para acessar, quais hosts pode acessar e que outros tipos de recursos estão ou não disponíveis para você. Assim, ninguém precisa abrir um ticket toda vez que precisa alterar o acesso, e ninguém precisa falar com a equipe de TI ou com algum outro grupo fora da sua equipe. Desde que você se enquadre na pontuação de risco

14:31 de que falamos antes, e você está no registro de agents, é governado, está aprovado. Então, é assim que mantemos muito baixo o custo para as equipes implantarem, criarem e executarem agents. E a mesma arquitetura de controle funciona em vários contextos. A próxima coisa que percebemos foi que as equipes estavam criando um monte de maneiras diferentes de avaliar agents, e cada stack é diferente, e algumas equipes não criam nada. Às vezes, você monta uma stack realmente detalhada para o funcionamento dos seus modelos; às vezes, não há nada, e eu

15:01 acho que, em geral, ficaríamos incomodados se as equipes não escrevessem testes unitários, certo? E consideramos que evals são mais ou menos a mesma coisa. Se os modelos estão mudando, isso é como uma dependência em tempo de execução que a sua aplicação tem; e, se o seu agent vai mudar de modelo, ele não sabe, sem evals, o que vai acontecer com as saídas dele e com a qualidade dessas saídas. Então, de novo, uma resposta tentadora aqui é criar algum tipo de metodologia central de avaliação que aguarde uma suite completa de evals e a aprovação de um

15:31 comitê, mas aí cada ajuste de prompt, cada mudança de uma linha vai ficar na mesma fila. Então, não queremos colocar mais decisões nas mãos de mais revisores para coisas assim. Não queremos abrir mão dessa iteração. Então, de novo, você não lançaria software sem testes unitários; agents precisam de avaliações pelo mesmo motivo, e queremos fornecer esses recursos no nível da empresa, de modo que sejam iguais para todos. Então, a equipe A escreve evals, a equipe B escreve evals, e as duas vão ter muitos recursos em comum. Então,

16:01 queremos ter uma abordagem compartilhada para fazer evals e fazer com que essa abordagem seja executada pela empresa e esteja disponível para todos realizarem suas evals. Assim, ela cobre todas as partes comuns das evals, e tudo o que você precisa fazer é escrever o que é verdadeiro sobre o seu agent. E, por fim, talvez você já tenha passado pela experiência de ter que aprovar um grande número de ações individuais de agents quando há uma pessoa no loop. Tudo bem em pequena escala, mas, quando você opera agents em paralelo ou em produção, isso se torna totalmente impraticável, e as solicitações de revisão

16:33 chegam mais rápido do que se pode esperar que alguém as aprove. Quer dizer, depois das primeiras vezes que isso acontece, você sucumbe à fadiga de revisão: só vê “sim, sim, sim, sim, sim” e, por fim, clica em “sim” para algo que, sabe, está ativando uma nova bomba nuclear, certo? Então, você não quer clicar em “sim” por reflexo, mas isso vai acontecer inevitavelmente. E um exemplo recente disso aconteceu no início deste ano: uma diretora de um laboratório de pesquisa em IA pediu ao agent OpenClaw que sugerisse emails para apagar da caixa de entrada e depois esperasse a aprovação dela, mas a caixa de entrada era tão grande que, em algum momento,

17:03 o agent compactou o contexto e perdeu a parte que dizia: “Espere pela minha aprovação”. Então, apagou centenas de emails e não parou quando ela mandou parar pelo celular. De novo, você pode ficar tentado a exigir que uma pessoa aprove cada ação, mas essa não é a maneira certa de fazer isso. Uma abordagem melhor é deixar que esses classificadores independentes e conservadores tomem decisões sobre chamadas rotineiras e, então, enviar a uma pessoa apenas as solicitações mais importantes, aquelas com maior probabilidade de fazer diferença. Se você diz “sim” 99,99999%

17:33 das vezes, então provavelmente isso é apenas uma regra que o agent deveria seguir, e não uma solicitação para a qual você precisa pedir permissão a uma pessoa. E o que for incerto, ambíguo ou potencialmente perigoso, sim, encaminhe a uma pessoa; ou, se for claramente perigoso, negue diretamente. Assim, não é preciso fazer todo o trabalho de revisão o tempo todo. Então, não queremos adotar a mesma abordagem para os dois casos: quando uma regra explícita se aplica, queremos caminhos rápidos determinísticos. Quando as regras explícitas não se aplicam e há alguma ambiguidade, queremos que um classificador

18:04 faça esse trabalho. Então, reunindo essas cinco partes, você cria um registro para que cada agent fique visível desde o dia em que é criado. Você avalia cada agent para que a revisão humana aconteça no lugar certo. Você opera com guardrails para que eles só acessem o que precisam. Você compartilha evals e métricas para que todos alcancem o mesmo patamar sem precisar reinventar a roda. E, por fim, você governa o ambiente de execução para garantir que a classificação aconteça ali, e não em outro lugar. Então, cada um desses controles funciona em conjunto. Vou deixar vocês com uma pergunta. Por que

18:35 os carros têm freios? Não é só para que você possa parar; é para que possa ir rápido e parar com segurança. Os controles para os nossos agents funcionam da mesma maneira. Muito obrigado. Sou John Feminella, e espero que tenham se divertido. >> [aplausos] [música]

Transcrição original

[00:01] [music] >> Uh my name’s John Feminella. I work on AI architecture and engineering at Two Sigma, which is a hedge fund here in New York. Before I get too far into things, I have a legal disclaimer slide that I have to show you. It says two things. One, I promise not to sell or market or offer you any securities at any point in this talk. And two, everything in this is my

[00:33] own opinion and not the opinion of Two Sigma. All right, thanks for indulging me. If I don’t say those magic words, the 5G microchips implanted in me will explode. So, that slide is a good example, actually, of how our industry is regulated. And as a regulated company with lots of controls, I think one thing that’s always interesting is to explore what happens when controls fail, because that gives you a good idea about why the controls were there in the first place. And so, I’d like to tell you a story about that by showing you another legal

[01:03] slide. After August 2020, a very interesting contract clause suddenly started showing up in a bunch of commercial loan agreements. And this clause essentially tries to prevent a certain scenario from happening. And it’s complicated, but I’ll explain it like this. Let’s say that you’re a lemonade stand business, and you borrow money from a lender to capitalize your lemonade stand. And the bank that’s overseeing that transaction, that’s in the middle between the borrower and the lender, sends the lender all of the money that

[01:35] you owe in a catastrophic mistake. You’d probably be mad and want the money back, but the lender might also say, “No, thanks. You paid us back and we’re all good, so we’d rather keep the money.” Something like this happened in August 2020. Revlon, the cosmetics company, had borrowed money under a big 2016 term loan. And that loan was split up into a bunch of pieces across 300-plus lenders, hedge funds, credit funds, CLOs, other banks. And in the middle is Citibank, the administrative agent. Being the

[02:05] agent in this kind of transaction means that you’re performing the plumbing that connects the borrowers with the lenders and managing the life cycle of the loan. So, in this transaction, Revlon pays City and then City pays the lenders. And City’s not lending its own money, it’s just in the middle moving people’s money around. So, here’s the plan for August 11th, 2020. Revlon would pay about 8 million bucks of accrued interest to both groups and the lenders’ principal would roll into this new facility. That’s an exchange of paper, not cash. So, the

[02:35] remaining lenders’ principal would stay put. And the idea here is that only interest should be going out, principal should not be moving at all. And the bank had a piece of internal processing software called Flexcube. Isn’t that a fun enterprise software name? So, in Flexcube, the easiest way to do this kind of transaction is to pretend to record it like Revlon were paying off the entire loan. And that triggers the correct interest payment calculations to everyone. You can probably guess what’s about to happen next. So, you’re supposed to send

[03:07] the principal portion to an internal wash account that you own as the bank, so that it’s booked and recorded correctly, but it never leaves the bank’s perimeter. So, keep your eye on that wash account. What was supposed to happen is that the boxes labeled uh front and fund and principal should all include the wash account number and should all have a check box checked next to them. So, unfortunately, it turned out that was what needed to happen, but for various arcane reasons, uh the boxes were not checked. And although Flexcube

[03:38] pops up a warning notification that says, “Uh-oh, money’s about to leave the bank. Are you sure you want to do this?” That was correct. Money was supposed to leave the bank because they were making the interest payments. So, the three approvers who were supposed to approve that looked at it and said, “Yep, that’s the right thing that’s supposed to happen.” And although that warning notification popped up, the human operators carrying out the transaction overrode that. Remember, Revlon was making that interest payment. So, the principal never went to the wash account, and instead Flexcube sent the entire outstanding principal of the loan

[04:09] to all of the 300 lenders, about $900 million instead of $8 million. So, every [snorts] lender got the amount that they would have been owed if Revlon had paid the loan in full, but Revlon didn’t want to pay off the loan. It wanted to hold onto its money. That was a great deal for the lenders because remember, Revlon was in trouble at the time, so its loans weren’t trading at face value, and getting all your money back on a deal that you thought was only worth 60 cents on the dollar is a great deal for you. So, they didn’t want to give the money back even after Citi called them and said, “Please, that was a mistake. Give

[04:39] us the money back.” And their argument was, “We shouldn’t have to give the money back because you paid us in full, and that’s how loans work. You eventually pay them back, and just because you paid it back at a different time than you were supposed to doesn’t mean that we should have to give it back now.” And so, to prevent that from happening, uh commercial loan agreements everywhere started including including a clause like that one. So, what does a payment error at a bank have to do with AI agents? Well, the bank had this procedure, it had these controls, and everybody did what they thought the right thing to do was. That’s the problem I want to talk about for the rest of this talk. Every day, we’re

[05:10] giving real agents real autonomy over systems like Flexcube. And how do we prevent accidents like that one from either from happening without locking everything down or just hoping we’ll get lucky that they won’t happen. So, here’s the crux of the issue. You can’t really know in advance what an agent will do, right? They’re these non-deterministic systems. Uh and that sounds scary until you remember that humans are also non-deterministic systems, and they’re going to make mistakes, too. And so, most firms don’t choose to say, “Well, in order to reduce the risk of humans making a mistake, we’re going to

[05:40] like lock them in rooms and prevent them from talking to each other, and they’re all going to double-check everybody else’s work, right?” We allow them a certain amount of autonomy along with a certain amount of controls. So, we give them boundaries, visibility, and we equip them with systems and controls that let them do their jobs effectively. So, in this sort of model, safety and innovation are not opposite ends of a spectrum that you must trade off on. There are things that you you at the same time. So, I think you can have your cake and eat it, too. And when we were thinking about what controls we wanted to apply to agents, we also looked at some approaches that didn’t

[06:11] work for us. We don’t want to sandbox or lock down everything, cuz a sandbox with no real access to systems is not is safe, but it’s not very interesting or useful. If you let agents go wild and do whatever they want, that’s uh, you know, maybe powerful and freeing from a cognitive perspective, but the isolation is very weak there, and that that approach is generally not suitable for highly regulated enterprises. And then, if you just have policy documents that agents look at or that are part of your uh, specification for the prompts, that’s also not very

[06:42] enforceable at runtime. You can’t guarantee that that will be part of the enforcement controls. So, what did work for us was thinking about what mix of controls would get us both safety and innovation at the same time. So, how do we provide boundaries and stop problems, but don’t hinder folks from operating correctly? So, we have a number of these controls, but today I’ll talk about five of them. And when I say controls here, what I mean are the guardrails and shared capabilities that let teams move in ways that don’t hinder what they’re trying to do. And we want to We don’t

[07:14] want to reach some chasm that we need to cross to to let people get their work done before uh, and then make everyone wait while we build a bridge to get there. So, these controls are composable. Each one does one job, and then together, they let us run agents with real autonomy at an appropriate level of safety. So, the first problem is that agents were showing up everywhere. We have big teams with lots of agents running. We have small teams with a few. We have individual people running stuff in a

[07:44] uncontrolled way. And these come in every shape. Could be random chatbots. It could be MPC servers glued together in this Frankenstein hotchpotch. It could be cool notebook experiments. Could be really useful web tools for folks. But, it’s hard to answer when you look at that a few simple questions, like who owns this? What tools does it have access to? What should it be doing? What should it is be doing? If if answer those kinds of questions, if you can’t govern them, then you can’t really also reuse that. So, you’re tempted to build multiple

[08:15] solutions to the same problem if you don’t know about what exists already, and then the firm can’t also govern those in any kind of legible way. So, one thing that firms sometimes do here is add some kind of gate, like don’t let anything run until everything is registered and approved and it’s gone through this very onerous process. And that sounds safe, but if you look at what it does, the work, every idea, even some simple notebook experiment, is going to wait in line behind something that’s really risky. And we don’t um you know, we we don’t want to subject everybody who’s given the diversity of

[08:47] agents to exactly the same process. So, most people are going to give up, or they’ll just get pushed to some shadow IT, less governed path that is um less visible, and then we don’t get to see anything at all. So, that’s what motivated the first control is an agent registry. You can’t govern what you can’t see. So, the agent registry makes agents legible, and it registers, [snorts] retrieves, and discovers the key facts about agents that we want to know for any agent. Um so, those are things like which tools it deploys, what endpoints it’s going to talk to, which product does it belong

[09:17] to, who owns it. And humans, other programs, other agents can then use the agent registry to decide what’s available at the firm, whether that’s useful for them, and to go use that as the source of truth for other questions. So, this doesn’t require extra effort on your part. It just happens when you use one of the firm’s approved agent building frameworks, it’s automatically registered, all that information is recorded there for you. And if you want to do a manual registration, you can certainly do that. So, the second problem we have is that now

[09:48] that we’ve got all these agents doing all these things, we [snorts] quickly notice that what they’re doing is really different. And that means our agents carry really different risks, right? So, a thing that summarizes Jira linear tickets is really different than a production deployment agent that can touch a running system. And if we can use the same if we We to use the same review process to cover all of these agents, then [snorts] every agent is waiting in the same queue for weeks for human review, and if people are going to route route around slow processes, then we wind up in the same situation that we

[10:20] had before. So again, you might be tempted to say the answer is something like really detailed heavy manual review by all of these different constituencies. Again, that feels safe, but now we’ve got a trivial summarizer waiting 2 months for the same sign-offs as an agent that is touching production systems. And most of the good agent ideas, most of the ones that have value right away, start out as small experiments, and you don’t want those people to wait in the same line as the stuff that’s touching production right away. So the reviewers are drowning in these like low-risk

[10:51] requests, and the high-risk ones have to share that attention pool. So we don’t want to trade away that speed if we can help it. So again, because not every agent needs the same review, and because most agents are purpose-built rather than open-ended. When I say open-ended here, you can imagine coding agents like Pi or Claude Code. When you open them and you start typing, uh Claude Code or Pi doesn’t know what you’re about to ask. It doesn’t It doesn’t circumscribe its purpose in any particular way, but most of the agents that are deployed in enterprises do have very specific purposes. When you’re

[11:22] engaging with that agent, it’s to do something specific that’s well known and well understood. So they have a very specific reason for existing and a very circumscribed purpose. And you can tell these agents apart from each other by looking at what they declare up front, their tools, um the end points they access, the controls that that are applied to them, etc. So the third problem is that if you know about your agents and what they’re doing, you’ll quickly notice that many agents don’t talk to each other, or sorry, they don’t talk to just one thing

[11:53] or in just one capacity. The more open-ended the agent is, the more it looks like a Claude Code or Pi, the more it can do a variety and a diversity of different things. Call an internal API, run a tool like a web search, that sort of thing. And [snorts] each one of those is a different opening a different door to a different kind of risk. And if you give an agent an entitlement for a role account, then it can do a lot more damage than something that’s just going to read a public web page, for example. So, the question is not can this agent do X, but what’s the

[12:24] granularity that we need to solve for for the agent to act successfully? And again, one tempting answer is to kind of be heavy-handed here or to give every agent the same short allow list of stuff that’s safe to do and then block everything else. Uh that’s safe, but it’s also useless. An agent that can’t uh that can’t search or can’t call an API or can’t do any of those things without asking somebody first can’t really do the work that it was intended for. And then teams either give up on those agents or they find a way around the wall, and both outcomes

[12:55] are costly. So, a wide kind of blanket block on everything trades away the innovation that we want to preserve and avoids making a real decision about risk. Um and as author John Shedd wrote, “A ship in harbor is safe, but that is not what ships are for.” So, the fix here is to let agents declare their purpose upfront and say what tools they’re going to use or what tools they need access to. Um so, in the second column here, we might say that a research summarizer is going

[13:27] to be allowed to use a web tool to access research, but for a release deployer agent, we’re not going to allow them to do that because they have no reason to use that tool. And so, if they try to ask for it, they won’t get it by default. Um so, we don’t need to make this kind of decision for every tool. The agents just have to say which tools they want. Right? And and you’re as the agent author, you’re in the best position to say, “I need these four things out of the 500 that are available.” So, the way we need to enforce that is that when agents run in our managed

[13:59] environments, they look at the registry that we talked about before to look up what policies apply to it at initialization time. And that policy gets translated into enforcible statements, like which endpoints are you allowed to access, which hosts are you allowed to access, uh what other types of resources are available or not available to you. And in this way, nobody’s writing a ticket every time they need to change the access, nobody’s going to talk to IT or some other group outside of your team. As long as you conform to the risk score

[14:31] that we talked about before, and you’re in the agent registry, you’re you’re governed, you’re approved. So, this is how we keep the cost to teams really low for deploying, building, running agents. And the same control architecture works in a variety of settings. The next thing we noticed was that teams were building a a ton of different ways to evaluate agents, and every stack looks different, and some teams don’t build anything at all. Sometimes you build like this really detailed stack for how your models work, sometimes it’s sometimes there’s nothing, and I

[15:01] think in general we’d be upset if teams were not writing unit tests, right? And we consider evals to be kind of the same thing. If models are changing, that’s like a runtime dependency that your application has, and if your agent is going to change models, it doesn’t know without the evals what’s going to happen to its to its outputs and to the quality of those outputs. So, again, one tempting answer here is let’s have some kind of central evaluation methodology that waits for a full eval suite and a

[15:31] committee sign off, but now every like prompt tweak, every one-line change is going to sit in that same queue. So, we don’t want to put more decisions on more reviewers for things like that. We we don’t want to trade away that iteration. So, again, you wouldn’t ship software without unit tests, so agents need evaluations for the same reason, and we want to provide this stuff at the level of the firm that’s going to be the same for everybody. So, team A writing evals, team B writing evals, they’re both going to have many of the same features. So,

[16:01] we want to have one shared approach to how we do evals, and have the shared approach be something that’s run by the firm and available to everybody for doing their evals. So, that covers all the common parts of evals, and all you’ve got to do is just write what’s true about your agent. Uh and finally, maybe you’ve had the experience of being asked to approve lots and lots of individual agent actions when there’s a human in the loop. So, that’s fine at a small scale, but once you’re operating agents in parallel or in production, this becomes completely onerous and review requests

[16:33] come in faster than anybody can be expected to approve them. I mean, after the first few times of this happening, you succumb to review fatigue where you just see yes, yes, yes, yes, yes, and eventually you click yes on something that’s, you know, activating a new nuclear bomb, right? So, you don’t want to click yes by reflex, but that’s going to happen inevitably. And one recent example of this is, uh, earlier this year a director at an AI research lab told her open claw agent to suggest emails to delete from her inbox and then wait for her approval, but her inbox was so large that eventually the

[17:03] agent compacted its context and lost the part that said, “Wait for my approval.” And then it deleted hundreds of emails and didn’t stop when she told it to stop from her phone. So, again, you might be tempted to try to make a human approve every action, but that’s not the right way to do it. A better approach is to let these independent, conservative classifiers make decisions about routine calls and then send a person only the requests that are most important, the ones that are most likely to make a difference. If you’re saying yes 99.99999%

[17:33] of the time, then that’s probably just a rule that the agent should follow, not a request you need to ask the human for permission for. And the stuff that’s unclear or ambiguous or potentially dangerous, yes, surface that to a human or if it’s definitely just dangerous, deny it outright. So, this is a way to not have to do all the review work all the time. So, we don’t want to take the same approach for both explicit, uh, when an explicit rule is applied, we want deterministic fast paths. When explicit rules don’t apply and there’s some ambiguity, we want a classifier to

[18:04] do that work instead. So, putting those five pieces back together, you create a registry so that every agent is visible from the day it’s created. You score each agent so human review goes in the right spot. You run on guardrails so that they only touch what they need. You share evals and metrics so everybody is reaching the same bar without having to reinvent the wheel. And then finally you govern your runtime to make sure that classification happens there and not somewhere else. So each of these controls works together. So I’ll leave you with one question. Why

[18:35] do cars have brakes? It’s not just so that you can stop, it’s so that you can go fast and stop safely. So controls for our agents works the same way. Thank you very much. I’m John Feminella and I hope you had a good time. >> [applause] [music]