Publicada em 10 de agosto de 2026, a segunda edição do Relatório de Gestão do Pix cobre o triênio 2023-2025. O documento traz um número bastante expressivo: quase 80 bilhões de transações em 2025, o que representa uma alta de 25,7% em relação ao ano anterior, totalizando um volume superior a R$ 35 trilhões.

Além dos resultados, o relatório dedica um capítulo ao futuro do sistema, delineando uma agenda de segurança composta por oito itens.

O segundo item dessa pauta atrai especialmente a atenção de quem atua com operações de risco. A iniciativa visa criar um indicador centralizado que aponte a probabilidade de fraude de uma transação. A proposta é que esse indicador, construído sobre um modelo de machine learning, seja alimentado por informações que o próprio Banco Central compila sobre marcações de fraude e sobre o ecossistema geral de transações realizadas.

Uma primeira leitura do mercado sugeriu a disponibilização imediata de um score de fraude. O relatório, contudo, é mais ponderado: o desenvolvimento do indicador não significa, necessariamente, sua distribuição para as instituições participantes. Essa disponibilização estará atrelada à confiança do BC na calibração do modelo e a uma profunda avaliação jurídica sobre a possibilidade de compartilhar esse tipo de informação.

São, portanto, duas dimensões fundamentais na evolução desse projeto: uma técnica e outra jurídica. Ambas seguem seu próprio tempo de maturação, ainda sem datas fixadas.

A dimensão técnica: a calibração do modelo

A busca pela “confiança no ajuste” reflete um desafio analítico sofisticado. Um classificador que analisa a totalidade das transações do Pix opera em um ambiente onde a fraude, felizmente, representa uma fração muito pequena do volume total em termos relativos, embora significativa em números absolutos.

Nesse cenário, o foco analítico se expande da acurácia geral para o comportamento da cauda: trata-se de observar atenciosamente como o modelo pontua as transações legítimas e como as instituições vão utilizar essa pontuação.

O relatório aborda o indicador de maneira colaborativa, tratando-o como um insumo valioso, e não como uma decisão imposta. O texto esclarece que a prerrogativa de autorizar ou rejeitar uma transação permanece com cada instituição, enquanto o BC fortalece seu papel de provedor de subsídios para embasar essa decisão.

Essa abordagem preserva a autonomia do ecossistema, mas introduz uma excelente oportunidade de refinamento: como integrar um sinal centralizado, calculado sem acesso a variáveis exclusivas da instituição, como dispositivo, sessão ou histórico do cliente, com as ricas informações internas já disponíveis.

É exatamente por isso que a calibração do modelo é tão importante. Um modelo bem calibrado oferece uma pontuação que pode ser lida como uma probabilidade real, facilitando a composição com outras evidências.

A dimensão jurídica: a natureza da informação

A avaliação jurídica, embora ocupe menos espaço no relatório, traz análises estruturais indispensáveis para o sistema.

O compartilhamento de informações sobre fraudes já faz parte da rotina das instituições. O DICT armazena marcações associadas a usuários e chaves Pix, distribuindo esses dados aos participantes para o aprimoramento contínuo de suas políticas de risco.

Em novembro de 2023, essa estrutura foi enriquecida com novos campos para detalhar a razão da notificação e o tipo de fraude, ampliando de forma consistente o arcabouço estatístico disponível para todos.

A transição para o novo modelo, no entanto, envolve uma mudança não de volume de informações, mas de natureza dos dados. Uma marcação de fraude tradicional reflete um evento reportado por uma instituição. Um score, por sua vez, constitui uma inferência estatística elaborada pelo regulador a partir do comportamento agregado de terceiros. Enquanto a primeira é um dado declarado, a segunda constitui um dado novo, formulado no instante do cálculo.

A autonomia na gestão de risco enquanto as definições avançam

A cronologia das atualizações regulatórias ajuda a contextualizar as dinâmicas atuais de prevenção à fraude.

Em 11 de setembro de 2025, a Resolução BCB nº 501 (que inseriu o art. 2º-A na Resolução BCB nº 142/2021) estabeleceu a diretriz para que as instituições recusem pagamentos direcionados a contas com fundada suspeita de fraude, definindo um prazo de adequação até 13 de outubro de 2025. A norma abrange contas de depósito à vista, de poupança e de pagamento pré-pagas.

Por adotar uma abordagem principiológica, sem criar um rol engessado, a regulamentação confia à avaliação de cada participante a definição de seus próprios critérios, incentivando o uso de dados públicos e privados para a tomada de decisão.

O próprio relatório do BC observa que essa flexibilidade de atuação gera políticas variadas, indicando também o surgimento de oportunidades de melhoria — especialmente em operações atípicas, como valores altos fora do horário comercial. Para apoiar essa evolução, projeta-se a criação de critérios objetivos mínimos que apoiem a identificação dessas suspeitas.

Em suma, a estruturação de referenciais sólidos e padronizados caminha de forma estratégica. Enquanto esses novos critérios e indicadores amadurecem, as instituições seguem convidadas a aplicar sua expertise analítica para embasar decisões seguras, em conformidade com as orientações vigentes desde outubro de 2025.

Oportunidades e caminhos práticos para a arquitetura de decisão

Para as operações, a evolução estrutural independe de a nova pontuação do BC chegar agora ou depois.

Caso o indicador seja disponibilizado, ele se integrará a um fluxo que já absorve várias outras variáveis, levantando a ótima reflexão sobre qual peso atribuir a ele e o momento ideal de sua inserção nos processos.

Caso a entrega passe por um tempo maior de maturação, o mercado continuará sendo fomentado por outras inovações valiosas já em desenvolvimento: critérios objetivos mínimos, marcações do DICT ainda mais refinadas e fluxos automatizados de bloqueios cautelares.

A semelhança entre esses cenários é o dinamismo e o ritmo da evolução tecnológica. A agenda de segurança do Pix é descrita como contínua e aberta a inovações permanentes. Na prática, isso prepara as políticas de decisão das instituições para incorporarem novos sinais e aprimoramentos com cadência natural.

Uma arquitetura de decisão que abraça esse futuro com tranquilidade possui propriedades como políticas centralizadas e organizadas; facilidade para conectar novas fontes de sinais sem a necessidade de reescrever sistemas inteiros; e a capacidade de observar e ajustar o peso de cada variável de forma fluida. Além disso, contar com registros claros sobre quais combinações de sinais levaram a cada desfecho permite afinar os modelos de forma orgânica e garante a transparência ideal para preservar transações legítimas com alta segurança.

Em nossa experiência apoiando a evolução antifraude no mercado brasileiro, observamos que a segunda dessas propriedades, a facilidade de conectar novas fontes, é o fator que mais otimiza a absorção de novos sinais.

Operações que tratam cada fonte como uma integração dedicada costumam demandar um ciclo completo de engenharia por sinal, um processo que precisa ser refeito a cada nova diretriz do regulador. Por outro lado, operações que encaram o fluxo de decisão como o verdadeiro artefato, orquestrando listas, regras de negócio e camadas probabilísticas em um único ponto, em tempo real, transformam essa adaptação em uma simples configuração.

Essa eficiência ganha escala rapidamente: a grande vantagem não se revela apenas na primeira fonte nova, mas na capacidade de absorver o quarto ou o quinto item da agenda de segurança com agilidade, mantendo o time de tecnologia focado em inovação, em vez de acumular demandas operacionais.

A Duranium apoia a evolução tecnológica da prevenção à fraude e identidade digital no mercado financeiro brasileiro. Se preparar a sua arquitetura de decisão é um objetivo da sua operação, adoraríamos contribuir com essa jornada. Fale conosco.

Compartilhar

A jornada de adoção da Inteligência Artificial nas empresas tem trazido aprendizados valiosos. Muitas vezes, a demonstração de uma nova ferramenta é um sucesso, o projeto recebe sinal verde e a equipe técnica entrega a solução proposta. Contudo, meses depois, algumas iniciativas ainda permanecem na fase de “piloto”.

Entender o caminho para fazer a transição sustentável para a produção é o que tem diferenciado os líderes de mercado.

A resposta para acelerar essa jornada vai além da tecnologia. Segundo a edição 2026 do relatório State of AI in the Enterprise, da Deloitte, 58% das organizações brasileiras relatam que até 20% de seus pilotos chegam à fase de implementação plena. No cenário global, 25% das empresas já conseguem escalar 40% ou mais dos seus experimentos para o dia a dia do negócio.

Esses dados nos convidam a um olhar estratégico: mais do que debater a maturidade dos modelos de IA, a grande oportunidade de evolução reside em como integramos essas inovações de forma inteligente às engrenagens da empresa.

Adoção como o primeiro passo para a transformação

O movimento inicial para uma estratégia de sucesso é compreender que a adoção da tecnologia é apenas a largada. O mesmo levantamento da Deloitte aponta que 85% das organizações globais (e 82% no Brasil) já autorizam o uso de IA para pelo menos um quinto de seus profissionais.

O potencial transformador ganha força quando essa rápida adesão passa a se refletir, de fato, na evolução e no aprimoramento dos processos de negócios.

Um relatório de julho de 2025 do MIT NANDA ilustra bem essa etapa de transição: enquanto mais de 80% das organizações exploraram ferramentas generalistas e cerca de 40% relatam implantações, o impacto inicial se deu mais no ganho de produtividade individual. O grande salto estratégico, agora, é traduzir essa produtividade em resultados financeiros globais para a companhia.

Uma excelente oportunidade de alinhamento, evidenciada no recorte brasileiro da Deloitte, está na gestão de expectativas: 87% dos líderes do país acreditam que a IA impulsionará o crescimento da receita, e 22% já percebem esse aumento na prática hoje. Construir pontes sólidas entre o que se espera e o que se mede é o que garantirá retornos cada vez mais expressivos e mensuráveis.

Do ambiente controlado à realidade operacional

Um dos segredos para o sucesso da IA pós-piloto é preparar a tecnologia para a riqueza e a complexidade do mundo corporativo. Em um ambiente de testes, as variáveis são perfeitamente controladas. Já na rotina operacional, a IA precisa estar preparada para lidar com exceções, possuir contexto acumulado e compreender o histórico de cada cliente.

Conforme aponta o MIT NANDA, o fator decisivo para a escalabilidade não é a infraestrutura ou a falta de talentos, mas a capacidade de aprendizado contínuo dos sistemas. Ferramentas que retêm feedback, adaptam-se ao contexto e evoluem de acordo com o uso ganham a adesão orgânica dos times.

Essa profunda conexão com a realidade da operação explica as diferentes jornadas da IA. Enquanto ferramentas generalistas de conversação apresentam conversão ágil (na casa dos 83%), as soluções integradas a processos específicos demandam uma adaptação mais cuidadosa à realidade da empresa para prosperar.

Entender a fundo essa estrutura de “bastidores” é o diferencial para que a inovação funcione na prática, com fluidez, todos os dias.

Expandindo o valor além de vendas e marketing

A estratégia de alocação de investimentos também revela caminhos promissores. A pesquisa do MIT NANDA indica um foco inicial expressivo em áreas de vendas e marketing. A razão para isso é muito pragmática: essas frentes oferecem métricas de resultado mais ágeis e fáceis de demonstrar aos conselhos de administração.

Entretanto, uma gigantesca janela de eficiência encontra-se nas áreas de backoffice (retaguarda). Embora os ganhos nessas frentes exijam indicadores mais sofisticados do que o aumento de receita no curto prazo, é justamente ali que muitas empresas relatam economias altamente expressivas — otimizando contratos, revisão de custos financeiros e gestão de parcerias externas.

O levantamento da Deloitte no Brasil reforça essa visão de valor: 59% dos respondentes apontam a melhoria na tomada de decisão e na geração de insights como a área mais impactada pela IA, superando a média global de 53%. O verdadeiro poder da IA se revela quando ela aprimora a inteligência de negócios, otimizando como a empresa decide e opera nos bastidores.

Agilidade e aprendizado em diferentes escalas

O estudo do MIT NANDA também traz uma reflexão valiosa sobre o dinamismo do mercado.

As grandes corporações lideram em volume de pilotos, mas são as empresas de médio porte que frequentemente demonstram mais agilidade, conseguindo levar projetos à implementação plena em cerca de 90 dias.

Nas companhias maiores, a necessidade de alinhar múltiplos sistemas e áreas naturais do seu porte faz com que esse ciclo exija mais tempo e sinergia. Contudo, isso não é um limite estrutural, mas sim uma oportunidade de aprendizado. Para acelerar esse movimento, 30% das empresas brasileiras já estão redesenhando seus fluxos críticos em torno da IA, segundo a Deloitte.

O diferencial das organizações bem-sucedidas é a disposição para reestruturar processos de forma colaborativa, em vez de simplesmente sobrepor a nova tecnologia a fluxos antigos.

Nesse contexto, recomenda-se uma leitura analítica sobre estatísticas muito repercutidas no mercado, como o dado preliminar de que “95% das iniciativas de IA não geram retorno”.

Ao mergulhar nesses números, identificamos que:

• O conceito de sucesso varia: A pesquisa foca na percepção de executivos em curto prazo (seis meses), não em relatórios financeiros consolidados.

• As categorias importam: A taxa refere-se a modelos de tarefas muito específicas, não englobando ferramentas generalistas, que convertem em taxas consideravelmente maiores.

Ler o mercado com profundidade e além das manchetes é o que garante decisões de orçamento estratégicas, seguras e muito bem fundamentadas.

O caminho das empresas que escalam a IA com sucesso

Ao observar as organizações que transformam experimentação em valor contínuo, fica claro que a inovação tecnológica caminha de mãos dadas com a excelência gerencial. Quatro características se destacam nas empresas que lideram essa transição:

1. Foco e escopo bem delimitados: Projetos que miram em um objetivo claro e que entregam valor imediato fluem com naturalidade.

2. Evolução de processos: Ajustar os fluxos de trabalho para extrair o melhor da ferramenta é muito mais eficaz do que forçar integrações complexas em métodos legados.

3. Engajamento e clareza de papéis: Organizações eficazes descentralizam a execução, mantendo a responsabilidade (accountability) bem definida junto aos gestores de cada área.

4. Critérios de sucesso desenhados no Dia 1: Definir com antecedência os indicadores que avaliarão o projeto cria bases sólidas para justificar investimentos em escala.

As expectativas do mercado seguem altas e inspiradoras. Planejar com ambição é o motor da inovação, e o sucesso em escala se concretiza quando aliamos esse entusiasmo à decisão corajosa de evoluir a nossa forma de trabalhar.

A Duranium apoia organizações a estruturarem a adoção de IA com governança, segurança, rastreabilidade e, acima de tudo, visão de negócios. Se a sua empresa está pronta para extrair o verdadeiro valor da Inteligência Artificial, nós somos o parceiro certo para essa jornada. Vale uma conversa?

Compartilhar

O tema da fraude com inteligência artificial no Brasil tem se concentrado especialmente em categorias como deepfake, prova de vida, foto sintética e vídeo gerado. Trata-se de uma preocupação legítima, à qual a indústria de verificação de identidade tem respondido com uma evidente corrida tecnológica.

Contudo, um detalhe nas declarações de quem combate a fraude em escala no país merece mais atenção do que tem recebido. Em entrevista ao Finsiders Brasil durante a Rio Innovation Week 2026, a CTO da Neon, Fabiola Marchiori, descreveu a evolução das contas laranja de um modo que reposiciona todo o problema.

Se no passado essas contas vinham com documentação falsa e podiam ser bloqueadas por algum nível de tecnologia, hoje tudo é real, desde o comprovante de residência até a pessoa e a foto. A conta existe de verdade; a diferença é que ela está a serviço de uma intenção criminosa, muitas vezes viabilizada por meio de venda, aluguel ou coação.

Esse cenário muda a pergunta que a esteira de defesa precisa responder, deixando de ser “esse documento é falso?” para se tornar “essa identidade verdadeira está a serviço de quem?”. E essa segunda pergunta pertence a outra camada. Não por deficiência da verificação de identidade, mas por escopo: biometria, prova de vida e validação documental foram desenhadas para responder por uma pessoa. Intenção, porém, não é atributo de pessoa — é atributo de relação. Ela só se torna observável quando se analisa a estrutura em volta do cadastro. Essa análise é possível. Ela é apenas difícil, e mora em outro ponto da esteira.

Diversificação e maior complexidade

Os dados de entrada ajudam a localizar o problema; segundo o levantamento das soluções de prevenção à fraude da Serasa Experian divulgado em agosto de 2026, o setor financeiro brasileiro registrou 1.747.373 tentativas de fraude de identidade no primeiro semestre do ano. Esse número representa um crescimento de 9,5% sobre o mesmo período de 2025, o equivalente a uma investida a cada nove segundos em processos de entrada e cadastro de clientes.

Dois recortes desse número importam mais do que o total, sendo o primeiro deles o alvo. O segmento de meios de pagamento, composto por empresas que viabilizam aceitação e processamento (incluindo maquininhas e canais digitais), concentrou 1.219.793 tentativas de fraude. Isso representa uma alta de 11,9% entre os dois períodos, e corresponde a sete em cada dez ocorrências identificadas no setor financeiro.

O segundo recorte diz respeito ao valor, visto que o montante protegido pelas tecnologias antifraude quase dobrou em um ano, saltando de R$ 51,3 milhões para R$ 100,4 milhões. Como observou o diretor de autenticação e prevenção à fraude da Serasa Experian, Leandro Bartolassi, os números sugerem que os criminosos não estão apenas tentando mais vezes, mas também mirando oportunidades de retorno significativamente maior.

Como os meios de pagamento concentram o maior volume de tentativas de fraude já na fase de entrada — que, neste setor, significa o credenciamento de estabelecimentos e o cadastro de pessoas jurídicas —, a atenção deve se voltar para a análise dessas empresas. Afinal, a tecnologia de deepfake ainda não é capaz de forjar uma estrutura societária inteira.

A importância de vigiar o comportamento

Mesmo no cadastro de pessoa física, a camada de identidade possui um limite estrutural de escopo, pois responde apenas sobre um instante específico.

A entrevista da Neon descreve com clareza o que acontece fora desse instante, indicando que a conta laranja nasce idônea. O fraudador realiza o que o mercado chama de “esquentar”, efetuando pequenas movimentações que constroem um score favorável, semelhante a um cadastro positivo, para só então disparar o golpe. Consequentemente, o ponto de detecção não ocorre na abertura, mas sim no momento da virada.

A executiva defende a implementação de múltiplas camadas e a lógica de confiança zero, na qual cada etapa refaz o trabalho da anterior em vez de assumi-lo como concluído. Ela resume o ritmo dessa corrida em uma frase que serve como um verdadeiro diagnóstico de arquitetura, afirmando que “a vacina de seis meses atrás já não resolve porque a doença mudou”. Além disso, ela cita a nova versão do Mecanismo Especial de Devolução do Pix (MED 2.0) por sua capacidade de rastrear o dinheiro em múltiplos níveis e (a depender do resultado da análise) devolver valores de contas marcadas como de risco para a base compartilhada do sistema.

Embora tudo isso seja verdadeiro e necessário, descreve um regime de defesa que só funciona se houver elementos adicionais para observar além do indivíduo no momento do cadastro. Se a foto, o CPF e a pessoa são reais, a análise deixa de ser sobre autenticidade e passa a ser sobre coerência: o que o histórico dessa pessoa diz — processos judiciais, óbito registrado, exposição política, presença pública real — e o que a estrutura ao redor dela revela.

