Recém-chegada de uma semana no ACFE Global em Boston (que teve significativamente mais partidas de Uno do que você imaginaria), Hailey Windham sentou-se com Chen Zamir (Head de Estratégia de Fraude), Tom Todd (Líder de IA Aplicada) e Ryan McCormack (Diretor de Engenharia) para um mergulho profundo em operações de fraude agentic. Esses Sardines abordaram tudo, desde um ataque de ATO de um cliente que usava seus próprios blocos como sinal de mutação até as lacunas de infraestrutura que só se tornaram visíveis depois que a implantação já havia sido automatizada.
Recomendamos fortemente conferir o webinar completo por conta própria, mas, enquanto isso, aqui vai um breve resumo do que achamos mais interessante.
Ataques de fraude em velocidade de máquina: um ataque de ATO que aprendeu com cada bloqueio
Chen começou com a história de um cliente lidando com tomada de conta de contas. Toda vez que o cliente ajustava uma regra, o ataque voltava um pouco diferente, e a resposta era tão rápida que a equipe começou a analisar o timing.
"Sempre que o ataque era bloqueado, a recusa na verdade era um sinal que o atacante usava para se adaptar e mudar seu comportamento. Nós literalmente vimos essas mudanças acontecendo em milissegundos e, claramente, não havia um humano por trás disso."
Ele fez questão de dizer que isso ainda é uma pequena minoria do que vemos. Mas a direção é clara, e ele foi totalmente franco: "Eu gostaria de ter boas notícias, é só comprar a Sardine, integrar a gente e pronto. Nunca é assim." Levar um programa de combate a fraudes à velocidade das máquinas significa repensar a organização e os processos, não apenas as ferramentas.
O KPI do ciclo de reação: Onde uma semana de tempo de resposta realmente se esconde
Se os ataques estão se adaptando em milissegundos, a questão passa a ser qual "velocidade" você está realmente medindo. Uma regra é acionada em tempo real, mas o processo por trás de mudar essa regra (identificar o problema, definir o escopo, desenhar uma solução, testá-la e, por fim, colocá-la em produção) pode facilmente levar uma semana. Chen chama isso de ciclo de reação, e ele escreveu sobre isso em nosso blog como o KPI que a maioria das equipes de fraude deveria acompanhar.
Nossa equipe de engenharia passou anos comprimindo a parte de implantação desse ciclo: um mecanismo de regras do qual os analistas fazem deploy diretamente, pipelines de modelos automatizados, testes embutidos. Esse trabalho valeu a pena e nós o faríamos de novo. Mas, quando a implantação ficou rápida, o tempo total do ciclo mal se mexeu, o que significava que aquela semana estava escondida em alguma etapa anterior do processo.
"Na verdade, o gargalo que encontramos, e que é um problema muito mais desafiador, está na interseção entre investigação e testes, talvez não necessariamente em implantação e detecção."
Às vezes, os dados de que você precisa nunca foram coletados, ou uma integração com um fornecedor simplesmente parou de funcionar silenciosamente meses atrás e ninguém percebeu. Os rótulos são outro problema completamente diferente: estornos levam semanas, denúncias de fraude podem nunca chegar, e as suas próprias decisões de bloqueio censuram o histórico, porque uma transação bloqueada não gera um resultado do qual seja possível aprender. E então há o vazamento, quando uma regra tem um bom desempenho em backtests, é colocada em produção e desmorona. "Esses problemas podem se tornar bastante grandes e problemáticos, difíceis de reverter e até mesmo de detectar em alguns casos."
Investigação de fraude em escala: impressão digital de dispositivos e o esquema de 150.000 contas
Tom mostrou como é o outro lado disso quando a infraestrutura está no lugar. Agentes executando buscas por padrões em segundo plano, um analista começando o dia com uma regra proposta já acompanhada da justificativa, e a possibilidade de conversar com o agente e contestar antes que qualquer coisa seja implementada.
Depois ele detalhou a investigação sobre a qual já escrevemos antes: um cliente sinalizou alguns cadastros suspeitos, nós extraímos a impressão digital de dispositivo compartilhado, percebemos que o IP indicava EUA enquanto os usuários estavam na verdade na Alemanha e nos Emirados Árabes Unidos, e passamos tudo para o nosso agente analista de dados. O agente mapeou as contas conectadas e destacou os sinais em comum, e o escopo continuou crescendo. 150.000 contas, um esquema coordenado, e a investigação, do primeiro alerta até o quadro completo, levou apenas alguns minutos.
O vídeo abaixo mostra o Tom explicando isso passo a passo.
Quatro armadilhas na implementação de agentes de IA em operações de fraude
Essa investigação funcionou porque a infraestrutura de dados por trás dela já estava em vigor. Aprendemos o que acontece quando isso não existe desde o início em nosso próprio trabalho com agentes.
Entregamos a um agente o nosso campo de ID de dispositivo sem explicar que os IDs de dispositivo dependem de um armazenamento do navegador que pode ser apagado, que as pessoas limpam os cookies regularmente e que alguns navegadores fazem isso automaticamente. O agente não tinha como saber disso: "Ele estava constantemente sinalizando: este é um mau ator, ele tem 10 dispositivos; este é um mau ator, ele tem 10 dispositivos." Um único campo, uma única peça de contexto faltando. Escale isso para 10.000 variáveis sem semântica associada e o agente passa a produzir ruído em grande volume.
LLMs também chegam com intuições embutidas sobre quais países parecem suspeitos, e uma empresa que atua globalmente precisa substituir essas intuições por evidências dos próprios dados, em vez de simplesmente aceitar os pressupostos prévios do modelo.
As decisões de analistas humanos parecem um bom ponto de referência de precisão até você realmente auditar o quão consistentes essas decisões são de caso a caso e em relação ao POP. Nós não conseguimos atingir as metas de precisão que queríamos até refinarmos o próprio ponto de referência.
E dar a um agente acesso irrestrito a toda a sua base de conhecimento parece eficiente, mas essa base contém suposições que já foram verdade e silenciosamente deixaram de ser, e essas suposições orientam as recomendações do agente sem que ninguém perceba.
Governança de agentes de IA: habilidade, confiança e sequência
Chen apresentou, durante o webinar, um framework de implementação que vale a pena detalhar aqui.
A proficiência em IA da sua equipe leva tempo de verdade para ser desenvolvida e não pode ser encurtada. Os cronogramas de implementação precisam levar em conta esse período de adaptação, não apenas a integração técnica. Chen disse que sabe com certeza que hoje é um usuário de IA melhor do que era há um ano, e essa curva de aprendizado vale para cada analista de uma equipe de fraude também.
A questão do número de pessoas surgiu, como sempre acontece. As equipes adotam IA e o quadro de funcionários permanece estável. Isso não é necessariamente um fracasso, mas sugere uma lacuna de confiança. A solução não é obrigar a adoção. É transparência: metas claras, monitoramento visível, relatórios que mostrem o que os agentes estão realmente fazendo. Sem isso, as equipes continuam fazendo o trabalho manualmente ao lado do agente, em vez de redirecionar seus esforços.
O argumento do Chen é que os agentes são governados por meio de dados e monitoramento, o que é trabalho de analytics, e a maioria das organizações de fraude ainda não tem essas funções devidamente estruturadas. Esses cargos precisam crescer antes que alguém fale em reduzir as operações.
A ordem em que você constrói também importa. Colocar agentes para escrever regras mais rápido não ajuda muito se seus rótulos estiverem desatualizados, porque as regras estão sendo treinadas em uma verdade de base ruim. Se você não conseguir rotular os eventos quase em tempo real primeiro, agentes que escrevem regras mais rápido estarão construindo sobre uma base fraca.
Por onde começar: um framework de auditoria de operações de fraude
Hailey pediu a cada painelista uma coisa para você levar de volta à sua mesa.
A dica do Tom foi a mais fundamental: antes de comprar ou construir qualquer coisa, documente os SOPs das suas operações de fraude para cada tarefa que sua equipe realiza. Quando você analisa chargebacks, quais são exatamente os passos? Onde é gasto mais tempo? Os clientes chegam à Sardine querendo agentes de IA antes de terem mapeado o que gostariam que o agente fizesse, e esse mapeamento é de graça.
A do Ryan era sobre o que vem depois: decida como você vai avaliar e auditar o sistema antes de construí-lo. Como você julgaria se ele está funcionando? Como você identificaria problemas? Essa capacidade de auditoria é mais fácil de projetar desde o início do que tentar encaixá-la depois.
A de Chen era simples: o seu ambiente de dados precisa estar pronto. Presumir que os seus dados já estão organizados e prontos para serem consumidos por IA quase sempre está errado se isso for apenas uma suposição e não algo que você verificou. E, além disso, presumir que agentes conseguem lidar sozinhos com dados fragmentados é igualmente perigoso.
A gravação completa está disponível sob demanda, e o whitepaper ao qual o painel se referia, a “leitura leve antes de dormir” recomendada por Chen, está aqui.
