Seis Semanas com IA Agentic Contra Fraudes em um Sistema Adversarial
Um arquiteto de IA de produção compartilha sua experiência de seis semanas implementando IA agentic para detecção de fraudes em um ambiente financeiro regulamentado, destacando os desafios e aprendizados de uma corrida armamentista digital.
MundiX News·30 de junho de 2026·8 min de leitura·👁 1 views
Implementei os primeiros resultados em nosso produto prematuramente. Na época, parecia lógico: conectamos IA agentic à análise de logs e comportamento do usuário em um produto regulamentado com transações financeiras reais, a qualidade da detecção aumentou e os analistas de fraude passaram a retornar menos casos inúteis para os engenheiros. Externamente, isso já parecia uma camada de defesa funcional: os analistas viam menos ruído, os engenheiros recebiam issues mais claras e o produto finalmente viu um benefício prático em vez de mais uma demonstração. Eu disse algo como: "Vejam, isso não é mais um brinquedo". Uma frase ruim, como se viu.
Porque assim que a defesa começa a funcionar, mesmo que um pouco, perguntas adultas e sérias surgem imediatamente. "E se aplicarmos isso a pagamentos? E a abuso de bônus? E a L7? E a engenharia social? E a casos estranhos de suporte, onde um único ticket explica de repente metade de um gráfico?" Perguntas honestas. Apenas caras.
E em sistemas com um adversário ativo, há outro detalhe desagradável: uma defesa funcional se torna um sinal para o outro lado. Estou escrevendo com base na minha própria experiência de engenharia. Os detalhes foram ligeiramente generalizados e anonimizados, porque em antifraude, a especificidade excessiva rapidamente se transforma em um manual para o outro lado.
Contexto: Dinheiro e um Adversário Constantemente Ativo
Era um produto regulamentado com transações financeiras reais em vários mercados, a alegria usual: botnets, caçadores de bônus, multi-contas, esquemas de saque, grupos de fraude, tráfego L7, que parece chato e quase legítimo até que você compare os timings, o histórico da conta, a impressão digital do dispositivo, o comportamento de pagamento e alguns tickets de suporte. Regras clássicas sobrevivem mal nesse cenário. Assinaturas ficam obsoletas, limites são ajustados e, após algum tempo, o dashboard começa a descrever com confiança o atacante de ontem: os gráficos são bonitos, apenas um pouco tarde.
Não vou fingir que inventamos um botão mágico para "encontrar fraude". Não havia mágica ali. Havia uma máquina antifraude já existente, muitos sinais sujos, analistas competentes, SRE, segurança, dor do produto e uma tentativa de integrar uma camada agentic ao loop de controle. Uma abordagem de "chapéu da moda no topo do sistema" teria desmoronado rapidamente aqui. Foi aí que as coisas ficaram interessantes.
Stack, para Clareza
A camada inferior de agentes estava em LangChain e LangGraph. A orquestração foi feita através do Claude Agent SDK. Pipelines foram executados pelo Dagster. Eventos viviam no Kafka, análise no ClickHouse, investigações no OpenSearch, tudo rodando no Kubernetes. Os modelos eram mistos: OpenAI, Anthropic, modelos locais com LoRA onde modelos locais faziam sentido em termos de custo ou privacidade. Langfuse cuidava do tracing, controle de qualidade e custos.
A camada agentic operava ao lado do antifraude e da segurança, usando-os como um conjunto de ferramentas. Um agente podia consultar o ClickHouse para um corte, comparar uma coorte com a semana anterior, verificar um padrão semelhante de chamadas de API no OpenSearch, modificar uma amostra, propor uma atualização de regra, levantar um caso para um humano ou coletar um resumo para verificação manual. Em alguns lugares, a decisão era automática: definir um flag, alterar uma amostra, pressionar temporariamente um cenário suspeito. Em locais onde o dinheiro estava envolvido, um humano permanecia no loop, porque se um agente pode bloquear o movimento de dinheiro, não se deve deixá-lo interpretar o departamento de fraude. Algo assim.
Uma bela recontagem de logs rapidamente deixou de ser interessante. LLMs podem fazer isso, é claro, mas é nível de demonstração. O benefício real surgiu onde o sistema começou a participar do ciclo de controle: detectou um desvio de padrão, alterou uma amostra, preparou uma explicação para um analista, propôs uma regra, depois recebeu feedback de que era um falso positivo, e esse feedback voltou para o controle de qualidade (aqui tivemos que lidar com como não transformar o feedback em um lixão).
Ou seja, deixou de ser um dashboard. Um dashboard mostra um problema, e essa coisa tentava intervir nele.
Os Dados Eram Sujos. Como Sempre.
É muito tentador contar essas histórias através de um data warehouse de features bem organizado, mas tínhamos cerca de quinze fontes, e cada uma com sua própria versão da verdade. Eventos de autenticação são quase normais, até que uma integração legada falha em passar um campo. Impressões digitais de dispositivos são úteis, até que a equipe começa a confiar nelas como passaportes. Pagamentos e saques dizem uma coisa, o uso de bônus adiciona outra, o status KYC muda o contexto, então chega um ticket de suporte com uma frase desagradável (não vou citar literalmente, por razões óbvias), e você pensa: "Ah, é por isso que o gráfico parecia estranho".
Geografia, IP, sinais de proxy, latências de tempo, comportamento na sessão, forma das chamadas de API, eventos de produto. Sujo, útil, cheio de mentiras e nomes "temporários" de 2018. Um único sinal fraco quase não significa nada. Dez sinais fracos ao longo do tempo começam a contar uma história, e o agente podia dizer algo como: "esta conta se parece com a coorte que bloqueamos na semana passada, mas a pontuação antifraude diz "normal" por algum motivo". Ou "esta chamada de API está abaixo do limite L7, apenas o timing dela está errado, vamos aumentar a amostragem aqui"; ou "o comportamento ao sacar dinheiro não bate com o ciclo de vida normal da conta". Estou parafraseando, mas não muito longe.
A tabela de métricas não era bonita, porque tabelas de métricas de produção geralmente não são bonitas. Observamos incidentes de fraude, detecção de ataques L7, casos de engenharia social, carga de verificação manual, tempo até a detecção e o consumo de tokens, porque tokens de repente se tornaram uma linha de orçamento (surpresa para aqueles acostumados a considerar LLM como uma API "quase gratuita" por US$ 200 por mês). Precisão e recall eram necessários, mas os analistas de fraude perguntavam de forma mais simples: "isso me faz perder a manhã ou me economiza?"
A primeira fase não foi sobre "o modelo deu bons resumos". Mudou a operação: análise mais rápida, menos verificações manuais inúteis, melhor ligação de sinais de sistemas que antes fingiam não se conhecer. Verdade, não por muito tempo: a vantagem durou algumas semanas.
Então os Hieróglifos Apareceram nos Logs
Alguém inseriu um fragmento de log em um chat. Acho que foi durante uma investigação L7, mas não posso garantir o dia. Dentro havia hieróglifos. Sem a cena de filme onde a tela fica subitamente verde e todos gritam "fomos hackeados": apenas um pedaço de lixo em um local onde um cenário de usuário normal não deveria deixar tal lixo. Primeiro, você pensa em um problema de codificação, porque, bem, o que mais? Então você vê um segundo caso semelhante. Então os relatórios do orquestrador começam a mudar de tom: há dúvida, mas é um tanto quanto modelar, plástico.
A qualidade da classificação começou a cair em ambos os eixos nas interações L7 com APIs de produto. Precisão pior. Recall pior. Quando ambos caem simultaneamente, pela minha experiência, o padrão mudou. Não se resolve com limites.
Os atacantes mudaram a forma do comportamento. Picos explícitos se tornaram mais longos e suaves. Cruzamentos de limites se transformaram em "quase lá, mas não". Ações prejudiciais se tornaram ações quase legítimas que ainda sobrecarregavam o backend e a camada de defesa. Muitos pequenos cortes. Barato para eles, caro para nós.
O atacante não precisa quebrar seu modelo de forma elegante em um sentido acadêmico. Basta fazer com que a defesa custe mais do que o ciclo de ataque deles. Do nosso lado, tínhamos conformidade, regras de processamento de dados, revisão jurídica, DPIA, restrições de log, modelo interno de custo de tokens e computação. Do lado deles, o ciclo era mais barato: gerar comportamento, observar o resultado, alterar parâmetros, repetir. Quase invejável. Antes disso, a detecção podia durar meses. Aqui, a vantagem durou cerca de seis semanas.
Por Que a IA Agentic Acelerou Ambos os Lados
LLMs sobre logs por si só não são assustadores. Podem ser úteis, mas podem ser mantidos como uma ferramenta analítica: perguntei, recebi um resumo, segui em frente. O esquema agentic muda a velocidade da iteração. A defesa ganha um ciclo: sinal -> hipótese -> verificação em dados -> alteração de amostra, regras ou verificação manual -> feedback. O atacante ganha um ciclo semelhante: tentativa -> observação da reação -> alteração de parâmetros -> nova tentativa. Se ambos os lados automatizaram esse ciclo, a corrida simplesmente se comprime no tempo.
Antes, você tinha uma semana para analisar um novo esquema. Depois, alguns dias. Depois, uma noite, e pela manhã você já está olhando para um gráfico que parece "eles também não dormiram". A defesa, ao mesmo tempo, tem mais atrito. Essa é uma diferença sistêmica, não uma reclamação sobre burocracia.
A defesa precisa proteger usuários honestos, explicar bloqueios, não registrar dados sensíveis em logs desnecessários e não transformar SREs em babás gratuitas para uma camada inteligente, mas barulhenta. Ainda precisa provar ao produto que falsos positivos não matam a receita. O atacante só precisa que a economia feche.
É por isso que a frase simples "vamos adicionar IA à detecção de fraudes" soa inocente demais. Você adiciona. Então você possuirá um pequeno produto com usuários, pressão de custos, um conjunto de regressão, rotulagem manual e adversários que leem suas reações através do comportamento do sistema. Divertido, mas não é mais um experimento de fim de semana.
O Custo Não Foi Apenas em Tokens
Tokens são pelo menos visíveis: chamadas de modelo, inferência local, tracing, armazenamento, amostragem aprimorada, modelos mais caros para casos complexos. Usamos roteamento, processamento em lote, resumos, amostragem baseada em risco, modelos baratos para triagem inicial e modelos fortes onde necessário. Isso ajudou, mas não zerou a curva. O custo menos óbvio foi a atenção das pessoas. Muitos casos de fronteira e os analistas de fraude param de confiar no sistema. Muitos bloqueios e o produto vem com forcados. Muitas escaladas para SRE e SRE começa a ver a defesa como um vizinho indesejado. Em um mês, a camada de defesa tem sua própria fila de tarefas, seus próprios bugs, suas próprias regressões e seus próprios "por que isso funcionava ontem?".
A descrição mais precisa: tornou-se um produto. A má notícia é que um produto precisa ser mantido. O que eu faria diferente
Eu investiria mais cedo em honeypots. Muitas armadilhas diferentes, não apenas uma armadilha bonita. Parte visível para automação barata, parte medindo a velocidade de adaptação, parte ajudando especificamente a entender qual modelo do nosso sistema o atacante construiu.
Se o outro lado também tem um ciclo agentic, a defesa precisa observar não apenas as contas, mas a própria adaptação. Quais parâmetros eles mudam primeiro? Quanto tempo esperam após um bloqueio? Eles tentam espalhar a carga ao longo do tempo ou mudar a forma do dispositivo e dos pagamentos? É possível fazê-los revelar um pouco do seu mapa mental?
Eu também construiria um agente de red team contra um adversário ativo desde o primeiro dia. O objetivo de tal agente é chato e útil: imitar um adversário paciente, estender padrões ao longo do tempo, ficar abaixo dos limites, gerar carga quase legítima, mutar o comportamento de dispositivos e pagamentos, atacar o modelo de custo.
Métricas de qualidade também são necessárias, mas se o atacante ataca o custo, um recall bonito não salva mais. E eu trataria a verificação de prompts e agentes como engenharia de produção mais cedo. Prompts em um sistema de controle de versão. Casos de regressão de incidentes reais. Testes de custo ao lado de testes de qualidade. A verificação manual deve retornar como feedback rotulado; um comentário no Slack duas semanas depois não será mais encontrado por ninguém. O lançamento de um agente deve ser mais parecido com o lançamento de código de pagamento do que com a edição de texto em um painel de administração.
O Esquema Mínimo que Começou a Funcionar
Se simplificarmos para um esqueleto arquitetônico, ele parecia assim:
Em um slide, é mais fácil vender "análise agentic". Na produção, o loop de feedback mantém o sistema. Sem ele, a camada agentic rapidamente se transforma em um gerador confiante de explicações para padrões antigos. Ela falará lindamente, apenas tarde demais. Mais ou menos como um dashboard, mas mais caro.
Um loop normal requer coisas chatas: esquemas de eventos, proprietário, rotulagem, versionamento, rollback, orçamento de tokens, limites, alertas de degradação, log de decisões, limites claros para ações automáticas. E ainda uma pessoa que tem o direito de dizer: "pare, este modelo está resolvendo com confiança a semana passada".
Sem isso, você obterá uma demonstração bonita que, na produção, começará a cheirar mal rapidamente. O que disso pode ser levado para outros domínios
A história não é apenas sobre produtos com transações financeiras reais. É apenas que a dor é vista mais rapidamente lá, porque dinheiro, bots e reguladores andam juntos. A mesma lógica aparece em pagamentos, anti-abuso, fraudes em marketplaces, segurança de API, confiança e segurança do usuário, até mesmo em alguns tipos de suporte onde o usuário ou bot aprende a contornar as regras.
Se o ambiente tem um adversário ativo, um defensor de IA útil se torna quase automaticamente parte da corrida. Ele acelera você, mas também acelera o processo de aprendizado do adversário, porque suas reações se tornam observáveis.
Portanto, a pergunta "podemos adicionar LLM aqui" eu deixaria de lado. Quase em todo lugar é possível, não é difícil. Eu faria outra pergunta: "conseguimos mudar a defesa mais rápido do que o adversário muda seu ataque, e ao fazer isso, não quebramos a privacidade, a operação e a confiança das pessoas que deveriam usá-la?"
Se não, os agentes fornecerão um dashboard mais caro. Se sim, eles realmente funcionam. Simplesmente a vitória não fica parada, e em sistemas com um adversário ativo, qualquer defesa funcional se torna rapidamente material de estudo para o próximo ataque.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Implementei os primeiros resultados em nosso produto prematuramente. Na época, parecia lógico: conectamos IA agentic à análise de logs e comportamento do usuário em um produto regulamentado com transações financeiras reais, a qualidade da detecção aumentou e os analistas de fraude passaram a retornar menos casos inúteis para os engenheiros. Externamente, isso já parecia uma camada de defesa funcional: os analistas viam menos ruído, os engenheiros recebiam issues mais claras e o produto finalmente viu um benefício prático em vez de mais uma demonstração. Eu disse algo como: "Vejam, isso não é mais um brinquedo". Uma frase ruim, como se viu.
Porque assim que a defesa começa a funcionar, mesmo que um pouco, perguntas adultas e sérias surgem imediatamente. "E se aplicarmos isso a pagamentos? E a abuso de bônus? E a L7? E a engenharia social? E a casos estranhos de suporte, onde um único ticket explica de repente metade de um gráfico?" Perguntas honestas. Apenas caras.
E em sistemas com um adversário ativo, há outro detalhe desagradável: uma defesa funcional se torna um sinal para o outro lado. Estou escrevendo com base na minha própria experiência de engenharia. Os detalhes foram ligeiramente generalizados e anonimizados, porque em antifraude, a especificidade excessiva rapidamente se transforma em um manual para o outro lado.
Contexto: Dinheiro e um Adversário Constantemente Ativo
Era um produto regulamentado com transações financeiras reais em vários mercados, a alegria usual: botnets, caçadores de bônus, multi-contas, esquemas de saque, grupos de fraude, tráfego L7, que parece chato e quase legítimo até que você compare os timings, o histórico da conta, a impressão digital do dispositivo, o comportamento de pagamento e alguns tickets de suporte. Regras clássicas sobrevivem mal nesse cenário. Assinaturas ficam obsoletas, limites são ajustados e, após algum tempo, o dashboard começa a descrever com confiança o atacante de ontem: os gráficos são bonitos, apenas um pouco tarde.
Não vou fingir que inventamos um botão mágico para "encontrar fraude". Não havia mágica ali. Havia uma máquina antifraude já existente, muitos sinais sujos, analistas competentes, SRE, segurança, dor do produto e uma tentativa de integrar uma camada agentic ao loop de controle. Uma abordagem de "chapéu da moda no topo do sistema" teria desmoronado rapidamente aqui. Foi aí que as coisas ficaram interessantes.
Stack, para Clareza
A camada inferior de agentes estava em LangChain e LangGraph. A orquestração foi feita através do Claude Agent SDK. Pipelines foram executados pelo Dagster. Eventos viviam no Kafka, análise no ClickHouse, investigações no OpenSearch, tudo rodando no Kubernetes. Os modelos eram mistos: OpenAI, Anthropic, modelos locais com LoRA onde modelos locais faziam sentido em termos de custo ou privacidade. Langfuse cuidava do tracing, controle de qualidade e custos.
A camada agentic operava ao lado do antifraude e da segurança, usando-os como um conjunto de ferramentas. Um agente podia consultar o ClickHouse para um corte, comparar uma coorte com a semana anterior, verificar um padrão semelhante de chamadas de API no OpenSearch, modificar uma amostra, propor uma atualização de regra, levantar um caso para um humano ou coletar um resumo para verificação manual. Em alguns lugares, a decisão era automática: definir um flag, alterar uma amostra, pressionar temporariamente um cenário suspeito. Em locais onde o dinheiro estava envolvido, um humano permanecia no loop, porque se um agente pode bloquear o movimento de dinheiro, não se deve deixá-lo interpretar o departamento de fraude. Algo assim.
Uma bela recontagem de logs rapidamente deixou de ser interessante. LLMs podem fazer isso, é claro, mas é nível de demonstração. O benefício real surgiu onde o sistema começou a participar do ciclo de controle: detectou um desvio de padrão, alterou uma amostra, preparou uma explicação para um analista, propôs uma regra, depois recebeu feedback de que era um falso positivo, e esse feedback voltou para o controle de qualidade (aqui tivemos que lidar com como não transformar o feedback em um lixão).
Ou seja, deixou de ser um dashboard. Um dashboard mostra um problema, e essa coisa tentava intervir nele.
Os Dados Eram Sujos. Como Sempre.
É muito tentador contar essas histórias através de um data warehouse de features bem organizado, mas tínhamos cerca de quinze fontes, e cada uma com sua própria versão da verdade. Eventos de autenticação são quase normais, até que uma integração legada falha em passar um campo. Impressões digitais de dispositivos são úteis, até que a equipe começa a confiar nelas como passaportes. Pagamentos e saques dizem uma coisa, o uso de bônus adiciona outra, o status KYC muda o contexto, então chega um ticket de suporte com uma frase desagradável (não vou citar literalmente, por razões óbvias), e você pensa: "Ah, é por isso que o gráfico parecia estranho".
Geografia, IP, sinais de proxy, latências de tempo, comportamento na sessão, forma das chamadas de API, eventos de produto. Sujo, útil, cheio de mentiras e nomes "temporários" de 2018. Um único sinal fraco quase não significa nada. Dez sinais fracos ao longo do tempo começam a contar uma história, e o agente podia dizer algo como: "esta conta se parece com a coorte que bloqueamos na semana passada, mas a pontuação antifraude diz "normal" por algum motivo". Ou "esta chamada de API está abaixo do limite L7, apenas o timing dela está errado, vamos aumentar a amostragem aqui"; ou "o comportamento ao sacar dinheiro não bate com o ciclo de vida normal da conta". Estou parafraseando, mas não muito longe.
A tabela de métricas não era bonita, porque tabelas de métricas de produção geralmente não são bonitas. Observamos incidentes de fraude, detecção de ataques L7, casos de engenharia social, carga de verificação manual, tempo até a detecção e o consumo de tokens, porque tokens de repente se tornaram uma linha de orçamento (surpresa para aqueles acostumados a considerar LLM como uma API "quase gratuita" por US$ 200 por mês). Precisão e recall eram necessários, mas os analistas de fraude perguntavam de forma mais simples: "isso me faz perder a manhã ou me economiza?"
A primeira fase não foi sobre "o modelo deu bons resumos". Mudou a operação: análise mais rápida, menos verificações manuais inúteis, melhor ligação de sinais de sistemas que antes fingiam não se conhecer. Verdade, não por muito tempo: a vantagem durou algumas semanas.
Então os Hieróglifos Apareceram nos Logs
Alguém inseriu um fragmento de log em um chat. Acho que foi durante uma investigação L7, mas não posso garantir o dia. Dentro havia hieróglifos. Sem a cena de filme onde a tela fica subitamente verde e todos gritam "fomos hackeados": apenas um pedaço de lixo em um local onde um cenário de usuário normal não deveria deixar tal lixo. Primeiro, você pensa em um problema de codificação, porque, bem, o que mais? Então você vê um segundo caso semelhante. Então os relatórios do orquestrador começam a mudar de tom: há dúvida, mas é um tanto quanto modelar, plástico.
A qualidade da classificação começou a cair em ambos os eixos nas interações L7 com APIs de produto. Precisão pior. Recall pior. Quando ambos caem simultaneamente, pela minha experiência, o padrão mudou. Não se resolve com limites.
Os atacantes mudaram a forma do comportamento. Picos explícitos se tornaram mais longos e suaves. Cruzamentos de limites se transformaram em "quase lá, mas não". Ações prejudiciais se tornaram ações quase legítimas que ainda sobrecarregavam o backend e a camada de defesa. Muitos pequenos cortes. Barato para eles, caro para nós.
O atacante não precisa quebrar seu modelo de forma elegante em um sentido acadêmico. Basta fazer com que a defesa custe mais do que o ciclo de ataque deles. Do nosso lado, tínhamos conformidade, regras de processamento de dados, revisão jurídica, DPIA, restrições de log, modelo interno de custo de tokens e computação. Do lado deles, o ciclo era mais barato: gerar comportamento, observar o resultado, alterar parâmetros, repetir. Quase invejável. Antes disso, a detecção podia durar meses. Aqui, a vantagem durou cerca de seis semanas.
Por Que a IA Agentic Acelerou Ambos os Lados
LLMs sobre logs por si só não são assustadores. Podem ser úteis, mas podem ser mantidos como uma ferramenta analítica: perguntei, recebi um resumo, segui em frente. O esquema agentic muda a velocidade da iteração. A defesa ganha um ciclo: sinal -> hipótese -> verificação em dados -> alteração de amostra, regras ou verificação manual -> feedback. O atacante ganha um ciclo semelhante: tentativa -> observação da reação -> alteração de parâmetros -> nova tentativa. Se ambos os lados automatizaram esse ciclo, a corrida simplesmente se comprime no tempo.
Antes, você tinha uma semana para analisar um novo esquema. Depois, alguns dias. Depois, uma noite, e pela manhã você já está olhando para um gráfico que parece "eles também não dormiram". A defesa, ao mesmo tempo, tem mais atrito. Essa é uma diferença sistêmica, não uma reclamação sobre burocracia.
A defesa precisa proteger usuários honestos, explicar bloqueios, não registrar dados sensíveis em logs desnecessários e não transformar SREs em babás gratuitas para uma camada inteligente, mas barulhenta. Ainda precisa provar ao produto que falsos positivos não matam a receita. O atacante só precisa que a economia feche.
É por isso que a frase simples "vamos adicionar IA à detecção de fraudes" soa inocente demais. Você adiciona. Então você possuirá um pequeno produto com usuários, pressão de custos, um conjunto de regressão, rotulagem manual e adversários que leem suas reações através do comportamento do sistema. Divertido, mas não é mais um experimento de fim de semana.
O Custo Não Foi Apenas em Tokens
Tokens são pelo menos visíveis: chamadas de modelo, inferência local, tracing, armazenamento, amostragem aprimorada, modelos mais caros para casos complexos. Usamos roteamento, processamento em lote, resumos, amostragem baseada em risco, modelos baratos para triagem inicial e modelos fortes onde necessário. Isso ajudou, mas não zerou a curva. O custo menos óbvio foi a atenção das pessoas. Muitos casos de fronteira e os analistas de fraude param de confiar no sistema. Muitos bloqueios e o produto vem com forcados. Muitas escaladas para SRE e SRE começa a ver a defesa como um vizinho indesejado. Em um mês, a camada de defesa tem sua própria fila de tarefas, seus próprios bugs, suas próprias regressões e seus próprios "por que isso funcionava ontem?".
A descrição mais precisa: tornou-se um produto. A má notícia é que um produto precisa ser mantido. O que eu faria diferente
Eu investiria mais cedo em honeypots. Muitas armadilhas diferentes, não apenas uma armadilha bonita. Parte visível para automação barata, parte medindo a velocidade de adaptação, parte ajudando especificamente a entender qual modelo do nosso sistema o atacante construiu.
Se o outro lado também tem um ciclo agentic, a defesa precisa observar não apenas as contas, mas a própria adaptação. Quais parâmetros eles mudam primeiro? Quanto tempo esperam após um bloqueio? Eles tentam espalhar a carga ao longo do tempo ou mudar a forma do dispositivo e dos pagamentos? É possível fazê-los revelar um pouco do seu mapa mental?
Eu também construiria um agente de red team contra um adversário ativo desde o primeiro dia. O objetivo de tal agente é chato e útil: imitar um adversário paciente, estender padrões ao longo do tempo, ficar abaixo dos limites, gerar carga quase legítima, mutar o comportamento de dispositivos e pagamentos, atacar o modelo de custo.
Métricas de qualidade também são necessárias, mas se o atacante ataca o custo, um recall bonito não salva mais. E eu trataria a verificação de prompts e agentes como engenharia de produção mais cedo. Prompts em um sistema de controle de versão. Casos de regressão de incidentes reais. Testes de custo ao lado de testes de qualidade. A verificação manual deve retornar como feedback rotulado; um comentário no Slack duas semanas depois não será mais encontrado por ninguém. O lançamento de um agente deve ser mais parecido com o lançamento de código de pagamento do que com a edição de texto em um painel de administração.
O Esquema Mínimo que Começou a Funcionar
Se simplificarmos para um esqueleto arquitetônico, ele parecia assim:
Em um slide, é mais fácil vender "análise agentic". Na produção, o loop de feedback mantém o sistema. Sem ele, a camada agentic rapidamente se transforma em um gerador confiante de explicações para padrões antigos. Ela falará lindamente, apenas tarde demais. Mais ou menos como um dashboard, mas mais caro.
Um loop normal requer coisas chatas: esquemas de eventos, proprietário, rotulagem, versionamento, rollback, orçamento de tokens, limites, alertas de degradação, log de decisões, limites claros para ações automáticas. E ainda uma pessoa que tem o direito de dizer: "pare, este modelo está resolvendo com confiança a semana passada".
Sem isso, você obterá uma demonstração bonita que, na produção, começará a cheirar mal rapidamente. O que disso pode ser levado para outros domínios
A história não é apenas sobre produtos com transações financeiras reais. É apenas que a dor é vista mais rapidamente lá, porque dinheiro, bots e reguladores andam juntos. A mesma lógica aparece em pagamentos, anti-abuso, fraudes em marketplaces, segurança de API, confiança e segurança do usuário, até mesmo em alguns tipos de suporte onde o usuário ou bot aprende a contornar as regras.
Se o ambiente tem um adversário ativo, um defensor de IA útil se torna quase automaticamente parte da corrida. Ele acelera você, mas também acelera o processo de aprendizado do adversário, porque suas reações se tornam observáveis.
Portanto, a pergunta "podemos adicionar LLM aqui" eu deixaria de lado. Quase em todo lugar é possível, não é difícil. Eu faria outra pergunta: "conseguimos mudar a defesa mais rápido do que o adversário muda seu ataque, e ao fazer isso, não quebramos a privacidade, a operação e a confiança das pessoas que deveriam usá-la?"
Se não, os agentes fornecerão um dashboard mais caro. Se sim, eles realmente funcionam. Simplesmente a vitória não fica parada, e em sistemas com um adversário ativo, qualquer defesa funcional se torna rapidamente material de estudo para o próximo ataque.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