A complexidade das relações societárias

Atualmente, gerar um rosto convincente ou um documento coerente tem um custo praticamente nulo. No entanto, produzir um histórico de relações que resista ao cruzamento de dados continua sendo custoso em termos de tempo, coordenação e rastros deixados.

Uma empresa de fachada pode até apresentar um CNPJ ativo, um sócio real e um endereço válido, mas costuma carecer de coerência ao se analisar o seu entorno. Isso inclui situações como um mesmo endereço abrigando dezenas de CNPJs sem relação operacional, sócios figurando simultaneamente em estruturas incompatíveis, cadeias complexas de empresas que dissolvem a titularidade final, ou um capital social desproporcional à atividade declarada. Outros indícios envolvem um CNAE divergente da atuação real, aberturas de empresas concentradas em lotes temporais com o mesmo padrão, reaberturas logo após a baixa e a ausência de qualquer presença digital legítima (como domínios, mapas, reputação ou rastros públicos de operação).

Embora nenhum desses sinais prove a fraude de forma isolada e muitos possuam explicações lícitas, a verdadeira utilidade reside no cruzamento das informações. Quando um mesmo cadastro acende múltiplos alertas simultaneamente, não se trata apenas de uma suspeita sobre a pessoa, mas sim de uma anomalia clara na estrutura.

É justamente nesse terreno de análise que o VOID, módulo de enriquecimento da plataforma FraudGate , opera. A ferramenta cruza o grafo societário brasileiro de mais de 67 milhões de CNPJs com mais de trinta dimensões de análise sobre CNPJs e CPFs, abrangendo estrutura societária, listas restritivas e sanções (como CEIS, CNEP, CEPIM, lista suja, OFAC, ONU e PEP), além da coerência de cadastro, processos judiciais e presença digital. Dessa forma, cada dimensão devolve um sinal único que pode ser consumido diretamente pelo fluxo de decisão.

Dentro da plataforma, esse sinal não atua de forma isolada, pois o VOID enriquece os dados, enquanto o CORTEX orquestra a decisão transacional em tempo real utilizando regras e modelos de machine learning treinados com casos de fraude confirmada. Em paralelo, o AUTOPILOT raciocina sobre a fila operacional por meio de uma camada de agentes de IA que investiga, prioriza e resolve os casos rotineiros antes mesmo de chegarem ao analista. Toda essa arquitetura funciona como um SaaS gerenciado com integração via API, desenhada especificamente para auditorias sob o arcabouço normativo do BACEN, COAF e LGPD.

A lógica de composição se mostra mais importante do que qualquer módulo isolado, uma vez que a verificação de identidade revela quem está presente, a análise de estrutura desvenda o que está por trás, e a decisão transacional determina se a operação deve prosseguir naquele momento. Como se tratam de três perguntas distintas, a fraude atual explora precisamente as lacunas existentes entre elas.

A conexão de entidades na evolução do antifraude

Embora o deepfake seja um problema real e de camada, o mercado já tem direcionado investimentos intensos para mitigá-lo. Hoje, o risco maior reside em gastar toda a atenção tentando provar que a pessoa é quem diz ser (em um cenário onde ela quase sempre é genuína), e ficar sem recursos para outras análises.

Assim, quando a fraude deixa de falsificar identidades e passa a alugar perfis legítimos, o antifraude deixa de ser apenas uma questão de autenticação para se tornar, também, uma questão de relação entre entidades.

-----

Quer entender onde estão as lacunas na sua esteira de defesa? Fale com o time da Duranium.

Compartilhar

Fontes

• Finsiders Brasil — “Golpes e fraudes com IA elevam preocupação com identidade digital”, 13/08/2026. Entrevista com Fabiola Marchiori, CTO da Neon. https://finsidersbrasil.com.br/noticias-sobre-fintechs/golpes-e-fraudes-com-ia-elevam-preocupacao-com-identidade-digital/

• Convergência Digital — “Meios de pagamentos lideram tentativas de fraudes no país”, 20/08/2026. Dados das soluções de prevenção à fraude da Serasa Experian. https://convergenciadigital.com.br/seguranca/meios-de-pagamentos-lideram-tentativas-de-fraudes-no-pais/

Nos últimos dois anos, muitas empresas que adotaram a inteligência artificial acreditaram ter solucionado a questão da capacitação ao comprar licenças, contratar plataformas e emitir certificados. No entanto, poucas conseguem responder com clareza quem na equipe de fato aprendeu a utilizar essas ferramentas no dia a dia.

Embora a intuição sugira que o acesso ilimitado a informações detalhadas tornaria o aprendizado trivial, o resultado prático tem sido o oposto — um fenômeno respaldado por pesquisas recentes sobre o impacto da IA no pensamento crítico, que mostram como a confiança cega na ferramenta reduz o esforço cognitivo.

Durante o webinar “A ilusão do aprendizado na era da IA”, Eduardo Morelli, cofundador da Duranium e criador da Duranium Academy, explorou esse paradoxo com base em suas quatro décadas de experiência acadêmica. Para ele, o problema central não reside na tecnologia em si, mas no impacto psicológico que o excesso de respostas prontas exerce sobre o desenvolvimento do profissional.

De procurar a decidir: o que a IA realmente exige da mente humana

Quando a internet surgiu ela eliminou o que podemos chamar de “assimetria de conhecimento”. Ou seja, ele não fica restrito a quem ensina, como antes. Isso tornava o acesso ao saber o recurso mais escasso. Com a disseminação dos buscadores, como o Google, surgiu a necessidade de desenvolver a capacidade de procurar. A habilidade mais valorizada passou a ser a formulação de buscas precisas e o julgamento crítico das fontes encontradas.

Com o advento da IA conversacional, vivemos um terceiro deslocamento, possivelmente o mais radical até agora. Ao contrário dos mecanismos de busca tradicionais, a inteligência artificial não entrega apenas uma lista de links para avaliação, mas fornece respostas prontas, articuladas e com aparência definitiva. Assim, a competência exigida deixou de ser a simples pesquisa e passou a ser a capacidade de decidir o que perguntar, o que aceitar como verdade e o que validar antes de usar.

O grande erro corporativo dentro deste cenário é encarar o salto tecnológico como o fim da necessidade de treinamento. Na verdade, a tecnologia apenas eliminou uma barreira operacional para colocar uma habilidade abstrata, a capacidade de realizar julgamento crítico, no centro das competências críticas. O objeto da formação mudou, mas a urgência dela permanece.

O perigo da resposta pronta para o aprendizado

Modelos de linguagem operam de forma probabilística, produzindo, como resume Morelli, “respostas plausíveis, não necessariamente verdadeiras”. Essa limitação técnica é conhecida, mas o efeito da alta qualidade dos textos gerados costuma ser subestimado. Quando um sistema entrega uma explicação bem escrita e repleta de exemplos convincentes, o usuário tende a baixar a guarda do próprio senso crítico. “As pessoas se encantam”, diz ele, “e aí o senso crítico diminui.”

A psicologia cognitiva chama esse fenômeno de “ilusão de fluência”. Sempre que um conceito é explicado com extrema clareza, nosso cérebro confunde a facilidade de compreensão com a real capacidade de retenção. Como a IA é uma máquina altamente eficiente em explicar qualquer assunto, ela atua também como a maior geradora de falsas sensações de aprendizado dentro das equipes.

Além disso, perdemos os antigos marcadores de progresso. Enquanto nos estudos tradicionais o aluno sublinhava textos e construía resumos para mapear seu avanço, a interação com a IA se baseia no consumo fragmentado de respostas imediatas, que são rapidamente esquecidas. Para os gestores, a conclusão soa como um alerta importante. “Eu achava que o problema do aprendizado estava resolvido. Agora é muito mais difícil aprender”, constata.

Os erros mais comuns das empresas

A estratégia corporativa de simplesmente distribuir licenças de software e presumir a adoção natural costuma falhar por um motivo contraintuitivo: “Quanto mais informação, mais dificuldade as pessoas têm de navegar nesse mundo”, explica Morelli. Se antes o universo de uma apostila era restrito e seguro, a era da busca o tornou vasto. Com a IA generativa, esse ambiente passou a ser também conversacional e dotado de uma autoridade aparente. “Deixar as pessoas sozinhas nesse mundo não faz sentido. Elas não vão ter tempo, não vão ter experiência, não vão saber o que perguntar.”

Outro equívoco frequente envolve a arquitetura dos treinamentos. Formatos engessados que utilizam o mesmo material para milhares de pessoas, seguidos de provas de múltipla escolha e certificados de conclusão, apoiam-se na ideia de que o valor reside na transmissão do conteúdo. Contudo, em um cenário onde a informação é abundante, repassar teorias perdeu o sentido.

Consequentemente, as avaliações tradicionais já não provam a real absorção de habilidades aplicáveis. “O que isso prova?”, questiona Morelli. “Não prova muita coisa mas, como contraponto, ao conhecer muito mais os alunos, hoje temos a oportunidade da hipersegmentação, propondo materiais mais personalizados, que refletem dores reais do dia a dia”.

Ensinar a aprender tornou-se um requisito operacional

Já que o conteúdo bruto deixou de ser o produto final, o foco do ensino precisa se voltar para o método. Embora a ideia de “ensinar a aprender” não seja nova, ela deixou de ser apenas uma aspiração pedagógica para se transformar em uma exigência diária das corporações. Uma equipe incapaz de aprender com a inteligência artificial não fica apenas menos informada, mas torna-se perigosamente rápida em cometer e replicar erros.

Essa mudança de paradigma transforma o papel do educador, que deixa a posição de autoridade central para atuar como um facilitador. “Eu me vi não como um professor no papel de autoridade, mas como um facilitador”, relembra Morelli. A função passa a ser criar as condições ideais para que o profissional chegue à resposta correta por conta própria, visto que a entrega direta da informação já foi terceirizada. A IA não substituiu quem ensina, mas sim eliminou a etapa mecânica de transferência de dados.

A abordagem metodológica em três pilares

Para contornar esses obstáculos, o modelo educacional precisa se basear em decisões estruturais claras, fundamentadas na realidade de cada empresa. A Duranium Academy foi desenhada a partir dessa premissa, e ela se traduz em três decisões concretas.

1. Adeus à uniformização do público: “O padrão no ensino do século XX era achar que você podia unificar a forma como as pessoas aprendem.” A capacitação moderna exige um mapeamento prévio das dores reais de cada participante. As dificuldades de um advogado diferem das enfrentadas por um desenvolvedor de software, e a própria IA pode ser usada para baratear e acelerar a customização dos materiais para cada setor.

2. O problema antes da teoria: O aprendizado se consolida quando o participante resolve uma tarefa legítima do seu cotidiano, em vez de lidar com exercícios genéricos. “Quando você aprende e vê a aplicação prática, o conceito entra junto.” Essa aplicação direta é a defesa mais robusta contra a ilusão de fluência, pois obriga o profissional a enfrentar a dificuldade que as respostas prontas suprimem.

3. Avaliação por evidência: O foco nos certificados deve ser substituído pela comprovação de ganho de eficiência real. “A prova que a pessoa vai fazer é o dia a dia dela.” Se antes um colaborador gastava horas analisando contratos e passa a concluir a tarefa em minutos, esse ganho prático carrega muito mais peso do que uma nota alta em um teste teórico.

Os 4Ds: um método transferível e atemporal

Enquanto conteúdos técnicos envelhecem rapidamente, os hábitos mentais permanecem. É com essa visão que se destaca o framework dos 4Ds - desenvolvido pelos pesquisadores Prof. Rick Dakan (Ringling College of Art and Design) e Prof. Joseph Feller (University College Cork) em parceria com a Anthropic e adotado pela Duranium Academy - focado em nortear as decisões de trabalho com IA em quatro etapas práticas:

• Delegação: Avaliar criticamente o que deve ou não ser repassado para a máquina. Delegar tarefas em excesso atrofia a capacidade intelectual da equipe. O alerta é direto: “Se você passa tudo, seu cérebro vai ficar pequenininho.”

• Descrição: Estruturar criteriosamente o pedido para minimizar invenções da inteligência artificial. Ao definir papéis, resultados esperados e restrições com antecedência, o usuário transforma impulsos preguiçosos em comandos precisos, economizando tempo na conferência do resultado.

• Discernimento: Partir do princípio de que nem toda informação gerada estará correta. Textos bem articulados podem esconder referências inexistentes ou fatos fabricados, exigindo do usuário uma verificação constante.

• Diligência: Assumir a responsabilidade final pela entrega. “Não faz sentido culpar a ferramenta pelo trabalho que você pediu para ela fazer.” Assim como no trânsito, a responsabilidade é sempre de quem conduz a máquina.

Esses quatro princípios não são focados em plataformas específicas, mas sim no julgamento crítico humano, garantindo que a metodologia se mantenha válida para as futuras versões da tecnologia.

Os desafios de gestão e a necessidade de governança

O problema que permanece em aberto diz respeito inteiramente à gestão. Assim como existe uma ilusão de aprendizado individual, as empresas sofrem de uma ilusão organizacional ao acreditarem que uma equipe está capacitada apenas porque utiliza as novas ferramentas.

A inteligência artificial atua como um amplificador de comportamentos; sem o devido direcionamento, o grupo pode começar a produzir mais rápido, porém entregando trabalhos falhos sem que ninguém perceba.

Resolver essa questão exige métricas precisas. “Se você não medir de forma precisa o quanto essas pessoas melhoraram no dia a dia, as pessoas vão continuar perdidas.” Enquanto as formações forem tratadas como eventos isolados, e não como um acompanhamento contínuo, as companhias continuarão sem conseguir calcular o retorno real dos investimentos.

Descobrir se uma equipe domina a tecnologia ou apenas repassa obrigações indiscriminadamente exige mais do que treinamentos pontuais. “A governança é o grande guarda-chuva”, resume Morelli. “Se não tem governança, não tem futuro.”

A Duranium Academy desenvolve treinamentos em inteligência artificial focados nas necessidades reais das equipes, baseando-se em avaliações por evidências de resultados práticos. Se você é gestor responsável por capacitação e reconhece esses desafios no seu time, fale conosco.

Este artigo deriva do webinar “A ilusão do aprendizado na era da IA”, com Eduardo Morelli. A gravação completa está disponível no canal da Duranium no YouTube. Assista aqui.

Compartilhar

Existe uma pergunta de suma importância em uma reunião de orçamento: quanto a instituição perde com fraude?

A resposta habitual é um número. O que raramente acompanha esse número é a metodologia que o produziu — quais categorias de perda foram incluídas, quais foram para outra conta, e com base em que critério a separação foi feita. E é aí que mora um problema que não é de tecnologia nem de detecção: é de classificação.

Porque uma parte relevante da perda por fraude pode não estar necessariamente registrada como fraude.

Uma taxonomia mínima

Antes de qualquer coisa, é útil separar as categorias de fraude que a conversa cotidiana costuma juntar:

Fraude de terceira parte. Alguém usa a identidade ou a credencial de outra pessoa. É o caso canônico, o mais estudado e aquele para o qual existe mais controle maduro.

Fraude de segunda parte. O titular cede a conta a um terceiro, por pagamento ou por coerção. É o território das contas laranja, onde o problema é a logística de recebimento e a análise de rede.

Fraude interna. Praticada por quem tem acesso legítimo, com credencial própria.

Fraude de primeira parte. O titular é o próprio autor. Ele contrata em nome próprio, com dados verdadeiros, sem intenção de honrar o compromisso. No Brasil, o termo mais usado é autofraude.

Essa última categoria tem duas subcategorias reconhecíveis.

Uma delas, a inadimplência programada — o que o mercado internacional chama de bust-out — descreve quem constrói histórico com compras pequenas e pagamentos pontuais, aguarda o aumento de limite e desaparece no momento em que a exposição fica interessante. Há também a contestação indevida de transação legítima e a exploração sistemática de programas de benefício. O que une essas condutas é que, em nenhuma delas, existe um terceiro para culpar.

Por que a autofraude se disfarça de inadimplência

Um modelo de crédito é construído para responder a duas perguntas: este cliente pode pagar? e qual a probabilidade de ele atrasar ao longo do tempo? São perguntas boas, com décadas de refinamento estatístico por trás. Nenhuma delas é a pergunta relevante para autofraude, que é: este cliente pretendia pagar?

Capacidade e intenção são coisas diferentes, e o modelo de crédito só observa a primeira. Quando uma perda acontece, o que chega ao sistema como possíveis causas é: contrato não honrado, valor a provisionar, baixa contábil. Sem um critério que separe efetivamente “causa” de “intenção”, a perda vai para a conta que já existe — risco de crédito.

Segundo análises da Experian existe um sinal que ajuda a fazer essa distinção: o comportamento no início do ciclo de vida. Um tomador legítimo sob dificuldade financeira tende a atrasar mais tarde, com períodos de recuperação e recaída — o perfil de quem está lutando para pagar.

Já o padrão associado à autofraude é a inadimplência precoce sem recuperação: a conta entra em atraso severo nos primeiros meses e nunca volta. A Experian usa o first-payment default (inadimplência 90+ dias em até seis meses da contratação) como indicador principal desse recorte. A mesma análise aponta que, nos EUA, as baixas ocorridas nos primeiros seis meses após a abertura são materialmente mais altas do que as ocorridas depois de doze meses.

Não há estimativa pública equivalente para o Brasil, sobre a proporção da perda de crédito que corresponde à autofraude. A referência nacional existente é de outra natureza — a Serasa Experian apurou cerca de 3,5 milhões de tentativas de fraude no primeiro trimestre de 2025, alta de 22,9% sobre o mesmo período do ano anterior, com bancos e cartões concentrando 54% do total. São tentativas registradas, não perdas classificadas por categoria: os dois indicadores medem coisas diferentes e não são comparáveis entre si.

Vale dizer com clareza: a maior parte da inadimplência não é fraude. Gente que perdeu emprego, adoeceu, calculou errado, foi atropelada pela vida. O argumento deste texto não é que devedores são fraudadores. É que dentro de um agregado grande existe um subconjunto com natureza distinta, e que tratar tudo como uma coisa só produz decisões erradas nas duas direções.

O efeito imediato: um número torto nas duas pontas

Quando a autofraude é lançada como perda de crédito, acontecem duas distorções simultâneas e de sinais opostos.

A perda de crédito fica superestimada. A carteira parece pior do que é, a provisão é calibrada para um risco de pagamento que não é o risco real, e a leitura de performance do produto fica prejudicada.

No entanto, a exposição à fraude fica subestimada. E como orçamento de prevenção se justifica com número de perda, a área que deveria endereçar o problema recebe menos investimento precisamente porque o problema está sendo contabilizado em outro lugar. É um ciclo que se sustenta sozinho: sem número, não há verba; sem verba, não há capacidade de produzir o número.

É o vazamento contabilizado como consumo: a conta de água fecha todo mês, o valor não chama atenção de ninguém, e o cano continua vazando porque na planilha aquilo não é vazamento, é gente tomando banho.

O efeito que ninguém vê: o rótulo volta para o onboarding

Modelo aprende com rótulo. O modelo que decide a abertura de conta e a concessão inicial de crédito é treinado com o histórico de como as contas anteriores se comportaram, e o rótulo que ele recebe é aquele que a contabilidade atribuiu. Se a autofraude foi registrada como inadimplência, o modelo de onboarding aprende que aquele caso foi um problema de capacidade de pagamento.

E o modelo vai ficar cada vez melhor em identificar quem tem dificuldade de pagar, e não vai desenvolver nenhuma sensibilidade à intenção — porque nunca recebeu exemplo rotulado como tal. O erro de classificação na baixa contábil não fica na contabilidade: ele sobe para a decisão de entrada e se reproduz em cada nova conta aberta.

Pior: como os dados sugerem que a autofraude tende a se apresentar com perfil de risco aparente bom, um modelo calibrado apenas em capacidade de pagamento aprova esses casos com folga. Ele não está falhando por imprecisão. Está acertando a pergunta errada com precisão crescente.

Isso reposiciona o cuidado no onboarding. A discussão sobre abertura de conta no Brasil tem se concentrado, com razão, em verificação de identidade — se a pessoa é quem diz ser, se o documento é autêntico, se o rosto na câmera é real. É um trabalho necessário, mas é insuficiente para caracterizar autofraude. Nela, a identidade é verdadeira, o documento é autêntico, a pessoa é quem diz ser. Nenhum controle de identidade é acionado, porque não há nada de falso a detectar.

O que sobra como sinal, no momento da entrada, é de outra natureza: comportamento durante o preenchimento da solicitação, características do dispositivo e do ambiente, coerência entre o que foi declarado e o que é observável, velocidade de contratação em múltiplas instituições no mesmo período. É informação que existe no momento do onboarding e que raramente é retida com a granularidade necessária porque, no desenho tradicional, o onboarding termina quando a conta é aberta.

Se a intenção é a variável que interessa, o onboarding deixa de ser um portão e passa a ser o primeiro ponto de uma série. E a série só tem valor analítico se o desfecho, meses depois, voltar com o rótulo correto.

O ponto cego é organizacional antes de ser técnico

Nada disso é difícil de entender. A pergunta é por que persiste — e a resposta não está na tecnologia.

O time de prevenção à fraude olha para ataque de terceiro: alguém de fora usando dados de outra pessoa. O time de risco de crédito olha para capacidade de pagamento: quem consegue honrar o compromisso. A autofraude cai exatamente na fenda entre os dois times. Não é ataque externo, então não é do primeiro. Não é incapacidade de pagar, então não deveria ser do segundo.

Quando nenhuma área é dona de uma categoria de perda, o número referente a ela não existe. Não por incompetência, mas por desenho.

E isso torna a saída mais institucional do que analítica. Uma taxonomia de perda declarada, com definição escrita do que entra em cada categoria. Um dono nomeado, com autoridade que atravesse fraude, crédito, produto e cobrança — porque um problema que vive na fenda não pode ser resolvido de dentro de um dos lados. Um critério de reclassificação com trilha, para que a mudança de rótulo seja auditável e não pareça manobra contábil. E o alinhamento de incentivo: enquanto a área de crédito for avaliada por um indicador que a autofraude infla e a área de fraude por outro que ela não toca, nenhuma das duas tem motivo para financiar a separação.

Para o conselho, a exigência correspondente também é modesta e desconfortável: não o número absoluto, que é fácil de produzir e difícil de interpretar, mas a tendência por categoria com a metodologia de classificação explícita. Um número de perda por fraude sem metodologia declarada não é informação — é um valor com aparência de informação.

Não existe controle capaz de endereçar uma categoria de perda que a organização não nomeia. E nenhum modelo de entrada vai aprender a reconhecer a intenção enquanto o desfecho voltar dela com o rótulo trocado.

A Duranium atua em prevenção à fraude e identidade digital no mercado financeiro brasileiro. Se este é um problema na sua operação, vamos conversar.

Compartilhar

Fontes:

• Experian Insights, How First-Party Fraud is Hiding in Banks’ Credit Losses (fev/2026) e material relacionado — mecanismo de misclassificação, distinção entre capacidade e intenção, FPD como indicador (90+ dias em até seis meses), perfil de atraso do tomador legítimo (atraso tardio com recuperação e recaída) vs. autofraude (atraso precoce sem recuperação). https://www.experian.com/blogs/insights/how-first-party-fraud-is-hiding-in-banks-credit-losses/

• Análise Experian via MeridianLink (abr/2026) — baixas nos primeiros seis meses superiores às posteriores a doze meses; concentração em segmentos de melhor risco aparente. https://www.meridianlink.com/blog/fraud-or-financial-distress-revealing-credit-unions-clearest-lens-on-intent/

• Serasa Experian — 3,5 milhões de tentativas de fraude no 1º trimestre de 2025, alta de 22,9%, bancos e cartões com 54%. Via Open Hub News / E-Commerce Brasil, artigo sobre autofraude. https://openhubnews.com/bn-autofraude-o-inimigo-invisivel-que-as-empresas-insistem-em-ignorar/

• Adyen — terminologia em português das tipologias (inadimplência programada, contestação indevida, exploração de benefícios). https://www.adyen.com/pt_BR/centro-de-conhecimento/autofraude-transacao-legitima-suspeita

Quase toda a conversa sobre prevenção à fraude no Brasil acontece do lado de quem paga. O investimento se concentra no momento da transação: o score, a regra, o sinal de comportamento, a decisão de aprovar ou barrar em milissegundos. É um trabalho legítimo e difícil, e é onde a indústria acumulou mais competência.

Mas existe uma restrição que nenhum fraudador consegue contornar: o dinheiro precisa ir para algum lugar. Não existe transação financeira que termine no clique da vítima. Ele termina numa conta que recebe, e depois em outra, e em outra, até que o rastro fique caro o suficiente de seguir. Essa camada — a logística do recebimento — é onde o criminoso tem o gargalo mais real da operação. E é, historicamente, onde a análise chega por último.

A fraude não acaba no clique da vítima

Um estudo da Quod, empresa de inteligência de dados, produzido a pedido da EXAME e publicado em junho de 2026, mapeou o mercado de contas laranja no Brasil. Em 2025, foram abertas 995.744 contas laranja — média de 2,7 mil por dia, crescimento de 11,3% sobre 2024.

O número por si só já é grande. Mas o dado mais revelador do estudo é outro: essas quase um milhão de contas foram abertas a partir de 686.737 CPFs. Ou seja, em média, cada CPF gerou 1,4 conta.

Pare nesse número por um instante. Ele não descreve um comportamento individual. Ele descreve um processo com escala, repetição e reaproveitamento de insumo — porque é exatamente assim que um CPF é tratado nesse mercado: como insumo. Um documento não vale por si; vale pela quantidade de contas que consegue abrir antes de queimar.

Isso não é um agregado de incidentes isolados. É uma cadeia de suprimentos.

A conta laranja é infraestrutura, não incidente

A palavra que a Federação Brasileira de Bancos usou, em nota à EXAME, é precisa: escoamento. O crime só acontece porque existe a possibilidade de escoar o dinheiro, e a conta laranja é o que viabiliza esse escoamento.

Vale entender por que ela é tão eficiente nesse papel.

Velocidade e pulverização. Segundo a Visa, o padrão observado é que os recursos saem rapidamente da conta que recebeu primeiro e se distribuem entre dez ou doze contas, até que a rastreabilidade do valor se perca. Não é uma transferência; é uma dispersão deliberada, desenhada para que cada fragmento fique abaixo do limiar de atenção de qualquer sistema que olhe transações isoladamente.

Multiplicidade de instituições. A conta laranja não é um problema de uma instituição — é um problema entre instituições. O criminoso distribui justamente porque cada instituição só vê o seu pedaço do fluxo. A assimetria de informação é o ativo dele.

Aliciamento com preço definido. O estudo da Quod descreve a abordagem direta: o criminoso alicia alguém e oferece um valor por conta aberta em cada banco. Existe também o mercado de aluguel de contas já existentes, com grupos abertos em redes sociais organizando oferta e demanda. Quando o insumo tem preço de tabela, deixou de ser desvio e passou a ser operação.

Extensão para pessoa jurídica. A Visa relata a criação de estabelecimentos comerciais fictícios credenciados em empresas de meios de pagamento para processar transações fraudulentas — abertos, muitas vezes, com documentos de terceiros sem histórico de fraude. O Ministério Público de São Paulo tem chamado atenção para o mesmo fenômeno: além de contas laranja, pessoas jurídicas laranja. Empresas de fachada sem objeto, sem serviço, sem produto.

Uma observação necessária antes de seguir: quem cede a conta não é uma categoria homogênea. Pode ser um participante remunerado. Pode ser alguém que teve dados vazados e viu contas serem abertas em seu nome — o que a reportagem da EXAME chama de laranjas inconscientes -, e pode, inclusive, ser alguém agindo sob coerção.

Nos três casos, a conta produz o mesmo padrão nos dados: recebe, dispersa, repete. O que muda é a responsabilidade de quem está por trás dela — e essa diferença não aparece em nenhum sinal técnico. É por isso que decidir sobre uma conta é mais difícil do que detectá-la.

O padrão só aparece em rede

Aqui está o limite estrutural de qualquer análise que tome a transação como unidade.

Uma transferência de mil reais entre duas contas legítimas, num horário comum, com valor comum, é indistinguível de milhares de outras. Ela não tem nada de anômalo — e de fato não é anômala, isoladamente. O que a torna significativa é o que está em volta dela: a conta de destino foi aberta há três semanas, com um CPF que abriu outras duas contas no mesmo período em instituições diferentes, e recebeu, nas últimas quarenta e oito horas, valores fracionados de sete origens sem relação entre si, que saíram em menos de uma hora para outras contas igualmente novas.

Nenhuma dessas transações, sozinha, justifica bloqueio. O conjunto, sim.

Diante disso, a resposta institucional prioriza a cooperação em vez de controles isolados. Um exemplo é a Operação Tentáculos da Polícia Federal, que integra bancos e fintechs em um repositório compartilhado para cruzar fraudes distantes e focar nas organizações criminosas. Segundo a PF, o repositório já reúne reportes de R$ 6 bilhões em fraudes eletrônicas.

As Resoluções CMN nº 5.261 e BCB nº 518, de 03/11/2025, determinam o encerramento compulsório de contas com indício de uso irregular, incluindo as contas-bolsão, que movimentam recursos de terceiros sob um único titular. Em paralelo, o Normativo SARB nº 28/2025 da FEBRABAN, em vigor desde 27/10/2025, trata especificamente das contas de passagem, com diretrizes de identificação, monitoramento, bloqueio e encerramento Além disso, o MED 2.0 aumentou a rastreabilidade dos recursos além do primeiro nível de recebimento.

Todos esses movimentos apontam para a mesma direção: a unidade de análise relevante deixou de ser a transação e passou a ser a rede.

Da transação para a rede: o que essa mudança exige

A conclusão prática deste texto não é uma recomendação de ferramenta. É uma mudança de pergunta — e, por trás dela, quatro mudanças bem mais difíceis.

A pergunta que orientou duas décadas de investimento em antifraude foi: esta transação é suspeita? É uma boa pergunta, respondível em milissegundos, e continua necessária. Mas ela é insuficiente para o problema descrito acima, porque a fraude que usa conta laranja foi desenhada exatamente para que nenhuma transação individual pareça suspeita. Cada fragmento é construído para passar. Perguntar melhor sobre o fragmento não resolve um problema que existe na composição.

A pergunta que produz resposta é outra: esta conta pertence a uma rede?

Enunciada assim, a troca parece simples. Não é. Ela reorganiza quatro coisas.

Muda o que se observa — e o horizonte de tempo. A análise transacional opera numa fotografia: os atributos disponíveis no instante da decisão. A análise de rede opera numa sequência. O que interessa passa a ser como a conta foi aberta, com que documento, em que velocidade acumulou vínculos, que padrão de entrada e saída sustenta ao longo de semanas, e com quais outras contas compartilha características que não deveriam ser compartilhadas. Nenhum desses sinais existe no instante. Eles só existem na série. Isso significa manter e correlacionar histórico de conta com uma disciplina que a decisão em milissegundos nunca exigiu — e são dois relógios diferentes rodando ao mesmo tempo, não um substituindo o outro.

Muda o dado necessário — e transforma cooperação em requisito técnico. Aqui está a parte incômoda. Parte do sinal que caracteriza uma rede não está dentro de nenhuma instituição isoladamente, por definição: a rede é distribuída porque distribuir funciona. Uma instituição sozinha vê contas novas com comportamento estranho; ela não vê que o mesmo documento abriu contas em outras quatro no mesmo mês. Isso muda o status da cooperação interinstitucional. Ela deixa de ser gesto de boa vontade setorial, ou obrigação de conformidade a ser cumprida no mínimo necessário, e passa a ser insumo do modelo — dentro dos limites da LGPD e dos canais formais de compartilhamento já previstos na regulação e na autorregulação.. Quem trata compartilhamento como custo regulatório está subfinanciando a própria capacidade de detecção.

Muda a natureza da decisão — e o seu custo de erro. Bloquear uma transação é um atrito: o cliente tenta de novo, liga, reclama, resolve. Restringir o acesso de uma pessoa ao sistema financeiro é outra ordem de dano — e o estudo da Quod mostra que o perfil predominante de quem aparece como laranja está concentrado nas faixas de menor renda, exatamente a população para quem perder acesso a conta tem consequência material mais severa. Some isso ao ponto levantado antes: o mesmo sinal técnico pode corresponder a um participante remunerado, a uma vítima de vazamento ou a uma pessoa sob coerção. A conclusão é que decisão de nível conta não pode ser binária como decisão de nível transação. Ela pede resposta graduada, contexto anexado à decisão e caminho de contestação real — não como cortesia de atendimento, mas como parte do controle. Um antifraude que não distingue esses casos não está sendo rigoroso, está sendo impreciso.

Muda quem responde. Decisão transacional cabe num sistema. Decisão sobre conta atravessa antifraude, compliance, jurídico, atendimento e produto — e, quando o insumo vem de fora, atravessa também a fronteira da instituição. Sem dono definido e sem critério auditável de por que uma conta foi marcada, o que se produz não é capacidade de detecção: é uma fila de exceções que ninguém consegue explicar seis meses depois, para o cliente ou para o regulador.

Nada disso substitui o controle transacional. Ele responde, em milissegundos, se aquele pagamento deve passar; a análise de conta responde, ao longo de semanas, se aquela conta faz parte de uma rede. Uma opera no instante e por isso não enxerga a série; a outra opera na série e por isso não chega a tempo do instante. O ponto é que a segunda pergunta esteve ausente do desenho por tempo suficiente para que a fraude se organizasse justamente onde ela não era feita.

O dinheiro tem que ir para algum lugar. É a única parte da operação criminosa que não pode ser eliminada — e, por isso mesmo, o lugar mais promissor para olhar.

A Duranium atua em prevenção à fraude e identidade digital no mercado financeiro brasileiro. Se este é um problema na sua operação, entre em contato e agende uma conversa com um especialista.

Toda operação de antifraude convive com uma incerteza que raramente é dita em voz alta: ela não sabe, com rigor, o quanto a própria defesa falha. O que foi bloqueado fica claro nos painéis. O problema é o restante, que se divide em três frentes operacionais:

Falhas de detecção: O motor de decisão (composto pelas regras, listas e modelos que avaliam todo o volume) deixa passar o que não reconhece. Esse gargalo só aparece quando o prejuízo bate no fechamento do mês.

Inconsistência da revisão humana: A fração de transações que vaza para análise manual carrega um custo crescente. A mesa decide caso a caso, sem que o valor por decisão apareça detalhado nos relatórios, o que em si já é um outro gargalo. Neste caso, escalar para reduzir o tempo de decisão requer investimentos altos. E mesmo que se escale, manter um padrão na tomada de decisões nas análises é algo difícil

Falsos positivos: O bloqueio indevido de clientes legítimos gera churn e reclamações, ocorrendo longe das métricas usuais de fraude.

No fim do mês, o balanço mostra que a empresa perdeu um valor X, mas não detalha a origem do estrago. Fica impossível saber quanto desse montante era evitável, quanto veio de regras defasadas, quanto dependia de sinais ignorados pelos sistemas e quanto se pagou em atrito para conter o resto.

Sem dados claros, o dia a dia acaba guiado pela intuição, com base na bagagem acumulada dos profissionais mais experientes do time. E embora esse repertório seja valioso, ele não substitui uma medição real. É exatamente neste ponto cego entre intuição e dados que a fraude continua passando mês a mês, disfarçada de custo inevitável.

Por que a operação não consegue se medir sozinha

Isso acontece por conta de uma limitação estrutural da própria operação, e não por negligência. Medir a eficiência da defesa exige compará-la com uma alternativa aplicada às mesmas transações. Sozinha, a operação não possui essa base comparativa. Como o motor em produção toma as decisões sozinho, falta um segundo julgamento sobre o mesmo fluxo para expor o que teria sido diferente. A régua atual acaba sendo a fonte da dúvida e, ao mesmo tempo, a única ferramenta de análise disponível (e nenhum instrumento consegue medir a si mesmo).

Auditorias e revisões de regras trazem benefícios, mas respondem a uma questão diferente. Elas confirmam se a estrutura funciona exatamente como foi desenhada, mas não garantem que o desenho atual continue aderente às táticas recentes de fraude. Como o crime organizado se adapta rapidamente, descobrir uma falha através do prejuízo financeiro significa que o custo da descoberta já foi pago. Quem enxerga o negócio apenas pelos próprios painéis descobre as brechas quase sempre do jeito mais caro.

Há ainda uma pressão vinda do regulador. A Circular BCB nº 3.978/2020 não pede apenas que a instituição tenha controles de prevenção à lavagem de dinheiro: pede que avalie a efetividade deles de forma periódica e auditável. A mesma lógica vale para as comunicações ao COAF, cuja qualidade depende diretamente da detecção que as origina — quem não sabe o que deixou passar não tem como sustentar que comunica o que deveria. Na prática, a diferença entre acreditar que a defesa funciona e demonstrar onde ela falha deixou de ser um detalhe de maturidade operacional para virar uma exigência de conformidade. Em breve, a provocação que abre este artigo virará uma cobrança formal de auditoria, com prazo rígido para resposta.

O piloto não testa o fornecedor. Testa você.

Ao avaliar uma nova solução antifraude, o mercado costuma enquadrar o piloto como um teste do produto: ele funciona, aguenta o volume e integra bem? Essas perguntas são válidas, mas passam longe de ser as mais valiosas nessa etapa.

O piloto representa a oportunidade real de obter um segundo julgamento sobre as transações da empresa. É uma defesa alternativa rodando em modo shadow (sem impacto na produção ou bloqueio de usuários) sobre o mesmo histórico, confrontada com um gabarito verificável: as fraudes confirmadas e as transações legítimas conhecidas. Pela primeira vez, há uma base direta de comparação. O custo real das falhas operacionais finalmente ganha números concretos.

Em suma, um piloto bem estruturado serve para mostrar onde a operação está falhando, em vez de focar só em validar as qualidades do fornecedor. O software atua como o instrumento de medição, e não como o objeto final da análise. Essa mudança de foco altera o impacto do teste: eventuais erros no desenho não significam apenas um atraso na contratação, mas a continuidade de uma cegueira custosa sobre os golpes.

O que um piloto mal desenhado esconde de você

Existem quatro falhas recorrentes no desenho de testes que eliminam a visibilidade do processo:

Testes sem gabarito: A medição precisa de rótulos confirmados (fraude ou transação legítima, validados pela equipe) sobre a base analisada. Sem isso, a prova vira uma demonstração qualitativa cheia de casos isolados e nenhuma evidência sólida. A operação sai do teste com as mesmas impressões do início, só que confortada por uma apresentação bonita.

Falta de linha de base: Para entender o real valor dos alertas gerados, é necessário comparar o resultado com a defesa atual no mesmo período. Isso exige documentar a régua vigente, detalhando verificações, pesos e notas de corte. Muitas equipes percebem nessa etapa um fenômeno curioso: parte importante da defesa atual só existe na cabeça de algum analista sênior, sem documentação alguma.

Foco no problema errado: Um teste pode ser metodologicamente rigoroso e, ainda assim, irrelevante. Medir a taxa de acerto em um processo afetado por alta latência (onde o dinheiro já saiu quando o alerta dispara) produz métricas corretas para o problema errado. O desenho precisa focar no gargalo mais crítico, seja a falta de detecção do motor, o custo das revisões manuais ou o atrito exagerado com clientes bons.

Escopo restrito às dores do time: Quando os resultados do teste respondem a uma pergunta que só a equipe técnica se faz, o desfecho no comitê de orçamento é conhecido: o número não perde por ser falso — perde por não ter sido traduzido para o CFO. Quase toda dor operacional tem uma versão que a diretoria reconhece, apenas esperando ser nomeada: fila de tickets de TI para ativar uma regra nova não é um incômodo do time, é tempo de resposta a golpe, que é janela de perda aberta, que é resultado no fechamento. Isso é traduzir o problema para a linguagem de receita ou risco regulatório. Por isso a pergunta do piloto precisa nascer já traduzida. E o pior desfecho não é o piloto reprovado: é o aprovado e ignorado, com o sangramento seguindo por baixo de um “testamos e não valia a pena”.

A exigência que separa teste de teatro

Ao corrigir esses quatro pontos, surge uma régua clara para avaliar qualquer parceiro de tecnologia: exigência de rótulos confirmados, linha de base documentada, execução em modo shadow e comparação direta com o fluxo atual (em vez de benchmarks genéricos que nada provam).

Essa metodologia é reveladora justamente porque muda o que está em jogo na conversa comercial. Um teste com gabarito, linha de base e execução em modo shadow produz um resultado que pode ser desfavorável ao fornecedor — e isso é uma característica do método, não um defeito. Vale observar como cada parceiro reage à proposta: há soluções desenhadas para operar sob esse tipo de escrutínio e há soluções que só se sustentam em demonstrações controladas, e a diferença raramente aparece no material comercial. Apresente as quatro exigências na próxima reunião e observe o que acontece com o nível de detalhe da resposta. A disposição de ser medido nas condições reais da sua operação é um sinal de maturidade técnica que nenhuma apresentação consegue substituir.

Além disso, o processo traz um ganho interno relevante. Mesmo que nenhum contrato seja assinado no final, um piloto conduzido dessa forma entrega o mapeamento detalhado das perdas operacionais, mostrando onde a defesa atual falha e quanto isso custa. É um conhecimento que permanece na empresa.

Medir uma vez ou medir sempre

Chega-se então ao ponto que define a evolução da empresa. Se a medição fosse possível apenas em pilotos ocasionais, a recomendação seria testar novas ferramentas constantemente. A solução real passa por adaptar a arquitetura para que o piloto seja o primeiro passo de uma medição contínua.

Uma estrutura moderna de proteção integra a capacidade de medição de forma permanente. Regras novas podem nascer em modo shadow contra o histórico antes de irem para produção, assim como o desalinhamento dos modelos frente a novos golpes pode ser detectado em tempo real, em vez de aparecer no fechamento contábil. Trata-se de um padrão viável para qualquer empresa que precisa acompanhar um cenário de fraude dinâmico (além de atender às exigências contínuas da regulação).

Sob essa ótica, o piloto serve tanto para expor falhas pontuais quanto para aprovar se a solução contratada consegue manter esse nível de transparência no dia a dia.

A medição está a semanas de distância

A primeira medição real exige um teste de poucas semanas, rodando em paralelo à operação normal e sem impactar nenhuma transação. O processo utiliza dados que a empresa já possui (como o histórico, os rótulos confirmados e a régua vigente), demandando apenas a postura de exigi-lo.

É exatamente esse tipo de medição que a Plataforma FraudGate foi desenhada para viabilizar: execução em modo shadow sobre o histórico da instituição, comparação direta com a régua vigente e resultado apresentado contra rótulos confirmados. Se a sua operação já tem o histórico, os rótulos e a régua documentada, o material para a primeira medição já existe. O que falta é desenhar o escopo: qual gargalo medir primeiro e qual pergunta a diretoria precisa ver respondida no final. Essa é uma conversa técnica de uma hora, sem compromisso de contratação.

Agendar conversa técnica

Um Engineering Manager abre três painéis para responder a uma pergunta que o board fez de manhã: o quanto a IA está ajudando o time. O primeiro dá um número. O segundo dá outro. O terceiro não bate com nenhum dos dois. Os três dizem medir “uso de IA”, e cada um definiu isso à sua maneira. No fim do dia, a resposta que sobe é honesta no tom e frágil no dado: a gente sente que está ajudando.

Fomos atrás dessa cena conversando com líderes de engenharia, para ouvir onde a medição dói de verdade. Um padrão se repetiu, mesmo entre empresas de contextos bem diferentes: quando os números de ferramentas diferentes não batem, a primeira coisa que se perde é a confiança em qualquer um deles.

Por que essa conta ficou urgente agora

Usar IA para escrever código deixou de ser novidade. Um levantamento da Pragmatic Engineer de 2025 aponta que 85% dos desenvolvedores já usam essas ferramentas no trabalho. A adoção já é grande. O que mudou foi o preço da pergunta seguinte. Token custa, licença custa, e o orçamento de IA virou linha que alguém acima do EM quer ver justificada. Quando o custo aparece, “a gente acha que ajuda” para de ser resposta suficiente.

E essa dificuldade não é de um time só. Num levantamento da LeadDev feito com a DX, ouvindo mais de 880 líderes de engenharia, a falta de métricas claras aparece entre os maiores desafios de quem adota IA. O EM que trava na hora de justificar está diante de um problema estrutural, não de um lapso pessoal.

Medir IA é novo para o setor inteiro, inclusive para as ferramentas

Duas camadas costumam cair no mesmo balde. Vale separá-las.

Nas métricas clássicas de engenharia (fluxo de entrega, tempo de ciclo, cobertura de teste, change failure rate), o mercado ao menos concorda sobre o que medir. Existe uma linhagem de mais de uma década, de DORA a SPACE, e ferramentas construídas em cima disso. Dá para discutir o número, mas a definição é compartilhada, e é ela que deixa o número comparável de um mês para o outro.

Na camada de IA, não existe nem esse consenso. Falta acordo sobre o que conta como “uso de IA”, “produtividade com IA” ou “qualidade do que a IA escreveu”. E isso não é só percepção de campo. Ao mapear como 18 grandes empresas de tecnologia medem o impacto da IA, a DX encontrou empresas parecidas, do porte de Microsoft e Google, medindo coisas diferentes, sem uma prática única que sirva de referência. Se quem tem times enormes e orçamento de sobra ainda está experimentando, o EM de um time menor não está atrasado. O terreno é novo para o setor inteiro ao mesmo tempo.

Some a isso um agravante herdado: medir produtividade de engenharia já era um problema não resolvido antes da IA. O setor discute isso há mais de uma década sem chegar a uma métrica única e confiável, e a IA chegou sobre um terreno que já estava instável.

O que essas métricas estão contando

Se a definição não é compartilhada, cada ferramenta preenche a lacuna do seu jeito. E aqui aparece a parte que os líderes menos gostam de admitir: o número que você recebe é o número que o fornecedor consegue medir. Um líder do Monzo colocou isso de forma direta ao Pragmatic Engineer, dizendo que o fornecedor mede o que dá, e é esse o número que chega até você.

O que quase todas essas ferramentas conseguem medir é a mesma coisa: o anel em volta do código. Uso da ferramenta, sugestões aceitas, sessões, tokens, teclada. Sinais de atividade, capturados da telemetria do editor ou do plugin. São baratos de instrumentar e, por isso mesmo, cada um recorta do seu jeito, o que explica por que a mesma métrica sai com valores distintos conforme a origem. Enquanto a conta olhar a atividade, ela vai continuar sem convergir, porque atividade é justamente a parte que cada fornecedor define como quiser.

E atividade responde à pergunta errada. O board não pergunta o quanto a IA foi usada. Pergunta o que ela deixou no produto. Esse sinal está num lugar diferente do anel de telemetria: está no que o time de fato entregou e com que qualidade, no código que foi mergeado e ficou de pé. Um artefato é mais difícil de recortar do que uma métrica de uso: ele é aquilo que ficou pronto.

Há ainda o reflexo mais antigo do mercado: na falta de uma definição boa, corre-se para a métrica fácil. Foi assim que a indústria voltou a se fixar em linhas de código e em “percentual de código escrito por IA”, números que rendem boa manchete e quase nada de leitura sobre qualidade ou resultado. “Percentual de código escrito por IA” é o retrato acabado disso: conta o volume que a IA gerou, sem uma palavra sobre se aquilo prestava.

A armadilha da taxa de aceitação

A taxa de aceitação de sugestões é o exemplo mais puro de contar o anel, e por isso vem perdendo espaço. Laura Tacho, CTO da DX, resume a armadilha numa pergunta: estamos confundindo atividade de IA com impacto de IA? A aceitação olha o instante em que a sugestão aparece e ignora o que vem depois: se o código se manteve, se foi revertido, se introduziu um bug. Ela registra que a IA foi usada. O que a IA deixou no fim fica de fora. Um número que sobe sem dizer se as coisas melhoraram não sustenta decisão, por mais preciso que pareça na tela.

O feeling não fecha a conta

Se o dado das ferramentas é frágil, a saída natural do EM é confiar na percepção do time. Aqui mora a última armadilha. Num experimento controlado do METR, no começo de 2025, desenvolvedores experientes trabalharam em repositórios que conheciam bem, metade das tarefas com IA liberada, metade sem. Eles se sentiram cerca de 20% mais rápidos usando IA. Na medição, levaram cerca de 19% mais tempo. O próprio METR trata o resultado como o retrato de um momento específico e já publicou números mais novos depois. O que interessa aqui é o descompasso, não a direção do efeito: a percepção, mesmo de quem está com a mão no código, é um instrumento pouco confiável para dizer se a IA está ajudando.

Painel e feeling falham pela mesma razão. Os dois olham a atividade: o painel pela telemetria, o feeling pela impressão de quem trabalhou. Nenhum dos dois olha o resultado que ficou. Medir mal não empurra para largar a medição. Empurra para mover a régua da atividade para o resultado.

Medir o quê, já que medir bem é difícil

A medição de IA vai continuar imperfeita por um bom tempo. O consenso não chega amanhã, e cada ferramenta vai seguir com o seu recorte. Quem lidera engenharia não vai escolher a medição perfeita. Vai escolher que pergunta vale a pena perseguir enquanto o consenso não vem.

Perseguir o uso é perseguir um número que sobe sozinho e não diz nada sobre o produto. Perseguir o resultado, o que o time entregou e com que qualidade depois que a IA entrou, é uma pergunta mais difícil de responder e a que o board de fato faz. A diferença entre um time que sabe conversar sobre IA com a liderança e um que responde no feeling costuma estar aí, em qual das duas perguntas ele decidiu levar a sério.

É esse o problema que a gente investiga no WeLuvCode: enxergar, direto do código, o que o time entrega e com que qualidade, a partir de uma definição estável de onde os números vêm, para que a evidência sirva a quem decide sem virar mais um painel para comparar. Ler o impacto da IA nesse mesmo eixo é uma frente que estamos construindo. Seria bom ouvir como outros times de engenharia estão lidando com isso à medida que a adoção amadurece.

Conheça o WeLuvCode

Todo desenvolvedor que adotou IA vai dizer, com razão, que ele ficou mais rápido. E o painel vai concordar: mais atividade, mais entregas, mais velocidade. Ainda assim, quando a liderança medir o que de fato chegou à produção, do commit ao deploy, a entrega do time anda quase no mesmo ritmo de um ano atrás.

Essa distância entre a aceleração que se sente e a entrega que não se move é um dos assuntos mais mal compreendidos da engenharia neste momento: velocidade local, o ganho do desenvolvedor sozinho, não é a mesma coisa que velocidade sistêmica, o ganho no fluxo de entrega do time inteiro. A primeira subiu, e muito. A segunda, quase nada. Entender esse fenômeno é determinante para transformar a adoção de IA em resultado.

O ganho é real, e mais estreito do que parece

Vale começar reconhecendo: o ganho existe, e é grande onde as condições ajudam. Analisando dezenas de milhares de engenheiros, a pesquisa citada pelo DORA de 2026 encontrou de 35 a 40% de ganho de produtividade em tarefas greenfield, código novo e simples. O problema é o outro lado do mesmo dado: em base legada e complexa, o ganho desaba para 10% ou menos. E é na base legada que mora a maior parte do trabalho real de praticamente todo time maduro.

Há aí um detalhe contra-intuitivo que diz muito sobre a natureza do ganho. Os desenvolvedores mais experientes tendem a extrair mais da IA que os juniores, não menos. Isso diz muito sobre capacidade de julgamento: saber o que pedir, reconhecer quando a resposta está errada, onde encaixar o trecho gerado num sistema que já existe. Ou seja, a parte que a IA acelera de verdade nunca foi escrever código, foi o entorno. E é exatamente no entorno que o ganho individual começa a se perder antes de chegar ao time.

No caminho até a entrega, o ganho evapora

O DORA descreve bem o primeiro motivo de perda: a fricção não desaparece, ela muda de lugar. O esforço que você economiza deixando a IA escrever o boilerplate reaparece como esforço de auditar um código que se parece muito com um código correto sem necessariamente ser. É o que o relatório chama de verification tax. Ler e validar com rigor algo plausível cansa mais que escrever do zero, porque o erro não salta aos olhos, ele se esconde.

A expectativa natural é que esse custo diminua à medida que o time ganha experiência com a ferramenta. Os dados mostram o contrário. Quando a Anthropic mediu como as pessoas de fato supervisionam agentes de IA no dia a dia, encontrou um padrão que, à primeira vista, parece paradoxal: quanto mais experiente o usuário, mais ele passa a aprovar automaticamente as ações e, ao mesmo tempo, com mais frequência ele interrompe o agente. A supervisão não some com a maturidade. Ela muda de forma: de aprovar cada passo para monitorar e intervir no ponto correto. A Anthropic lê isso como supervisão saudável. Mas é a mesma moeda pela outra face: supervisão eficaz tem preço, e é esse preço que o verification tax nomeia. O custo de verificar não desaparece porque o time amadureceu. Ele deixa de aparecer como aprovação manual e passa a se manifestar como atenção contínua.

O segundo motivo de perda que o DORA apresenta está associado ao throughput: o time passa a gerar código mais depressa do que as etapas seguintes conseguem absorver: revisão, teste, aprovação de mudança, deploy. O ganho individual chega à esteira, forma fila e quem paga essa conta é o fluxo inteiro. Cada desenvolvedor acelerou a vazão individual, mas o gargalo virou o pipeline. Velocidade local vira estoque parado, não entrega mais rápida.

Por trás desses dois motivos que levam à perda dos ganhos da adoção de IA, há uma crença de fundo que alimenta os dois: a de que engenharia de software seria o terreno seguro para delegar à IA, porque o resultado é verificável, bastando rodar o código e ver se funciona. É algo que a própria pesquisa da Anthropic reflete, ao tratar a testabilidade do software como aquilo que torna mais fácil a confiança no agente nessa área do que em outras, como direito, medicina ou finanças.

O DORA complica esse raciocínio, e é uma complicação que reconhecemos na prática. “Passar no teste” não é “estar estruturalmente correto”. Um código gerado por IA pode compilar, passar no CI e ainda assim falhar em arquitetura, manutenção ou integração com o resto da base. O teste verde é o disfarce perfeito: dá a sensação de que a tarefa está concluída, e o verification tax passa sem ser notado. Ou seja, a verificabilidade que supostamente torna o software seguro para delegar é precisamente onde o custo se esconde.

O custo que ninguém orçou

Perder o ganho no caminho já seria problema suficiente. Mas há um efeito pior: parte do que foi produzido volta como custo. Quando o DORA mediu o efeito da IA sobre dez dimensões de engenharia, o maior avanço veio, como se esperava, na efetividade individual. Mas o efeito sobre o throughput do time, a vazão real de entrega, foi quase nulo. E o segundo maior efeito de todos foi negativo: aumento de instabilidade. Mais falha em produção, mais tempo consertando.

É o que se pode chamar de instability tax. O sistema ficou mais rápido para produzir e, na mesma medida, mais rápido para quebrar. Com isso, o tempo gasto estabilizando toma de volta parte do ganho que cada desenvolvedor jurava ter entregue. Some verification tax, fila no pipeline e instabilidade, e você tem a anatomia completa de como um ganho individual de 35% chega perto de zero na conta do time.

O que muda para quem lidera

A primeira consequência prática dessa leitura é parar de tratar velocidade local como se fosse velocidade sistêmica. Tempo economizado por desenvolvedor, sugestões aceitas, PRs por semana, tudo isso é sinal local, e sobe mesmo quando a entrega do time não anda. A pergunta que interessa é outra: o fluxo inteiro, do commit à produção, ficou mais rápido sem ficar mais instável?

A segunda é contar com a queda antes da subida. A adoção de IA costuma desenhar uma curva J: uma perda temporária de produtividade enquanto o time aprende a ferramenta, ajusta o pipeline e paga o verification tax, seguida de recuperação. No modelo do DORA, o vale dura algo como três meses. Esse vale é o custo de matrícula da transformação, não o veredito dela. Quem lê o vale como fracasso corta o investimento pouco antes da virada e, aí sim, garante o fracasso.

Mas há uma armadilha: a subida da curva J não é automática. Costuma-se vender como promessa: desce e sobe. Não é. A recuperação depende inteiramente do sistema em que o vale acontece.

Num sistema maduro, o vale vira recuperação e o ganho individual finalmente se converte em velocidade de time. Num sistema caótico, o mesmo vale pode nunca virar subida. A linha pode seguir descendo, com a IA apenas acelerando a deterioração. A curva J não é um direito adquirido de quem adota IA. É o resultado que só um sistema saudável entrega.

O que nos leva ao achado mais honesto do DORA: a IA não gera valor, ela amplifica o sistema em que cai. Um sistema maduro transforma o ganho individual em velocidade de time. Um sistema caótico transforma o mesmo ganho em caos mais rápido.

E não é só o DORA que aponta para lá. A Anthropic chegou a uma conclusão parecida por outro caminho: ao medir como a autonomia dos agentes cresce na prática, encontrou que ela sobe de forma gradual e não acompanha os saltos de capacidade dos modelos. Quem determina a autonomia não é o modelo, é o sistema em que ele opera.

Duas pesquisas, por caminhos opostos, uma medindo entrega e outra medindo autonomia, chegam ao mesmo destino: o que decide o resultado não é a ferramenta, é o sistema que a cerca.

Descobrir em qual dos dois sistemas você está não se faz olhando o desenvolvedor. Se faz medindo o sistema. É esse o trabalho ao qual nos dedicamos no WeLuvCode.

Conheça o WLC

Toda operação que aceita transações tem um porteiro. Obviamente, o banco tem, mas o e-commerce também tem, e a seguradora, o marketplace, a plataforma de mobilidade, a operadora de telecom. Em todos eles existe um ponto onde alguém — ou alguma coisa — decide se aquela transação passa ou não. O que mudou, ao longo do tempo, foi a forma como esse porteiro aprendeu a decidir.

No começo ele era um segurança com uma prancheta de rostos procurados: conferia cada pessoa contra uma lista fixa e barrava quem aparecia nela. Depois, já um segurança mais experiente, que já viu milhares de pessoas passarem, ele aprendeu a reconhecer, pelo jeito de cada um, quem parece suspeito — mas ainda com base no que já viu antes. Em seguida, ele deixou de ser um porteiro e virou uma equipe: investiga, cruza informações, faz perguntas e toma decisões por conta própria.

A pergunta que este texto quer provocar é simples: em qual dessas gerações a sua operação realmente está? A resposta quase nunca é a que o time de tecnologia gostaria de dar.

As duas primeiras gerações, em rápida retomada

Se você leu a primeira parte desta série, já conhece o essencial dos dois primeiros degraus — sinta-se à vontade para pular direto para a próxima seção.

A primeira geração é a das regras. O marco é o FICO Falcon, de 1992: uma rede neural detectando fraude de cartão em tempo real, mas ancorada, como a própria FICO descreve, em padrões de fraude conhecidos. Regra é barata, é determinística e é explicável — e continua insubstituível para o que é conhecido e estável. Seu teto é igualmente claro: ela não enxerga o que ainda não tem nome.

A segunda geração é a do machine learning supervisionado, que a partir dos anos 2010 troca a codificação manual de regras pelo aprendizado de padrões a partir de dados rotulados. É um salto real, mas ele carrega um limite herdado: um modelo supervisionado aprende com fraude confirmada e, por construção, está sempre uma geração atrás do fraudador. A análise comportamental — detecção de anomalia não-supervisionada, com métodos como o Isolation Forest — é o auge dessa segunda geração e a antessala da terceira, porque começa a mudar a pergunta de: “esse padrão é fraude conhecida?”, para: “esse comportamento foge do normal desta conta?”.

O ponto que interessa aqui não é reviver esse histórico, e sim notar uma coisa sobre a forma dele: cada geração não apagou a anterior, ela foi um incremento.

O movimento maior que chegou ao antifraude

Antes de seguir, é preciso destacar que a lógica de “especificar regras, aprender com dados e delegar julgamento a um sistema autônomo” não é uma peculiaridade do antifraude. É a forma como praticamente toda disciplina de automação amadurece. Antes de ser uma história sobre fraude, essa é uma história sobre automação.

O desenvolvimento de software vive isso agora, ao migrar de escrever instruções explícitas para descrever a intenção e deixar que a máquina preencha o “como”.

Em todas essas disciplinas, o movimento é o mesmo: sobe-se um degrau de abstração, transferindo para o sistema uma parcela maior de decisão. Antifraude está subindo exatamente esse degrau, e é isso que a terceira geração representa.

E é olhando desse degrau que a terceira geração do antifraude precisa ser entendida. É também onde o discurso de mercado costuma ficar mais barulhento e menos preciso, então convém definir com cuidado o que de fato muda da segunda para a terceira geração que é, fundamentalmente, o que acontece depois que o sistema chega a uma conclusão.

Terceira geração: de sinalizar para agir

As gerações anteriores focaram em pontuar e sinalizar: calcular um score, produzir uma recomendação, disparar um alerta, deixando a decisão para um humano. Um sistema agêntico não para nesse ponto: ele percebe, raciocina, decide e age por conta própria, sem esperar aprovação a cada passo. É essa passagem, do sinalizar para o agir, que redefine o problema.

A própria FICO define IA agêntica de forma sóbria: sistemas que percebem dados, raciocinam sobre eles, decidem e agem sem intervenção humana em cada etapa; e faz questão de posicionar a IA generativa como copiloto do analista, que reduz carga cognitiva e acelera investigação sem substituir o julgamento de um profissional experiente.

Ou seja, a FICO não faz um discurso de substituição, mas de alavancagem. E já existe implementação concreta: a Nasdaq Verafin descreve seu analista agêntico como uma mudança de “IA como ferramenta” para “IA como trabalhador”, capaz de percorrer sozinho o fluxo investigativo de um alerta.

Na mesma linha, a Enrst & Young, aponta que “IA agêntica permite monitoramento em tempo real e aprendizado adaptativo, analisando transações de forma autônoma e refinando a detecção, com redução significativa de falsos positivos”.

Até aqui, parece só progresso. O contrapeso honesto vem agora. Em nossa experiência implantando soluções de antifraude nos clientes da Duranium, aprendemos que autonomia sem três condições não é ativo, é passivo.

A primeira é o dado. Um agente que decide sozinho amplifica a qualidade — ou a pobreza — dos dados que o sustentam. Autonomia sobre dado ruim apenas erra mais rápido e em maior escala.

A segunda é explicabilidade. No momento em que o sistema age em vez de sugerir, alguém vai perguntar por quê. Um agente que não sabe explicar por que agiu é um risco jurídico esperando para acontecer. Setores regulados sentem isso primeiro e com força — no mercado financeiro brasileiro, por exemplo, o arcabouço em torno da Resolução BCB nº 538 deixa explícita a exigência de gestão e prestação de contas sobre decisões de risco. Mas isso não é um problema só de banco: qualquer operação cujo sistema bloqueie um cliente, negue uma apólice ou cancele uma conta vai precisar justificar a decisão, seja para o cliente, para o jurídico, para o mercado.

A terceira é governança. Quando o porteiro-equipe age sozinho e erra, quem responde? A pergunta não é retórica. Delegar decisão a um sistema autônomo é também delegar responsabilidade, e essa parte não pode ser terceirizada para o algoritmo.

Instalar um agente não é chegar à terceira geração

Daí decorre o erro mais comum de quem quer pular etapas. Instalar um componente agêntico não coloca ninguém na terceira geração se as camadas de baixo não estiverem maduras.

A evolução é cumulativa: o agente que raciocina depende do modelo que aprende, que depende do dado bem rotulado, que depende da regra bem desenhada. Pular a base não acelera a chegada à fronteira — só produz uma automação confiante e cega.

É por isso que vale enunciar o princípio que atravessa toda a série: uma geração mais avançada alimentada por dado ruim é pior do que uma geração anterior alimentada por dado bom. A conversa sobre “qual geração de IA você usa” quase sempre deveria ser, antes, uma conversa sobre a qualidade e a origem do dado que sustenta qualquer uma delas — um tema que merece um capítulo próprio.

O que já é produto e o que ainda é fronteira

Se uma geração avançada depende da qualidade das camadas anteriores, o primeiro passo é reconhecer onde a operação está de fato. Essa distinção é importante para separar maturidade real de promessa de mercado.

Na Duranium, a leitura é que a terceira geração só faz sentido quando as camadas anteriores estão bem resolvidas. Por isso, o FraudGate opera solidamente na segunda geração, e de forma madura: combina uma camada determinística — regras duras, listas e limites que o cliente ajusta em tempo real — com uma camada comportamental probabilística, calibrada com rigor sobre o eixo de falsos positivos e falsos negativos (FAR/FRR) e desenhada para a realidade transacional brasileira.

A camada agêntica é, para a Duranium, direção de pesquisa e visão de mercado — investigada internamente sob o nome Autopilot —, não um recurso pronto de prateleira. Dizer o contrário seria vender a fronteira sem ter atravessado a ponte que leva até ela.

É essa a pergunta que vale levar para dentro de qualquer operação, dentro ou fora do setor financeiro: o debate útil não é “você já tem IA agêntica?”. É “as suas camadas de baixo — regra, modelo, dado — estão maduras o suficiente para sustentar a próxima geração?”. Quem responde a essa pergunta com sinceridade descobre em que degrau realmente está.

Quer mapear em qual geração sua operação está de fato? O time de antifraude da Duranium conduz assessments de maturidade que traduzem exatamente isso: onde estão suas regras, seus modelos, seus dados — e o que falta para sustentar o próximo degrau. Fale com a gente.

Fontes

• FICO — Falcon Fraud Manager e The Future of Fraud Protection: From Platforms to Agentic AI (fico.com): marco histórico do Falcon (1992) e definição sóbria de IA agêntica e generativa em antifraude.

• Liu, F. T.; Ting, K. M.; Zhou, Z. H. (2008). Isolation Forest. IEEE ICDM — detecção não-supervisionada de anomalias.

• Nasdaq Verafin — materiais sobre Agentic AI Workforce (verafin.com): IA agêntica em produção e o conceito de “IA como trabalhador”.

• EY — The rise of agentic AI: transforming fraud risk management (ey.com): monitoramento autônomo e redução de falsos positivos por aprendizado contínuo.

• Banco Central do Brasil — Resolução BCB nº 538 (referência ilustrativa ao peso regulatório sobre gestão e prestação de contas de decisões de risco).

Compartilhar

Existe uma pergunta que toda liderança de engenharia de software precisa se fazer com frequência: o que estamos entregando é realmente bom?

Quando volume ainda significava maturidade

Por anos, essa pergunta foi respondida de forma indireta, olhando para a velocidade: deploys frequentes, ciclos curtos, alto volume de pull requests e aumento de throughput costumavam ser sinais de um time saudável.

Essas métricas nunca foram uma medida perfeita de qualidade, mas funcionavam como indicadores razoáveis em um contexto no qual esforço humano e volume de entrega ainda caminhavam relativamente próximos.

Até pouco tempo atrás, quando a escrita do código dependia quase inteiramente do trabalho humano, havia uma relação mais estável entre o trabalho produzido e o cuidado necessário para produzi-lo. Um time que entregava mais, com ciclos menores e frequência constante, provavelmente tinha processos mais maduros, menor fricção e boa capacidade de execução. O volume não dizia tudo, mas ajudava a interpretar a saúde da engenharia.

O que a IA generativa mudou

A adoção de IA generativa mudou essa relação.

Hoje, um desenvolvedor apoiado por um agente consegue abrir múltiplos PRs em poucos minutos. O painel pode registrar mais atividade, mais entregas e mais velocidade, sem que isso represente, necessariamente, uma base de código mais saudável. O que antes era uma pista razoável de maturidade agora passou a capturar também a intensidade de uso da ferramenta.

Essa mudança cria um problema importante para quem lidera engenharia: as métricas tradicionais continuam subindo, mas parte delas deixa de responder à pergunta central sobre qualidade. Elas mostram que mais coisas estão sendo produzidas. Não mostram, sozinhas, se essas coisas melhoram ou deterioram o sistema.

O que o relatório DORA de 2026 revela

O relatório DORA de 2026 ajuda a enxergar a amplitude desse descompasso. Ao medir os efeitos da adoção de IA sobre diferentes dimensões de engenharia, o estudo identificou um ganho relevante na efetividade individual do desenvolvedor. Esse resultado é esperado: a IA ajuda a escrever, completar, revisar e acelerar partes do trabalho.

O ponto crítico está em outro efeito detectado pelo relatório: um aumento expressivo na instabilidade da entrega.

Ao mesmo tempo em que a IA torna cada pessoa mais rápida, a qualidade do código e o throughput do time apresentam ganhos limitados, aumentando o risco de instabilidade no sistema. O resultado é um descompasso: o processo acelera sem que aquilo que realmente importa melhore na mesma proporção.

Onde a fricção foi parar

Isso não significa que a IA seja ruim para engenharia. Significa que ela muda o lugar onde a fricção aparece. Parte do esforço economizado na escrita do código passa a ser gasto na validação de um código que parece correto, compila, passa em testes automatizados, mas ainda pode falhar em aspectos importantes de arquitetura, negócio, manutenção ou integração com o restante da base.

Esse efeito também não se distribui de maneira uniforme. Em códigos novos e simples, os ganhos de produtividade podem chegar a 35% ou 40%. Em bases legadas, com dependências acumuladas, decisões antigas e maior complexidade estrutural, esse ganho pode cair para 10% ou menos.

A leitura superficial dos indicadores tende a mostrar uma melhora geral. Os indicadores do painel ficam todos verdes, mas a realidade por baixo desses números é mais fragmentada. Em alguns contextos há ganho real. Em outros, há apenas mais produção sobre uma estrutura igualmente frágil.

A decepção por trás dos números verdes

Esse descompasso já aparece na percepção executiva. Em uma pesquisa recente conduzida pela Writer em parceria com a Workplace Intelligence, quase metade dos executivos relatou decepção relevante com o retorno do investimento em IA, em um movimento que cresceu de forma consistente de um ano para o outro.

O padrão é compreensível. Os indicadores tradicionais mostram aumento de atividade, mas quem opera os sistemas percebe mais retrabalho, mais revisão, mais dúvidas sobre o que foi realmente resolvido e mais dificuldade para separar velocidade real de produção inflada. Quando isso acontece, a liderança perde clareza sobre a pergunta mais importante: a engenharia está entregando melhor ou apenas entregando mais?

Métricas que medem consequência, não atividade

A resposta não está em abandonar métricas. Métricas continuam sendo fundamentais para entender fluxo, gargalos, previsibilidade e capacidade de entrega. O problema está em tratar métricas de volume como se fossem evidência direta de qualidade.

Alguns indicadores continuam úteis justamente porque medem consequências, não atividade. Falhas em produção, tempo de recuperação, volume de retrabalho e recorrência de incidentes dizem mais sobre o efeito real das entregas do que a simples contagem de PRs, deploys ou linhas de código.

Um defeito que chega ao ambiente de produção é um fato concreto, independentemente de ter sido escrito por uma pessoa ou gerado com apoio de IA.

O tempo necessário para recuperar um sistema depois de um incidente também revela algo importante sobre a compreensão da base, a robustez da arquitetura e a capacidade do time de operar aquilo que constrói.

O retrabalho segue a mesma lógica. Quando um código precisa ser refeito logo depois de ser considerado pronto, existe uma diferença entre produção aparente e entrega real. Esse cenário tende a se tornar mais frequente quando o código gerado com IA resolve o sintoma imediato, mas não considera adequadamente o contexto do sistema ou o objetivo de negócio. Por isso, a pergunta sobre qualidade precisa ir além da contagem.

O teste que separa atividade de qualidade real

Uma forma simples de testar uma métrica é perguntar se um agente de IA conseguiria inflar aquele número sem de fato gerar melhorias. Se a resposta for sim, a métrica ainda pode ter valor operacional, mas não deve ser lida como prova de qualidade.

Isso vale para número de PRs, linhas de código, volume de commits e até frequência de deploys. Esses indicadores ajudam a entender movimento. Não bastam para entender saúde. Para avaliar qualidade, é preciso observar o conteúdo do que foi entregue.

Imagine dois PRs com o mesmo cycle time, ambos aprovados no CI e registrados da mesma forma no painel. No primeiro, o desenvolvedor entendeu a causa raiz de um bug e corrigiu o problema na origem. No segundo, um agente de IA tratou apenas o sintoma, adicionou mais linhas de código, acoplou uma nova dependência e não criou testes capazes de validar o cenário de risco.

Pelas métricas de fluxo, os dois PRs podem parecer equivalentes. Em alguns casos, o segundo pode até parecer mais produtivo, simplesmente por gerar mais código. A diferença real aparece quando alguém analisa o conteúdo da entrega: um PR reduziu risco e melhorou a base; o outro apenas deslocou o problema para o futuro.

Esse é o tipo de distinção que a contagem não consegue fazer sozinha. Ela exige leitura do código, da arquitetura, dos testes, das dependências e dos efeitos acumulados sobre a base.

Ler o conteúdo significa observar sinais que nem sempre viram número de forma automática: aumento de acoplamento, duplicação de lógica, crescimento de complexidade, ausência de testes em áreas críticas, dependências mal introduzidas e soluções que resolvem o caso imediato sem preservar a qualidade estrutural do sistema.

Esses sinais ajudam a responder uma pergunta diferente daquela respondida pelas métricas de fluxo. O fluxo mostra como o time entrega, onde trava e com que velocidade avança. A leitura do conteúdo mostra o que está sendo acumulado na base a cada entrega, independentemente da velocidade.

As duas dimensões são necessárias. Sem métricas de fluxo, a liderança perde visibilidade sobre ritmo, previsibilidade e gargalos. Sem leitura do conteúdo, ela pode confundir atividade com evolução. O risco, na era da IA, é deixar que um dashboard cheio de sinais positivos esconda uma base de código que está ficando mais frágil.

Por que criamos o WeLuvCode

Foi a partir dessa leitura que criamos o WeLuvCode.

O WeLuvCode integra métricas de fluxo, extraídas do histórico do Git, com análise semântica do conteúdo do código. A proposta é oferecer à liderança uma visão que conecte velocidade de entrega com impacto estrutural sobre a base.

Na prática, isso permite identificar situações em que o cycle time caiu, mas o acoplamento nos módulos alterados aumentou na mesma proporção. Também permite observar quando uma sequência de PRs acelerou o fluxo, mas elevou complexidade, duplicação ou risco de manutenção em partes importantes do sistema.

Em outras palavras, o WeLuvCode mostra se a velocidade veio com um custo estrutural. Algo que nenhum dos dois indicadores mostraria sozinho.

Esses sinais, vistos isoladamente, podem passar despercebidos. A queda no cycle time sugere ganho de eficiência. O aumento de acoplamento sugere perda estrutural. Quando os dois aparecem juntos, a liderança consegue enxergar o custo real da velocidade.

E não se trata de uma foto pontual, mas de uma leitura contínua e automatizada. O WeLuvCode realiza uma leitura contínua e acompanha a evolução da base a cada nova entrega. Isso permite observar tendências, identificar deterioração progressiva e entender como decisões de curto prazo afetam a saúde do código ao longo do tempo.

Conheça o WeLuvCode

Nossa própria experiência com IA em escala

Sobre essa fundação, estamos construindo uma camada adicional voltada especificamente para o uso de IA na engenharia. O objetivo é entender quanto do código já é assistido por ferramentas de IA generativa, qual é o custo desse uso e que nível de qualidade ele produz.

Essa convicção vem da nossa própria experiência. A Duranium é parceira oficial da Anthropic e implementa IA aplicada à engenharia no dia a dia.

Convivendo de perto com código gerado em larga escala, ficou claro que medir apenas adoção, volume ou velocidade seria insuficiente. A pergunta relevante não é apenas quanto a IA está sendo usada, mas o que ela está produzindo para a saúde da base.

O WeLuvCode nasce desse aprendizado: medir fluxo continua importante, mas a liderança também precisa ler o conteúdo do que está sendo entregue.

Da contagem ao entendimento

Para quem lidera engenharia, a recomendação não é descartar frameworks como DORA ou SPACE. Eles continuam úteis para entender desempenho, fluxo e operação. O ponto é complementar essas métricas com uma camada capaz de avaliar qualidade estrutural.

A relação histórica entre volume e valor ficou menos confiável. Com IA, um time pode produzir mais sem necessariamente melhorar o sistema. Pode reduzir cycle time e, ao mesmo tempo, aumentar retrabalho. Pode elevar o número de entregas e acumular dívida técnica silenciosa.

A liderança que quiser avaliar o impacto real da IA na engenharia precisará olhar para além da atividade gerada. Será necessário conectar fluxo, consequência e conteúdo: o que foi entregue, como isso afetou a base e quais sinais indicam melhora ou deterioração ao longo do tempo.

No fim das contas, quem vai saber se a IA está ajudando o time ou deteriorando a base de código em silêncio é quem parou de contar o que a engenharia produz e começou a entender o que cada entrega muda no sistema.

Imagine um segurança parado na porta de um prédio, com uma prancheta de rostos de pessoas procuradas na mão. A cada pessoa que chega, ele compara o rosto com a lista. Se bate, barra. Se não bate, deixa passar. É um sistema que funciona muito bem contra reincidentes — quem já foi fichado não entra de novo. Mas ele tem um ponto cego estrutural, e o ponto cego não é uma falha de execução: é a própria definição do método. O segurança não consegue identificar um novo golpista. Quem nunca apareceu na lista atravessa a porta sorrindo.

Por mais de trinta anos, foi assim que a detecção de fraude funcionou: comparando cada transação com um catálogo do que já se sabia ser golpe. Agora imagine esse mesmo segurança diante não de uma fila organizada, mas de uma multidão atravessando a porta ao mesmo tempo, em segundos, sem catraca e sem volta.

Foi exatamente isso que o Pix fez com o mercado brasileiro. Em 2025, o sistema processou 79,8 bilhões de transações — uma média acima de 200 milhões por dia, com pico de mais de 313 milhões em um único dia de dezembro. Cada uma delas é processada em segundos. É nessa multidão, nessa velocidade, que o ponto cego daquele segurança hipotético deixou de ser um detalhe e virou o problema central do antifraude no país.

O limite estrutural: você só detecta o que já tem nome

A disciplina de antifraude nasceu olhando para trás. O marco fundador é de 1992, quando a FICO lançou o Falcon, um sistema de detecção de fraude em cartões baseado em rede neural operando em tempo real. Foi um avanço enorme para a época, e a arquitetura que ele inaugurou ainda domina o mercado: um modelo aprende, a partir de transações historicamente rotuladas como fraude, a reconhecer os padrões que se repetem. Quanto melhor o histórico, melhor a detecção. A própria FICO descreve o Falcon como uma tecnologia que “alavanca padrões de fraude conhecidos” para atingir seus níveis de precisão.

A palavra que importa nessa frase é essa: conhecidos.

Diante disso, a leitura fácil é dizer que o problema é a regra velha e que a solução é simplesmente colocar mais inteligência artificial no lugar. Mas essa é uma falsa oposição.

Vale ser justo com o estado da arte: os grandes fornecedores globais já foram muito além de regras estáticas há tempos — operam camadas robustas de machine learning, biometria comportamental e inteligência de rede. A Feedzai, por exemplo, se posiciona justamente pela capacidade de identificar fraudes novas a partir de desvios de comportamento. O antagonista desta história, portanto, não é “regra contra IA”. Essa é uma simplificação que qualquer pessoa de risco desmonta em trinta segundos.

O limite real é mais sutil e mais profundo, e tem duas camadas.

A primeira é temporal: um modelo supervisionado — por mais sofisticado que seja — aprende com fraude confirmada. Por construção, ele está sempre uma geração atrás do fraudador, porque precisa que um golpe aconteça, seja rotulado e entre no conjunto de treino antes de saber reconhecê-lo.

A segunda é geográfica, e é aqui que a coisa ganha um verniz à brasileira. A inteligência desses fornecedores é calibrada, na maior parte, sobre a realidade transacional de outros mercados — e o catálogo de fraudes do mundo deles não é o nosso.

O golpe que define o Brasil não é o vazamento de cartão à americana. É o falso funcionário do banco que liga pedindo um Pix “de segurança”; é o falso parente no WhatsApp; é o falso boleto e a falsa central de atendimento; é o investimento fraudulento que circula em grupo de mensagens; é a conta-laranja que recebe e repassa o dinheiro em cadeia, em minutos; é a cultura de um pagamento que não tem estorno automático.

Nada disso aparece com a mesma cara — nem com a mesma frequência — em modelos treinados sobre fraude de cartão europeia ou norte-americana.

São esses dois limites somados — o que chega tarde e o que olha para o lugar errado — que abrem a porta para novas modalidades de golpes.

O comportamental detecta o desvio, não o rótulo

Se o nosso segurança segurando a prancheta pergunta: “esse rosto está na lista de procurados?”, o sistema comportamental pergunta outra coisa: “essa pessoa está agindo como o dono desta conta costuma agir?”.

A diferença não é cosmética. É a diferença entre detecção supervisionada — que aprende com exemplos rotulados — e detecção não-supervisionada de anomalias, que não precisa de rótulo nenhum para funcionar.

Ela modela o comportamento normal de cada conta e dispara quando há um desvio relevante daquele perfil, independentemente de aquele tipo específico de fraude já ter um nome.

A literatura técnica sustenta isso de forma sólida. Algoritmos como o Isolation Forest, proposto por Liu, Ting e Zhou em 2008, isolam anomalias explicitamente em vez de modelar laboriosamente o que é “normal”.

Autoencoders fazem algo parecido por outro caminho: aprendem a reconstruir o comportamento típico e tratam o erro de reconstrução como sinal de anomalia.

O ponto que importa para quem decide é este: métodos não-supervisionados têm capacidade comprovadamente superior de detectar ataques desconhecidos, justamente porque não dependem de assinaturas prévias.

Traduzindo para a operação: a camada determinística — regras duras, listas, limites — continua essencial e barata para o que é conhecido e estável. Mas é a camada comportamental, probabilística, que cobre o território onde a fraude ainda não tem nome.

O trabalho fino não está em escolher uma ou outra, e sim em calibrar a fronteira entre as duas — o equilíbrio entre falsos positivos (FAR) e falsos negativos (FRR) que decide se o sistema protege o cliente ou o pune. É nesse ajuste que mora a engenharia de verdade.

O Pix mudou a geometria do problema

Nada disso seria tão urgente se a janela de reação ainda existisse. No mundo do cartão, do boleto, da transferência que levava horas para compensar, havia tempo: dava para detectar depois, estornar, bloquear o saque. A fraude tinha um intervalo onde podia ser interrompida.

O Pix fechou esse intervalo. A liquidação é final e acontece em segundos — não existe, no Pix, o estorno automático que o cartão oferece via chargeback. E a escala torna tudo mais sério: segundo o Banco Central, o sistema movimentou R$ 35,36 trilhões em 2025, cerca de três vezes o PIB do país, com quase 80 bilhões de transações e alcance de praticamente toda a população adulta.

Isso não significa que não exista caminho de volta. O Banco Central criou o MED — Mecanismo Especial de Devolução —, que dá à vítima até 80 dias para contestar uma transação de golpe ou fraude e permite o bloqueio cautelar dos valores na conta de destino.

Mas o MED não é um botão de desfazer: a devolução só acontece se o dinheiro ainda estiver lá.

E os fraudadores sabem disso — esvaziam a conta de destino em minutos, pulverizando o valor por uma cadeia de contas-laranja.

O problema é tão estrutural que o próprio regulador precisou evoluir o mecanismo: o MED 2.0 (Resolução BCB nº 493/2025), obrigatório desde fevereiro de 2026, passou a rastrear o caminho do dinheiro por várias contas justamente porque a recuperação na conta original quase sempre falhava.

A leitura correta, portanto, não é “a transação é irreversível”. É algo incômodo: a recuperação depois do fato é uma corrida contra o relógio na qual, na maioria das vezes, a vítima perde.

A ACI Worldwide diz o mesmo em linguagem técnica — em transações instantâneas não há janela de recuperação confiável, o que torna o monitoramento pós-transação insuficiente por si só. Tudo isso empurra a decisão para o único lugar onde ela ainda faz diferença: os milissegundos antes da liquidação.

E há um tipo de golpe que ataca a velha prancheta no seu ponto mais sensível.

A modalidade que mais cresce nos pagamentos instantâneos é o golpe de pagamento autorizado — o que a ACI chama de “fraude Pix” no Brasil.

Nele não há invasão de conta nem transação tecnicamente anômala: é o próprio cliente legítimo, manipulado por engenharia social, quem autoriza a transferência. Do ponto de vista da credencial, está tudo correto (e por isso o golpe contorna os controles tradicionais). O rosto que chega na porta é o do próprio morador, agindo sob um engano que o sistema não enxerga.

Os números dão a dimensão do estrago: só em 2024, o Banco Central contabilizou R$ 6,5 bilhões em perdas com fraudes envolvendo o Pix, alta de 80% em um único ano.

Há aqui um detalhe que o mercado ainda está digerindo: o próprio MED, criado para proteger a vítima, pode, potencialmente, se tornar uma superfície de ataque. Fraudadores aprenderam a explorar o mecanismo de contestação - como nos golpes que vêm atingindo lojistas que recebem por Pix e, em seguida, têm o pagamento contestado. A Duranium dedicou um whitepaper inteiro a mapear esses vetores de ameaça ao MED 2.0. Mas isso é assunto para outra conversa.

Por que o Brasil virou laboratório de detecção comportamental

Junte os três fatos: volume gigantesco, liquidação final em segundos e um fraudador local criativo, que opera por WhatsApp e engenharia social em vez de invasão técnica. O resultado é um ambiente onde a detecção baseada em fraude conhecida não tem para onde correr — o intervalo de reação que ela pressupõe simplesmente não existe.

Isso coloca o Brasil numa posição incomum. Em vez de importar o problema dos mercados desenvolvidos com cinco anos de atraso, como costumava acontecer, o país chegou primeiro à fronteira. A combinação de pagamento instantâneo de massa com fraude em tempo real é um cenário que Europa e Estados Unidos só começam a viver agora, à medida que seus próprios trilhos instantâneos amadurecem. Quem aprende a detectar comportamento fraudulento no ambiente brasileiro está, na prática, resolvendo um problema antes do resto do mundo.

A fronteira não é reconhecer a fraude. É reconhecer o desvio.

A lição que atravessa tudo isso é simples de enunciar e difícil de implementar: vencer a fraude deixou de ser uma questão de ter o melhor catálogo de fraudes conhecidas. Passou a ser uma questão de reconhecer o desvio de comportamento antes que ele tenha um nome — e de fazer isso na janela de milissegundos antes de uma transação que não volta atrás.

É essa a tese que orienta o FraudGate, a plataforma de antifraude da Duranium. Em vez de tratar regra e comportamento como rivais, ela combina uma camada determinística — regras duras, listas e limites que o cliente ajusta em tempo real — com uma camada comportamental probabilística, calibrada com rigor sobre o eixo FAR/FRR e desenhada para a realidade transacional brasileira, não adaptada a ela depois. A diferença entre os dois projetos é a diferença entre o segurança que confere a prancheta e o que conhece, de fato, quem mora no prédio.

A pergunta que vale fazer dentro da sua operação não é “qual é o nosso melhor modelo”. É outra: quanto da nossa detecção ainda depende de a fraude já ter acontecido antes para que a gente saiba reconhecê-la? A resposta diz onde sua instituição está na fronteira — e quanto da sua exposição mora no ponto cego.

Quer mapear onde sua operação está nessa curva? O time de antifraude da Duranium conduz assessments de maturidade que medem exatamente isso: quanto da sua detecção é reativa ao conhecido e quanto já cobre o comportamental. Fale com a gente.

E aquela outra conversa — sobre o MED virar alvo? Ela já existe. No whitepaper Modelagem de Ameaças ao MED 2.0, a Duranium mapeia, via STRIDE, os vetores que transformam o mecanismo de devolução em superfície de ataque — e o que isso exige das instituições financeiras. Baixe o material.

Fontes

• FICO — Falcon Fraud Manager e Fraud Detection with Machine Learning (fico.com): histórico do Falcon (1992, rede neural, tempo real) e limites da detecção por padrões conhecidos.

• Liu, F. T.; Ting, K. M.; Zhou, Z. H. (2008). Isolation Forest. IEEE ICDM — método fundacional de detecção não-supervisionada de anomalias.

• Feedzai — materiais de produto (feedzai.com): posicionamento de detecção comportamental de fraudes desconhecidas.

• ACI Worldwide / GlobalData — Scamscope Report e materiais sobre pagamentos em tempo real: irreversibilidade dos trilhos instantâneos e golpes de pagamento autorizado (”fraude Pix”).

• Banco Central do Brasil — Estatísticas de Pagamentos e balanço do Pix 2025 (R$ 35,36 tri; 79,8 bi de transações); perdas com fraude no Pix em 2024 (R$ 6,5 bi, +80%).

• Banco Central do Brasil — Mecanismo Especial de Devolução (MED) e MED 2.0 (Resolução BCB nº 493/2025): janela de contestação de 80 dias, bloqueio cautelar e rastreamento do caminho do dinheiro.

• Duranium — Whitepaper: Modelagem de Ameaças ao MED 2.0 (análise STRIDE de vetores de ataque ao mecanismo).

Algo que a indústria vinha evitando dizer em voz alta ficou explícito em dois sinais que aconteceram quase ao mesmo tempo em maio de 2026.

A Microsoft, que investiu cerca de US$ 13 bilhões na OpenAI e escreve perto de 30% do próprio código com IA generativa, pediu, discretamente, que engenheiros de uma divisão importante parassem de usar o Claude Code. Não porque a ferramenta não funcionava. Porque a conta ficou grande demais.

O segundo sinal veio da da Uber alguns dias depois: a empresa havia colocado um agente de codificação nas mãos de cerca de 5.000 engenheiros em dezembro de 2025. Em abril de 2026, o CTO revelou a repórteres que o orçamento anual de IA tinha sido consumido em quatro meses. Engenheiros gastavam entre US$ 500 e US$ 2.000 por mês só em chamadas de API. Adoção em 95%. Setenta por cento dos commits dirigidos por IA. E, ainda assim, o COO da empresa, Andrew Macdonald, admitiu não conseguir traçar uma linha entre esses números impressionantes e valor real para o usuário.

Quem trabalha há tempos com engenharia reconheceu o problema na hora: o número de linhas de código nunca foi um bom indicador do valor do trabalho de engenharia. Gerar mais linhas, mais rápido, não torna o indicador mais confiável; só torna o desperdício mais veloz.

A pergunta que importa, então, deixa de ser “quanto código a IA produz?” e passa a ser “como você governa, mede e prova o retorno desse código?”. E é exatamente aí que entra o framework que o Google publicou recentemente.

Do vibe coding à engenharia agêntica

O paper do Google (”The New SDLC With Vibe Coding“) trata vibe coding e engenharia agêntica não como um sim/não, mas como extremos de um espectro. No “vibe coding”, você descreve o que quer em linguagem natural, aceita o que a IA devolve e, quando algo quebra, cola a mensagem de erro de volta e pede para consertar. Verificação é opcional: roda, parece certo, segue.

Na outra ponta, a engenharia agêntica trata a IA como um motor de implementação dentro de um sistema cuidadosamente desenhado de restrições, testes e feedback loops, com humanos mantendo a decisão sobre arquitetura, correção e qualidade.

O diferenciador entre os dois não é usar IA. É quanta estrutura, verificação e julgamento cercam o output.

Isso parece abstrato até você trocar o exemplo. Um protótipo de fim de semana pode ser puro vibe coding, com risco aceitável e código descartável. Um sistema que sustenta um produto em produção exige engenharia agêntica. No meio, fica quase todo o trabalho real, e a habilidade está em saber onde traçar a linha para cada tarefa. Essa decisão vale para qualquer empresa que já gera código com IA (e, segundo a Stack Overflow, isso já são 84% dos desenvolvedores).

O harness é governança de IA

Há uma tentação, quando se começa a trabalhar com agentes, de tratar o modelo como o sistema inteiro. Modelo novo, agente fica melhor; modelo velho, agente piora. O modelo vira a explicação para tudo.

O Google argumenta que essa intuição é errada e cara. O modelo é só um insumo. Tudo o mais (os prompts, as ferramentas, as políticas de contexto, os hooks, os sandboxes, a observabilidade) é o que eles chamam de harness: o arcabouço em volta do modelo que faz ele realmente terminar alguma coisa.

A equação é simples:

Agente = Modelo + Harness

Se o modelo é o motor, o harness é o carro, a estrada e as leis de trânsito. Um motor sozinho não fabrica um carro. E os números são contundentes: num benchmark público (Terminal Bench 2.0), um time tirou um agente de fora do Top 30 e o colocou no Top 5 sem trocar o modelo, mexendo só no harness. A conclusão do paper é direta: a maioria das falhas de agente, examinadas com honestidade, são falhas de configuração, não do modelo.

Aqui vale traduzir “harness” para a linguagem de quem precisa responder por essa adoção: harness é governança de IA, na prática. Ele inclui as regras e instruções que o agente carrega (arquivos como AGENTS.md, CLAUDE.md), as ferramentas que ele pode chamar, os ambientes isolados onde o código roda, a lógica de orquestração e os guardrails, hooks e observabilidade: código determinístico que dispara em momentos do ciclo (por exemplo, bloquear um commit que tente subir uma senha), o rastreamento de qual código foi gerado por IA, e a capacidade de auditar por que um agente tomou determinada decisão.

Governar significa exatamente isso: saber o que o agente pode fazer, o que ele fez e por que. Segurança é uma das dimensões dessa governança — importante, mas não a única. Sem o harness, você não tem um problema de modelo; tem um problema de controle.

O novo SDLC: você não escreve código, você projeta a fábrica

A consequência disso para o ciclo de desenvolvimento (SDLC) é estrutural. Quando a implementação que levava semanas passa a levar horas, o gargalo migra. Requisitos, arquitetura e verificação seguem teimosamente humanos; a escrita de código, não.

O Google resume isso no que chama de modelo de fábrica: o entregável principal do desenvolvedor deixa de ser o código e passa a ser o sistema que produz código. Esse sistema reúne especificações e contexto, agentes que traduzem specs em implementação, testes e quality gates que verificam correção, feedback loops que devolvem as falhas para o agente corrigir e guardrails que mantêm o agente dentro de um comportamento seguro.

Um gerente de fábrica não monta cada peça à mão. Ele projeta a linha de montagem e garante o controle de qualidade.

Aqui mora o risco que o discurso de produtividade costuma pular. Uma fábrica sem controle de qualidade não produz menos defeito — produz defeito em escala. E os dados não são gentis: 45% do código gerado por IA contém vulnerabilidades (Veracode, 2025), e 20% dos pacotes que a IA sugere simplesmente não existem — o fenômeno do slopsquatting. Sem governança embutida na linha, a fábrica industrializa o defeito na mesma velocidade com que industrializa a entrega.

Assine agora

A economia: o problema é provar o ROI

Para um líder de engenharia, a métrica que importa não é velocidade — é retorno. E é aí que os fatos convergem.

O vibe coding parece imbatível em custo: uma assinatura mensal e alguns prompts. O CapEx (investimento inicial) é quase zero, porque você se apoia inteiramente na capacidade bruta do modelo. Mas o paper do Google mostra o que isso esconde: um OpEx (despesas operacionais) alto e crescente, em três parcelas.

A primeira é o token burn — o loop caro de despejar arquivos enormes no contexto e pedir, repetidamente, que o modelo conserte os próprios erros.

A segunda é o imposto de manutenção: código gerado por prompt ad-hoc costuma não ter consistência estrutural, e meses depois alguém gasta dias fazendo engenharia reversa de um “espaguete”.

A terceira é a remediação: corrigir uma falha em produção custa exponencialmente mais do que pegá-la no design.

O caso Microsoft/Uber é precisamente esse OpEx se materializando. E o ponto mais incômodo não foi a conta — foi o COO da Uber não conseguir provar o que aquele gasto comprou. Esse é o coração do problema de ROI da IA: commits são contáveis; valor, não. A menos que você instrumentalize a medição.

A engenharia agêntica inverte a equação: CapEx alto, OpEx baixo. Investe-se tempo, antes da primeira linha de produção, em desenhar schemas, construir suítes de teste e, sobretudo, estruturar o contexto do agente. O custo marginal de cada feature despenca, porque a IA opera dentro de uma fábrica governada. Context engineering, nesse mundo, deixa de ser um truque técnico e vira uma alavanca financeira. Provar o ROI deixa de ser narrativa e passa a ser leitura de métrica DORA, qualidade, custo por feature entregue e verificada.

O elo que ninguém terceiriza: o time que sabe dirigir agentes

Há uma última peça nessa história, uma que a fintech sueca Klarna aprendeu do jeito caro.

Em 2024, a empresa cortou cerca de 700 posições para substituir gente por IA. A satisfação despencou justamente nos casos complexos; os que exigiam julgamento e não estavam nos padrões aprendidos pela IA se acumularam sem ninguém preparado para resolver, enquanto a média geral mascarava a piora. Em meados de 2025, a empresa recontratava humanos.

A versão de manchete diz “a IA falhou”. A versão precisa é outra: a IA resolveu o trabalho que foi feita para resolver, e aí se descobriu que esse trabalho não era a maior parte do trabalho. Sistemas reais acumulam história. Uma IA lê o código, mas não leu a reunião em que se decidiu não usar uma abordagem por causa de uma falha de três anos atrás que nunca foi documentada.

Por isso o Google é categórico ao falar de pessoas: o gargalo migra da escrita para a especificação, a avaliação e o julgamento, e os engenheiros mais valiosos dos próximos anos serão os que dirigem agentes bem, não os que escrevem mais código. Isso não acontece por osmose. Acontece quando a empresa decide educar o time deliberadamente para especificar com precisão, decompor tarefas, avaliar output com ceticismo e desenhar os guardrails e feedback loops que mantêm o agente produtivo.

Geração resolvida. O novo ofício é outro.

A transição de sintaxe para intenção não é previsão de futuro, é presente. A transformação já está acontecendo e agora é questão com quanta disciplina cada time vai navegá-la. Três princípios resistem: estrutura escala, “vibe” não; a IA amplifica a cultura de engenharia que encontra — multiplica forças e fraquezas; e o papel humano evolui, não diminui.

É essa a leitura que orienta o trabalho da Duranium, IA-first dos dois lados — protegendo o código e a transação.

Como Parceiro Anthropic, ajudamos a estruturar esse harness de ponta a ponta; em setores regulados, como o financeiro, onde acumulamos cases, ele ainda vira evidência de conformidade; mas o problema é horizontal: vale para qualquer empresa que já gera código com IA.

A geração de código está resolvida. Governança, prova de ROI, julgamento e educação são o novo ofício.

Sua empresa já gera código com IA. A pergunta é se isso está governado, medido e nas mãos de um time preparado.

Fale com a Duranium sobre WeLuvCode, Consultoria Anthropic e a Duranium Academy.

#IAnaEngenharia #EngenhariaAgentica #GovernancaDeIA #ROIdeIA #ClaudeCode

O Cenário em Números: Uma Mudança de Ordem de Grandeza

Em 2024, o MITRE CVE (Common Vulnerabilities and Exposures) chegou a registrar picos de vulnerabilidades nunca antes vistos. Para colocar em perspectiva: há dez anos, falávamos em centenas de CVEs por mês. Hoje, esse número é uma rotina para muitos segmentos e, em picos específicos, entra na casa dos milhares.

Em 2025, Daniel Stenberg, mantenedor histórico do cURL (uma das bibliotecas mais usadas na internet), comentou que a velocidade de descoberta e publicação de vulnerabilidades tornou-se incompatível com o ritmo de correção tradicional. Antes, uma vulnerabilidade podia ficar “quieta” no radar por meses. Hoje, é medida em horas.

Estamos em um cenário de transformação estrutural.

Por Que Isso Está Acontecendo: A Democratização da Descoberta

A resposta está em uma palavra: automação.

Ferramentas de análise estática (SAST), análise dinâmica (DAST), scanning de dependências (SCA) e, crucialmente, modelos de IA aplicados à detecção de vulnerabilidades tornaram a busca por falhas uma atividade escalável, barata e contínua.

Antes, encontrar uma vulnerabilidade requeria expertise humana. Hoje, um pipeline de CI/CD com as ferramentas certas consegue varrer código, identificar padrões suspeitos, e reportar potenciais CVEs em minutos.

A consequência: o custo de descoberta caiu dramaticamente. Onde havia gargalos humanos, agora há paralelização.

Empresas que conseguem equipar seus time com ferramentas modernas,como orquestração AppSec com integração de SAST, SCA, análise comportamental, começam a descobrir vulnerabilidades que, há cinco anos, teriam passado desapercebidas por meses.

O Caso Mythos: De Meses para Horas

Em 2026, a Anthropic divulgou publicamente um cenário emblemático: uma vulnerabilidade complexa em uma biblioteca de processamento de linguagem natural foi descoberta, validada, corrigida e patcheada em poucas horas — não dias, não semanas. O ciclo completo.

Isso não seria notável se não fosse impossível há pouco tempo. Antes, esse tipo de descoberta levaria semanas de análise, mais semanas de comunicação com mantenedores, e meses até a propagação do patch.

O que mudou? Análise contínua automática sobre uma codebase viva. A IA não só identificou a falha, mas sugeriu a correção contextualizada, e engenheiros humanos validaram em tempo real.

O significado é profundo: não estamos apenas descobrindo mais vulnerabilidades, estamos reduzindo o tempo de exposição. A velocidade de correção começou a acompanhar a velocidade de descoberta, pelo menos nos casos em que há automação envolvida.

ASSISTA AO WEBINAR

O Efeito Colateral: O Dilema de Priorização Explodiu

Aqui está o dilema que mantém os security leads acordados à noite: se há 2.000 CVEs potenciais na sua stack, qual você corrige primeiro?

Há dez anos, a resposta era simples: todos, pois a quantidade era administrável, já hoje, isso seria impossível.

O que antes era uma lista de prioridades virou um problema combinatório. Uma organização típica pode estar exposta a 500+ vulnerabilidades conhecidas simultânea e legitimamente, considerando dependências indiretas, versões não-auditadas de bibliotecas, código legado nunca revisado.

Um banco, uma fintech, uma empresa de seguros. Todas enfrentam a mesma realidade: priorizar não é mais uma questão operacional, é uma questão de risco.

E aqui é onde a IA realmente entra: modelos treinados para entender o “risco contextual” de uma vulnerabilidade — isso é, qual CVE é mais provável de ser explorado dado o seu ambiente específico, suas dependências, sua exposição de rede, seu padrão de tráfego — começam a tornar a priorização viável novamente.

Mas exige equipamento. Exige estrutura.

O Que Não Funciona: Os Processos de Antes Não Escalam

Muitas empresas ainda operam com processos desenhados para o mundo anterior: planilhas de priorização manual, reuniões semanais de triagem, análise humana pura de cada CVE. Esses processos quebram sob volume. Colocar mais gente no problema não resolve. Uma equipe de segurança de 50 pessoas não consegue revisar 2.000 vulnerabilidades de forma contínua. O problema não é linear, é exponencial.

Alguns cenários que não funcionam mais:

• “Vamos revisar todos os CVEs em comitê” → Impossível. O tempo de decisão vai além do tempo de exploração.

• “Vamos fazer um plano de remedição de 12 meses” → A vulnerabilidade explorada no mês 3 não espera o plano.

• “Vamos cuidar só das críticas” → “Crítico” é subjetivo. Um CVE classificado como “média” pode ser crítico no seu contexto específico.

• “Vamos ignorar as que têm CVSS < 7.0” → Você vai descobrir que metade das suas breaches vieram de CVEs abaixo dessa linha.

O que começa a funcionar é:

• Automação de scanning contínuo — não mensal, não trimestral. Contínuo.

• Priorização contextual baseada em dados — seu risco real, não o CVSS genérico.

• Correlação automática — “esse CVE está em código que toca dados de clientes? Eleva de media para critical.”

• Human in the loop — mas estratégico. Humanos revisam exceções, validam recomendações, tomam decisões de negócio. Não fazem scanning manual.

O Que a Indústria Está Começando a Fazer

As organizações mais maduras em AppSec já começaram a responder:

1. Orquestração de ferramentas Não é SAST ou SCA. É SAST + SCA + DAST + análise comportamental + inteligência de ameaças. Tudo alimentando um dashboard unificado que faz correlação automática.

2. Modelos de risco dinâmicos Em vez de um CVSS fixo, o risco muda com o contexto: a biblioteca vulnerável está em produção? Quem tem acesso a ela? Há detectores de anomalia observando aquele componente?

3. Correção automática quando possível Não é só identificar. É corrigir: patches automáticos, bumps de versão sugeridos, reescritas de código oferecidas (com revisão humana).

4. Compliance como subproduto Se você tem visibilidade contínua e priorização inteligente, compliance (BACEN, PCI-DSS, SOX) é automaticamente mais fácil, você tem o histórico de o quê, quando, por quê.

O Que Uma Empresa Deve Fazer Agora

Se você está enfrentando esse cenário, a recomendação não é heroica, é pragmática:

1. Mapeie sua baseline hoje

Antes de fazer qualquer coisa, saiba: quantas dependências você tem? Quantas delas têm vulnerabilidades conhecidas? Qual é a distribuição de severidade? Sem baseline, não há priorização, só caos.

2. Automatize o scanning

Não negocie isso. Se seu pipeline de CI/CD não está rodando análise de segurança em todo commit, você está acumulando débito.

3. Escolha ferramental com inteligência sobre contexto

Não basta “encontrar vulnerabilidades”. Ferramentas que conseguem correlacionar risco com sua exposição real (código que roda em produção, que toca dados sensíveis, que é acessado externamente) reduzem o ruído exponencialmente.

4. Estruture priorização inteligente

Trabalhe com a área de segurança para definir: qual é o seu real apetite de risco? Em quais ativos não é aceitável desvio? Onde há folga? Com essas respostas, modelos de priorização tornam-se possíveis.

5. Invista em treinamento, não em heroísmo

Equipes que entendem por que uma vulnerabilidade importa no contexto específico delas conseguem tomar decisões melhores (incluindo “vamos aceitar esse risco”) do que equipes que recebem listas genéricas.

6. Integre humanos em pontos de decisão, não em pontos de entrada

Deixe máquinas fazerem triagem, correlação e sugestão. Coloque humanos para validar exceções, explicar tradeoffs, assinar decisões de risco.

A Realidade que Está Aqui

O vulpocalipse não é um cenário futuro. É hoje.

Empresas que enxergam volume crescente de vulnerabilidades como um sinal de que seus processos viraram obsoletos, saem na frente. Empresas que tentam escalar processos manuais vão se afogar.

A boa notícia? A tecnologia para navegar isso existe. A orquestração AppSec com inteligência contextual, automação e priorização inteligente não é ficção científica. Está aqui, operacional, reduzindo risco em tempo real.

A pergunta agora é: “como eu navego o volume, priorizo efetivamente, e reduzo meu tempo de exposição?”

Responder essa pergunta exige equipamento moderno, estrutura de dados clara, e humanos focados em decisão, não em entrada de dados.

Está na hora de equipar seu time.

Assista nosso Webinar com a Conviso, onde abordamos esse tema e muitos outros

Fontes e Referências

• MITRE CVE Report 2024–2026: dados de volume de CVEs

• Daniel Stenberg (cURL maintainer): discussão pública sobre velocidade de descoberta vs. correção, 2025

• Anthropic disclosure (2026): caso de estudo de ciclo de descoberta e correção acelerado via análise contínua

• Convenção: discussão sobre orquestração AppSec e correlação de risco contextual na prática

O que a maioria dos times de engenharia não consegue responder

Existe uma pergunta simples que a maioria dos líderes de engenharia não consegue responder com dados: o que meu time está entregando, com qual qualidade, e onde estão os riscos?

Não por falta de esforço. Por falta de fonte.

O que existe hoje, na maior parte das organizações, são dashboards montados manualmente, velocity como proxy de saúde, e reuniões onde os dados apresentados são os que o time conseguiu levantar na semana anterior. Segundo o relatório Port 2025, cerca de 50% dos engenheiros não confiam nos dados que a própria empresa usa para medir a engenharia — e 53% das organizações que rastreiam métricas ainda fazem isso de forma manual.

O resultado tem um nome: teatro de métricas. Os números existem para reportar, não para decidir.

Mas esse é só o primeiro problema. Embaixo dele, existem outros dois que crescem em silêncio.

O conhecimento que ninguém documenta — e o risco que isso representa

Pesquisas mostram que 58% do tempo dos desenvolvedores é gasto lendo e entendendo código existente — não escrevendo código novo. Isso não é ineficiência individual. É o custo estrutural de sistemas que cresceram sem documentação acompanhando.

Todo mundo sabe que documentação é necessária. E quase ninguém tem tempo de fazer. Dados de mercado mostram que menos de 3% do dia de um desenvolvedor é dedicado a documentação, e apenas 1% das atividades de PR incluem atualização de docs. Não porque o time é negligente — porque documentar manualmente compete com entregar, e entregar sempre ganha.

O efeito acumulado é a dívida técnica consumindo, em média, 42% da capacidade produtiva dos times de engenharia — horas por semana gastas em manutenção de código que ninguém tem contexto suficiente para tocar com confiança.

E quando esse contexto está concentrado em poucas pessoas, o risco fica ainda mais concreto. 65% dos repositórios dependem de no máximo duas pessoas para manter o conhecimento ativo sobre aquele código. Quando uma delas sai, o time leva meses para recuperar o que foi embora com ela — porque o conhecimento nunca foi do repositório, foi da pessoa.

70% das organizações levam mais de um mês para colocar um desenvolvedor novo em produção. Parte desse tempo é onboarding inevitável. Mas boa parte é tempo gasto tentando entender um sistema que não se explica sozinho.

Três problemas. Uma mesma raiz.

Teatro de métricas, documentação inexistente e conhecimento concentrado parecem problemas separados. Mas têm a mesma causa: a engenharia não tem uma fonte de verdade contínua sobre si mesma.

O repositório contém tudo — cada decisão de arquitetura, cada padrão adotado, cada hotspot de risco, cada sinal de qualidade. O que falta é uma forma de lê-lo de maneira estruturada, contínua e sem exigir disciplina extra do time.

Quer entender o que o WeLuvCode encontra na sua engenharia? Conheça a plataforma

O que muda quando o repositório vira fonte de verdade

O WeLuvCode conecta ao repositório e, a cada novo merge, mantém três frentes atualizadas automaticamente — sem instrumentação no time, sem mudança de processo.

Na frente de saúde da engenharia, indicadores de fluxo, qualidade, eficiência e riscos são calculados do código real e atualizados a cada entrega. Frameworks DORA e SPACE calibrados para o contexto brasileiro. O Engineering Manager para de montar planilha. O CTO para de apresentar velocity como proxy de saúde. A liderança passa a apresentar dados que a própria engenharia reconhece como verdadeiros.

Na frente de conhecimento, o WeLuvCode faz engenharia reversa a cada merge: sete frentes de documentação — arquitetura, regras de negócio, dependências, segurança e mais — são regeneradas automaticamente. O contexto técnico do sistema vira ativo da empresa, não informação na cabeça de quem escreveu. Uma busca semântica cross-repo responde em segundos perguntas que hoje custam horas: “onde tem código que valida CNPJ?”, “quais são os pontos de atenção desse repositório?”, “como está a engenharia este mês?”.

Na frente de ação, o conhecimento extraído vira produto: planos de onboarding de 90 dias construídos a partir do código real, por contexto e squad, e descrições de vagas com a stack real do time. Novos desenvolvedores chegam com um caminho

estruturado — não com uma pilha de documentação desatualizada para decifrar sozinhos. Os seniores param de ser a única fonte de verdade sobre o sistema.

O repositório continua sendo o mesmo. O que muda é o que a organização consegue ver nele.

Veja como o WeLuvCode funciona na prática.

CONHEÇA A SOLUÇÃO

Fontes: Port 2025 Engineering Benchmark · Xia et al., IEEE Transactions on Software Engineering (2017) · GitLab Global DevSecOps Report (2024) · Jellyfish State of Engineering (2021) · Stripe Engineering Productivity Research · CISQ Cost of Poor Software Quality · Avelino et al., ICPC 2016 · SmartBear/Cisco Code Review Study · Frameworks DORA e SPACE

A Duranium publicou o onepager do WeLuvCode, sua plataforma de inteligência de engenharia. O material apresenta o produto em três blocos: o problema (custo da engenharia invisível, embasado em seis estudos públicos), o que a plataforma entrega (três frentes integradas: saúde da engenharia, conhecimento que não se perde e ações que liberam seniores) e como funciona na operação (contínuo, cross-repo, seguro por contexto e com zero fricção pro time).

Este post resume o conteúdo do onepager e contextualiza por que o problema que o WeLuvCode endereça importa agora — especialmente em times que estão adotando IA na engenharia em ritmo superior à sua capacidade de absorver contexto.

→ Acessar o onepager

O custo da engenharia invisível

Times de engenharia produzem contexto crítico todos os dias — e raramente conseguem capturá-lo de forma estruturada. O conhecimento fica na cabeça de quem escreveu o código. A liderança decide com base em estimativa. Quem chega ao time gasta semanas em arqueologia antes de contribuir de forma efetiva.

Seis estudos públicos documentam a dimensão desse problema.

Desenvolvedores profissionais gastam 58% do tempo lendo e compreendendo código existente — não escrevendo código novo (Xia et al., IEEE Transactions on Software Engineering, 2017).

Em 70% das organizações, colocar um dev novo em produção leva mais de um mês (GitLab Global DevSecOps Report, 2024).

Em 65% dos repositórios analisados no GitHub, o conhecimento técnico está concentrado em no máximo duas pessoas — uma demissão ou licença basta para que ele saia pela porta (Avelino et al., ICPC 2016). E código com ownership fraco apresenta seis vezes mais bugs do que código com ownership forte (Microsoft Research, MSR 2011–2015).

A leitura combinada desses dados aponta para o mesmo lugar: o conhecimento crítico está concentrado, o contexto técnico não é capturado de forma estruturada e a liderança toma decisões sem visibilidade real do que está acontecendo na engenharia.

Por que esse problema ficou mais urgente agora

A adoção acelerada de IA na engenharia aprofundou o desafio. O Google Cloud/DORA Accelerate State of DevOps Report 2024, com respostas de mais de 39 mil profissionais, identificou que 76% já usam IA para escrever, explicar ou documentar código. A produção de código acelerou. Mas o mesmo relatório registrou que 39% dos profissionais desconfiam do código gerado por IA — e que adoção de IA correlacionou com piora em métricas de entrega de software, não melhora.

O padrão é direto: enquanto a IA amplia a velocidade de produção, a capacidade dos times de absorver, revisar e manter esse código não cresce na mesma proporção. Em times onde o contexto técnico já estava mal documentado, essa pressão chega num sistema que não estava preparado para absorvê-la.

O que está no Onepager

O material detalha as três frentes que o WeLuvCode cobre, como cada uma opera na prática e o que muda para liderança e times de engenharia. Inclui os seis dados públicos com fontes, exemplos de tela e os princípios operacionais que diferenciam a plataforma de ferramentas tradicionais de métricas ou documentação.

Para times que quiserem ir além do material, a Duranium está abrindo pilotos de 15 dias com repositórios reais, sem custo. Ao final, o time vê o que o WeLuvCode encontrou sobre sua própria engenharia. A decisão de seguir é do cliente.

→ Baixar o onepager

→ Iniciar um piloto: contato@duranium.io

Fontes: Xia et al., IEEE TSE, 2017 · GitLab Global DevSecOps Report, 2024 · Avelino et al., ICPC 2016 · Microsoft Research, MSR 2011–2015 · Google Cloud/DORA Accelerate State of DevOps Report, 2024

Compartilhar

A aceleração que criou um novo gargalo

Nos últimos dois anos, a adoção de ferramentas de IA para codificação passou de experimento a padrão. Mais de 75% dos times de engenharia já trabalham com algum nível de assistência de IA no dia a dia — e o efeito mais imediato aparece no volume: mais código escrito, mais pull requests abertos, ciclos de entrega mais curtos.

O problema é que code review não acompanhou esse ritmo. Revisar código continuou sendo um trabalho humano, sequencial, que depende de quem entende o contexto da codebase. E o volume de PRs que chegou para revisão praticamente dobrou em muitas equipes.

O resultado prático: os mesmos engenheiros seniores que antes já tinham pouco tempo disponível passaram a ser o principal ponto de contenção do processo. A IA acelerou a geração de código. O gargalo só mudou de lugar.

O que os dados de qualidade estão registrando

Mais código entrando não significa necessariamente melhor código entrando. Ferramentas de IA são boas em produzir código que funciona na superfície — que compila, passa em testes básicos, parece correto numa leitura rápida. O que elas costumam ignorar são os padrões internos da codebase, as decisões de arquitetura que não estão documentadas, as dependências que só quem trabalha no repositório há meses conhece.

O efeito acumulado aparece em métricas de qualidade pós-merge: a taxa de code churn — código reescrito ou descartado pouco depois de entrar — praticamente dobrou entre 2020 e 2024, segundo análise do GitClear após análise de 211 milhões de linhas de código. O Cortex Engineering Benchmarks 2026 registrou crescimento de 23,5% em incidentes por PR e 30% na taxa de falha de mudanças em equipes com alta adoção de IA sem controles de qualidade correspondentes.

Temos mais output individual mas, ao mesmo tempo, uma entrega organizacional que não melhora na mesma proporção.

O que o board está cobrando — e por que a resposta não vem

Enquanto o time lida com volume e qualidade, a liderança enfrenta uma pressão diferente: demonstrar retorno sobre o investimento em IA.

O problema é que as métricas disponíveis não respondem essa pergunta com precisão. Taxa de aceitação de sugestões, linhas de código geradas — medem atividade, não impacto. Não dizem se a base de código está mais saudável, se os incidentes diminuíram, se o time está de fato entregando com mais qualidade.

Resultado: 71% dos CIOs e CTOs dizem que as expectativas do board sobre ROI de IA são irreais — porque não conseguem demonstrá-lo com dados concretos, segundo pesquisa da Solvd com a Wakefield (2025). Decisões sobre investimento em ferramentas continuam sendo tomadas com base em percepção.

O paradoxo em números

O paradoxo é mensurável: devs acham que são 24% mais rápidos com IA, mas uma pesquisa da METR mostrou que, em tarefas reais de repositório, a velocidade caiu 19%. Mais output individual, entrega organizacional estagnada.

Nesse caso, a percepção e a realidade foram em direções opostas — e ninguém que participou do estudo percebeu enquanto acontecia.

Isso não significa que IA não funciona. Significa que o impacto é mais complexo do que parece e que medi-lo com as ferramentas erradas leva a conclusões erradas.

O que falta não é dado — é leitura

O repositório registra tudo. Cada merge, cada reversão, cada trecho de código que entrou e saiu em duas semanas, cada PR aprovado sem revisão real. Os sinais estão lá — o que falta é uma forma de lê-los de maneira contínua, sem exigir que alguém monte um dashboard manualmente toda semana.

É exatamente o que o WeLuvCode faz. A plataforma conecta ao repositório e, a cada novo merge, agentes especializados analisam o que mudou: as métricas se atualizam, os hotspots ficam visíveis, e a documentação se regenera automaticamente — sem instrumentação no time, sem mudança de processo.

Na frente de saúde da engenharia, indicadores de fluxo, qualidade, eficiência e riscos são calculados do código real e atualizados a cada entrega. Se o throughput sobe sem que a qualidade acompanhe, aparece nos dados. Se a revisão está concentrada em duas pessoas, aparece nos dados. Se o código gerado por IA está sendo validado de verdade ou apenas aprovado, aparece nos dados.

Na frente de conhecimento, o contexto técnico do sistema — arquitetura, regras de negócio, dependências — vira ativo da empresa, não informação na cabeça de quem escreveu. Uma busca semântica cross-repo responde em segundos perguntas que hoje custam horas de investigação manual.

E na frente de ação, o conhecimento extraído dos repositórios vira plano de onboarding por contexto e descrição de vagas com a stack real do time — liberando os seniores do papel de única fonte de verdade sobre o sistema.

A liderança passa a ter o que estava faltando: não mais volume como proxy de saúde, mas evidência real sobre o que está sendo entregue — e com qual qualidade.

Compartilhar

Fontes: Faros AI — AI Productivity Paradox Report (2025) · GitClear — AI Copilot Code Quality Report (2025) · Cortex — Engineering in the Age of AI: 2026 Benchmark Report · METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025) · Solvd/Wakefield Research — CIO & CTO Insights: AI Research (2025) · DX Report: How Top Companies Measure AI (2025)

A AWS quase protagonizou um grande incidente de supply chain. Um atacante chegou ao repositório oficial do Amazon Q Developer, embutiu um payload destrutivo em um release legítimo, e o código foi distribuído para quase 1 milhão de instalações.

O que impediu o estrago não foi detecção. Não foi controle de integridade. Não foi resposta a incidente.

Foi um erro de sintaxe no código malicioso.

Essa é a parte que não deveria passar despercebida.

Assine agora

Três vetores. Nenhum sendo observado.

O ataque combinou uma credencial com escopo excessivo no pipeline de CI/CD, ausência de controles efetivos de integridade no fluxo de release, e um terceiro vetor que praticamente nenhuma empresa está preparada para tratar: prompt injection indireta em um agente com acesso amplo ao ambiente de desenvolvimento.

Cada um desses vetores tem fornecedor, tem ferramenta, tem framework há anos. Tê-los instalados e tê-los efetivamente operando, no entanto, são coisas diferentes — e o denominador comum dos três foi a ausência de alguém olhando.

Por que AI coding assistants mudam o jogo

Uma extensão tradicional de IDE tem escopo previsível, ações específicas e raio de dano local. Um agente de AI coding interpreta linguagem natural, decide o que fazer e age sobre o ambiente: cria arquivos, executa comandos, conversa com a cloud. O escopo é dinâmico. O raio de dano deixa de ser local — passa a alcançar o pipeline e a conta cloud inteira.

Isso transforma cada AI coding assistant em software privilegiado. E exige uma camada de visibilidade que poucas empresas construíram.

O ponto cego: o painel da operação de engenharia

Ferramentas pontuais resolvem suas camadas bem. Nenhuma delas responde à pergunta que o CTO precisa responder na segunda de manhã: o que está acontecendo no meu código? Não no nível do alerta — no nível do padrão.

Quantas mudanças entraram nos repositórios críticos esta semana? Onde a profundidade de revisão caiu? O que o agente de IA está modificando com mais frequência? Onde o conhecimento dos módulos críticos está concentrado em uma única pessoa?

Essa é a camada que o incidente da AWS expôs como ausente — e onde Engineering Intelligence opera.

Sorte não escala

Mesmo a AWS só não sofreu dano maior porque o atacante errou a sintaxe. Operar engenharia hoje sem visibilidade contínua é construir sobre sorte.

→ Baixe o whitepaper completo: a análise técnica dos três vetores, o framework de visibilidade da camada de Engineering Intelligence e como o WeLuvCode operacionaliza isso na prática antes que sua empresa precise da mesma sorte.

Baixar o whitepaper completo

A conferência Black Hat Asia deste ano em Singapura trouxe uma das palestras mais equilibradas e provocativas da temporada de eventos de segurança. Ari Herbert-Voss, CEO da RunSybil e ex-primeira contratação de segurança da OpenAI — onde liderou os red teams dos modelos GPT-3 e Codex —, apresentou um panorama técnico sobre o que modelos de linguagem de grande escala (LLMs) realmente mudam no cenário ofensivo. E, mais importante: o que ainda não mudaram.

O resumo direto: a IA está acelerando a descoberta de vulnerabilidades de forma significativa. Isso tem implicações concretas para qualquer time de engenharia que ainda trata segurança como uma etapa pós-desenvolvimento.

O paralelo com o fuzzing — e por que ele importa

Herbert-Voss abre sua análise com um paralelo histórico útil. Nos anos 2000, o fuzzing foi recebido como uma tecnologia que tornaria pesquisadores de vulnerabilidades obsoletos — uma ferramenta que encontraria falhas em escala, automaticamente, sem esforço humano. O que aconteceu de fato foi diferente: o fuzzing criou um volume enorme de possíveis bugs, mas alguém ainda precisava triá-los, identificar os exploráveis e entender a causa raiz.

“De certa forma, o fuzzing tornou os pesquisadores de vulnerabilidades mais valiosos”, disse Herbert-Voss.

O mesmo padrão está se repetindo com LLMs. Modelos como o Mythos (Anthropic) conseguem gerar datasets massivos, confirmar anomalias e sugerir formas de exploração — mas a validação de quais achados têm impacto real de segurança ainda exige julgamento humano. “Equipes podem gerar mais bugs possíveis do que nunca. Validar quais têm impacto real de segurança ainda requer um humano. Esse gap é o problema”, afirma o especialista.

Os números que mudam a conversa

Há um dado no artigo que merece atenção particular de qualquer engineering manager ou responsável por produto:

Entre 2023 e 2026, o tempo médio entre a descoberta de uma vulnerabilidade e sua exploração caiu de cinco meses para dez horas.

Isso não é uma projeção especulativa — é uma mudança observável no comportamento de ameaças reais. Em competições profissionais de capture-the-flag (CTF), desafios que antes levavam horas para times especializados estão sendo resolvidos em minutos por jogadores usando ferramentas agênticas.

A aceleração não é uniforme entre todos os tipos de vulnerabilidade: modelos como o Mythos apresentam ganhos expressivos na descoberta de bugs “rasas” de baixa severidade, ganhos moderados para falhas de nível intermediário, e ganhos limitados para as mais complexas. Mesmo assim, o volume aumentado de detecções automatizadas coloca pressão constante sobre as equipes de defesa.

O que isso significa na prática para times de desenvolvimento

Herbert-Voss é direto: “Em breve será o caso de que organizações simplesmente não conseguirão entregar código com bugs sem que esses bugs sejam encontrados e explorados rapidamente.”

É aqui que entra o conceito de shift left — e vale explicar o que isso significa na prática.

Shift left é a ideia de mover as verificações de segurança e qualidade para mais cedo no ciclo de desenvolvimento — ou seja, para a “esquerda” do pipeline, mais próximas do momento em que o código é escrito. Em vez de testar e auditar no final, antes do deploy, a lógica é: detectar problemas enquanto o desenvolvedor ainda está com o contexto fresco, o custo de correção é baixo e a janela de exposição ainda não se abriu.

Com a aceleração que Herbert-Voss descreve, essa prática deixa de ser uma recomendação de boas práticas e passa a ser uma resposta estrutural a um cenário concreto: bugs que chegam à produção têm cada vez menos tempo de vida antes de serem explorados.

Quatro capacidades técnicas foram destacadas como prioritárias para times que querem se posicionar bem nesse novo ritmo:

1. Raciocínio aprofundado — Grande parte da segurança envolve lógica causal: como isso funciona? Como pode quebrar? Se X acontece, o que isso implica?

2. Uso eficaz de ferramentas — Agentes precisam conseguir interagir com sistemas reais para provar que uma vulnerabilidade existe. Agentes modernos já são consideravelmente melhores nisso.

3. Engenharia de “harness” de qualidade — Agentes têm janelas de contexto limitadas. Para trabalhar bem, precisam receber acesso ao contexto certo, com o escopo certo e as ferramentas certas. Isso é uma disciplina de engenharia, não só uma configuração.

4. Sistemas ao redor do harness — Um único agente com bom contexto tem limite. A efetividade real vem de múltiplos agentes trabalhando em conjunto, com comunicação bem estruturada entre eles.

O que o WeLuvCode tem a ver com isso

Existe uma conexão direta entre o que Herbert-Voss descreve e o problema que o WeLuvCode foi construído para resolver.

Quando ele fala que “organizações simplesmente não conseguirão entregar código com bugs sem que esses bugs sejam encontrados e explorados”, está descrevendo um novo patamar de exigência sobre a qualidade do que sai dos repositórios dos times de engenharia. A janela de tolerância está encolhendo.

O WeLuvCode atua precisamente nesse ponto crítico: integrado diretamente ao fluxo de trabalho do time de produto e desenvolvimento, ele aciona agentes a cada novo Pull Request submetido — validando segurança, padrões de codificação, boas práticas e regras específicas do repositório antes que qualquer mudança avance no pipeline. A cada push, os agentes validam funcionalmente a mudança. Issues recebem melhoria automática de especificação.

Esse modelo de revisão contínua e integrada ao ciclo de desenvolvimento não é apenas uma conveniência — é uma resposta estrutural ao tipo de pressão que Herbert-Voss descreve. Quanto mais cedo uma vulnerabilidade é identificada no ciclo de desenvolvimento, menor o custo de correção e menor a janela de exposição.

Dados internos do WeLuvCode apontam que 40% do código gerado com auxílio de IA contém mais vulnerabilidades do que código escrito manualmente — dado que reforça a necessidade de validação sistemática, especialmente em ambientes onde o uso de copilotos de código está se tornando padrão.

Uma oportunidade, não só uma ameaça

Herbert-Voss conclui sua palestra com uma perspectiva que vale ser registrada. Apesar de toda a aceleração ofensiva, ele enxerga na democratização dos modelos de fronteira também uma oportunidade para defensores: construir defesas em múltiplas camadas, priorizar patches, e finalmente executar as práticas de segurança que já deveriam ter sido implementadas.

“Há muito mais oportunidade de focar na construção de defesas em múltiplas camadas e na aplicação de patches — e usar essa energia e esse momentum para fazer muitas das coisas que provavelmente já deveríamos ter feito antes.”

O momento atual pede menos especulação sobre cenários apocalípticos e mais ação nos fundamentos: código mais seguro, revisão mais próxima do ponto de escrita, e times de engenharia com contexto técnico para tomar decisões melhores.

É nesse espaço que ferramentas como o WeLuvCode fazem sentido — não como uma solução definitiva, mas como uma camada de inteligência que desloca a detecção para onde ela é mais barata e mais eficaz: antes do merge.

Quer saber como o WeLuvCode se integra ao fluxo do seu time de desenvolvimento?

[Fale com a Duranium.]

Em janeiro de 2026, a Anthropic publicou uma pesquisa controlada randomizada com desenvolvedores de software investigando uma pergunta que muita gente já se fazia em voz baixa: usar IA durante o aprendizado ajuda ou atrapalha?

A resposta curta: depende completamente de como você usa.

O estudo identificou seis padrões distintos de uso da IA. Três deles levaram a notas até 86% mais altas nos testes de compreensão. Os outros três resultaram em aprendizado medíocre — e um deles, o pior de todos, deixou o dev mais lento e com menos conhecimento ao mesmo tempo.

O dado que mais chama atenção: participantes que usaram IA durante o aprendizado tiraram, em média, nota 17% menor do que os que codificaram manualmente. Mas isso só vale para quem usou IA sem critério. Os que souberam usar a ferramenta com intenção chegaram exatamente ao resultado oposto.

Esse é o ponto central: não é se você usa IA. É como você usa.

A partir dessa pesquisa, a Duranium organizou um guia com 10 dicas práticas para devs que estão começando a carreira agora, mas também para quem já está na carreira. O material cobre desde padrões de uso da IA que preservam o aprendizado até mentalidade de segurança — uma lacuna que o próprio estudo aponta como crítica, já que cerca de 45% do código gerado por IA contém vulnerabilidades identificáveis.

Você pode ler e baixar o guia completo aqui: https://content.duranium.io/10-dicas_carreira_engenharia_software_ia

Abaixo, um resumo dos principais aprendizados.

Os padrões que funcionam (e os que não funcionam)

O que prejudica o aprendizado:

• Delegar tudo para a IA sem tentar entender o código gerado (AI Delegation — 39% no quiz)

• Começar fazendo perguntas, mas na segunda tarefa já entregar tudo para a IA (Progressive AI Reliance — 35%)

• Ficar num loop de “IA, debugga isso” sem entender o erro (Iterative AI Debugging — 24% e o mais lento de todos)

O que preserva o aprendizado:

• Gerar o código com IA e depois perguntar “me explica o que esse código faz” (Generation-then-Comprehension — 86%)

• Pedir código e explicação na mesma query (Hybrid Code-Explanation — 68%)

• Fazer apenas perguntas conceituais e implementar por conta própria (Conceptual Inquiry — 65%, e o segundo mais rápido)

A diferença não está no acesso à ferramenta. Está na postura de quem usa.

Por que segurança entra nessa conversa

Uma das dicas do guia que mais gera reação é a dica 9: cultive mentalidade de segurança desde o início.

Não por alarmismo. Mas porque o código gerado por IA chega com vulnerabilidades reais que um dev sem base em AppSec não vai identificar. OWASP Top 10, validação de inputs, gerenciamento de secrets — esses fundamentos precisam andar em paralelo com o aprendizado de IA, não depois.

O guia completo explora isso (e as outras 9 dicas) com contexto, exemplos e referências úteis.

📥 Leia e baixe gratuitamente: https://content.duranium.io/10-dicas_carreira_engenharia_software_ia

Compartilhar