{"id":36473,"date":"2026-03-23T13:43:15","date_gmt":"2026-03-23T16:43:15","guid":{"rendered":"https:\/\/building.nubank.com\/?p=36473"},"modified":"2026-03-25T10:04:35","modified_gmt":"2026-03-25T13:04:35","slug":"construindo-agentes-de-ia-para-127-milhoes-de-clientes","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/pt-br\/construindo-agentes-de-ia-para-127-milhoes-de-clientes\/","title":{"rendered":"Construindo agentes de IA para 131 milh\u00f5es de clientes"},"content":{"rendered":"\n

Written by: Aman Gupta<\/a><\/em>, <\/em><\/a>Daniel Braithwaite<\/a><\/em><\/p>\n\n\n\n

No universo de alto risco das finan\u00e7as globais, a margem para erro \u00e9 zero. No Nu, atendemos 131 milh\u00f5es de clientes no Brasil, M\u00e9xico e Col\u00f4mbia. Para um neobank dessa escala, a era do \u201cchatbot\u201d j\u00e1 ficou para tr\u00e1s. Nosso desafio agora \u00e9 ir al\u00e9m da simples recupera\u00e7\u00e3o de respostas de FAQ e construir sistemas aut\u00f4nomos capazes de lidar com renegocia\u00e7\u00e3o de d\u00edvidas, log\u00edstica de cart\u00f5es e preven\u00e7\u00e3o a fraudes, sempre mantendo a confian\u00e7a absoluta de uma base de clientes que espera suporte imediato, emp\u00e1tico e factualmente correto.<\/p>\n\n\n\n

Minha perspectiva vem de mais de uma d\u00e9cada trabalhando em empresas como Apple, Amazon e LinkedIn, al\u00e9m de uma forte conex\u00e3o com a comunidade de pesquisa, com publica\u00e7\u00f5es em confer\u00eancias como NeurIPS, ICML e ICLR. Como criador do Quant Ease, o primeiro algoritmo de quantiza\u00e7\u00e3o em larga escala baseado em coordinate descent<\/em>, e pesquisador em alinhamento de prefer\u00eancias para LLMs, aprendi que a \u201cm\u00e1gica\u201d dos agentes de IA \u00e9, na verdade, um problema de infraestrutura. Para construir agentes que funcionem para centenas de milh\u00f5es de usu\u00e1rios, \u00e9 preciso abandonar a \u201cbruxaria de prompts\u201d e adotar o rigor arquitetural.<\/p>\n\n\n\n

Estas s\u00e3o cinco das li\u00e7\u00f5es mais dif\u00edceis que aprendemos construindo agentes de IA em produ\u00e7\u00e3o.<\/p>\n\n\n\n

1. A abordagem “Evals-First”: de NPS para TNPS<\/h2>\n\n\n\n

M\u00e9tricas tradicionais podem ser uma armadilha no desenvolvimento de IA. Muitas organiza\u00e7\u00f5es usam o Net Promoter Score (NPS) para medir sucesso, mas em ambientes de suporte de alto volume o NPS funciona mal. A taxa de resposta costuma ser baixa, o feedback chega com dias de atraso e a amostra n\u00e3o tem poder estat\u00edstico suficiente para ciclos r\u00e1pidos de testes A\/B.<\/p>\n\n\n\n

Para escalar, \u00e9 preciso migrar para TNPS (Transactional Net Promoter Score)<\/strong>, avaliando a intera\u00e7\u00e3o espec\u00edfica com a IA imediatamente, e complementar isso com um framework de \u201cLLM-as-a-judge\u201d. Ao inv\u00e9s de esperar por uma pesquisa que talvez nunca seja respondida, usamos um segundo LLM, atuando como auditor, para avaliar 100% das conversas com base em crit\u00e9rios bin\u00e1rios:<\/p>\n\n\n\n

    \n
  • Corretude: <\/strong>a resposta do agente contradiz nossa base de conhecimento interna?<\/li>\n\n\n\n
  • Concis\u00e3o: <\/strong>o agente entregou uma resposta direta ou um \u201cmuro de texto\u201d?<\/li>\n\n\n\n
  • Alinhamento de prefer\u00eancia: <\/strong>o agente respeitou a vers\u00e3o de tom e estilo definida para aquele mercado?<\/li>\n<\/ul>\n\n\n\n

    Ao sair de uma pequena amostra de pesquisas para uma auditoria completa das intera\u00e7\u00f5es, conseguimos iterar diariamente sobre diferentes variantes. Como diz o princ\u00edpio b\u00e1sico: se voc\u00ea n\u00e3o mede, n\u00e3o consegue melhorar<\/em>.<\/p>\n\n\n\n

    2. Redefinindo o que \u00e9 um agente: o paradigma ReAct<\/h2>\n\n\n\n

    A palavra \u201cagente\u201d hoje est\u00e1 cercada de muito ru\u00eddo. Em produ\u00e7\u00e3o, um agente n\u00e3o \u00e9 apenas um gerador de texto, \u00e9 um sistema aut\u00f4nomo que segue o paradigma ReAct (Reasoning and Acting)<\/strong>. Ou seja, um \u201cc\u00e9rebro\u201d que raciocina e um conjunto de ferramentas que executam a\u00e7\u00f5es para resolver tarefas de ponta a ponta.<\/p>\n\n\n\n

    Arquiteturalmente, definimos o agente em tr\u00eas camadas:<\/p>\n\n\n\n

      \n
    • Prompt (o c\u00e9rebro):<\/strong> o motor de racioc\u00ednio que decide qual ser\u00e1 o pr\u00f3ximo passo.<\/li>\n\n\n\n
    • Ferramentas (as m\u00e3os\/APIs):<\/strong> a\u00e7\u00f5es determin\u00edsticas, como check_delivery_status ou trigger_debt_renegotiation.<\/li>\n\n\n\n
    • Dados (a mem\u00f3ria):<\/strong> A camada de RAG (Retrieval-Augmented Generation) e o contexto da sess\u00e3o que conectam o modelo ao hist\u00f3rico real do cliente.<\/li>\n<\/ul>\n\n\n\n

      Se o seu sistema n\u00e3o consegue executar uma a\u00e7\u00e3o no mundo real (como reenviar um cart\u00e3o perdido ou atualizar um limite de cr\u00e9dito) ent\u00e3o ele n\u00e3o \u00e9 um agente. \u00c9 apenas uma interface de busca.<\/p>\n\n\n\n

      3. Pare de escrever prompts: a era da otimiza\u00e7\u00e3o de prompts<\/h2>\n\n\n\n

      Uma das conclus\u00f5es mais contraintuitivas que encontramos \u00e9 que humanos s\u00e3o ruins em escrever prompts para produ\u00e7\u00e3o. Prompts escritos manualmente tendem a ser fr\u00e1geis e altamente dependentes do modelo.<\/p>\n\n\n\n

      J\u00e1 observamos situa\u00e7\u00f5es em que migrar para modelos de nova gera\u00e7\u00e3o (por exemplo, sair do GPT-4 para modelos mais avan\u00e7ados de racioc\u00ednio) quebra agentes existentes. Isso acontece porque modelos mais inteligentes fazem menos suposi\u00e7\u00f5es impl\u00edcitas, eliminando \u201cajudas invis\u00edveis\u201d das quais o prompt dependia.<\/p>\n\n\n\n

      Para lidar com isso, usamos Prompt Optimization<\/strong> e Semantic Versioning<\/strong>. Tratamos prompts como c\u00f3digo, dividindo-os em m\u00f3dulos (por exemplo: Tone, Tooling, Safety) que evoluem de forma independente.<\/p>\n\n\n\n

      Utilizamos frameworks como DSPy<\/strong> e o otimizador Japa<\/strong>, desenvolvido em Berkeley. Nesse fluxo, o papel humano muda:<\/p>\n\n\n\n

        \n
      1. O humano define o objetivo:<\/strong> define os crit\u00e9rios de sucesso de entrada e sa\u00edda.<\/li>\n\n\n\n
      2. O humano rotula os exemplos:<\/strong> fornece de 50 a 100 intera\u00e7\u00f5es de alta qualidade.<\/li>\n\n\n\n
      3. A m\u00e1quina otimiza:<\/strong> o otimizador itera sobre o texto do prompt para encontrar o conjunto de instru\u00e7\u00f5es mais eficiente para aquele modelo.<\/li>\n<\/ol>\n\n\n\n

        Se voc\u00ea est\u00e1 escrevendo prompts de cinco p\u00e1ginas manualmente, est\u00e1 construindo um sistema que vai quebrar assim que o provedor do modelo atualizar os pesos.<\/p>\n\n\n\n

        4. N\u00e3o fa\u00e7a fine-tuning antes da hora<\/h2>\n\n\n\n

        Existe uma tend\u00eancia comum de correr direto para Supervised Fine-Tuning (SFT) ou Reinforcement Learning (RL). Apesar de minha pesquisa se concentrar em alinhamento de prefer\u00eancias, meu conselho estrat\u00e9gico costuma ser o oposto: n\u00e3o fa\u00e7a fine-tuning at\u00e9 extrair tudo o que os modelos de ponta j\u00e1 conseguem fazer<\/strong>.<\/p>\n\n\n\n

        Seu verdadeiro diferencial competitivo raramente est\u00e1 nos pesos do modelo. Ele est\u00e1 nas camadas de dados e a\u00e7\u00e3o<\/strong>. Fine-tuning tamb\u00e9m traz riscos arquiteturais relevantes:<\/p>\n\n\n\n

          \n
        • Model Drift:<\/strong> melhorar o modelo para uma tarefa espec\u00edfica pode degradar seu racioc\u00ednio geral.<\/li>\n\n\n\n
        • Problemas de capacidade: <\/strong>modelos menores podem \u201cesquecer\u201d regras de seguran\u00e7a ou instru\u00e7\u00f5es fora do conjunto de treinamento.<\/li>\n\n\n\n
        • Sobrecarga de manuten\u00e7\u00e3o: <\/strong>voc\u00ea passa a ser respons\u00e1vel pelo ciclo completo de desempenho do modelo.<\/li>\n<\/ul>\n\n\n\n

          A menos que voc\u00ea esteja perseguindo os \u00faltimos 5% de precis\u00e3o ou requisitos espec\u00edficos de lat\u00eancia em tarefas muito especializadas e de alto volume, o tempo de engenharia costuma ser melhor investido em ferramentas robustas.<\/p>\n\n\n\n

          5. Tire l\u00f3gica do LLM e coloque nas ferramentas<\/h2>\n\n\n\n

          Alucina\u00e7\u00f5es muitas vezes s\u00e3o resultado de pedir que o LLM execute trabalho determin\u00edstico. Se um processo tem uma sequ\u00eancia fixa, n\u00e3o pe\u00e7a ao modelo para \u201craciocinar\u201d sobre ele.<\/p>\n\n\n\n

          Um exemplo foi nosso caso de entrega de cart\u00e3o<\/strong>. Inicialmente deixamos o LLM encadear tr\u00eas ferramentas:<\/p>\n\n\n\n

          check status \u2192 verify address \u2192 trigger re-order<\/p>\n\n\n\n

          Com frequ\u00eancia, o modelo alucinava a sequ\u00eancia ou falhava no meio do fluxo. Percebemos que est\u00e1vamos pedindo ao LLM para fazer o trabalho de um script.<\/p>\n\n\n\n

          A solu\u00e7\u00e3o foi criar uma Composite Tool<\/strong>: uma \u00fanica API determin\u00edstica que executa internamente toda a l\u00f3gica de tr\u00eas etapas. O LLM s\u00f3 precisa decidir: \u201cFix Card Delivery\u201d.<\/p>\n\n\n\n

          A regra \u00e9 simples:<\/p>\n\n\n\n

          Se \u00e9 determin\u00edstico, n\u00e3o deixe o LLM fazer o trabalho.<\/p>\n\n\n\n

          Ao mover a l\u00f3gica de neg\u00f3cio para as ferramentas, reduzimos drasticamente alucina\u00e7\u00f5es e mantemos o agente como uma interface confi\u00e1vel para os servi\u00e7os de backend.<\/p>\n\n\n\n

          O blueprint: simula\u00e7\u00e3o automatizada e bug-bashing<\/h2>\n\n\n\n

          Antes que qualquer variante de agente chegue a um \u00fanico cliente, ela passa por um ambiente de Bug Bashing. Sa\u00edmos de um modelo de QA manual para um sistema de simula\u00e7\u00e3o automatizada e red teaming<\/strong>. Usando nossos dashboards internos e sistemas de rastreamento, simulamos milhares de conversas para \u201catacar\u201d o agente.<\/p>\n\n\n\n

          Monitoramos os traces<\/em>, que representam toda a cadeia de intera\u00e7\u00f5es entre mensagens do LLM, entradas do cliente e chamadas de ferramentas. Tamb\u00e9m usamos parceiros de simula\u00e7\u00e3o para testar cen\u00e1rios extremos que um testador humano talvez n\u00e3o antecipasse, garantindo que o agente n\u00e3o exponha PII ou desvie de suas responsabilidades financeiras antes de ir para produ\u00e7\u00e3o.<\/p>\n\n\n\n

          O futuro das finan\u00e7as aut\u00f4nomas<\/h2>\n\n\n\n

          Agentes de IA n\u00e3o existem para substituir nossos X-Peers, mas para ampliar seu impacto.<\/p>\n\n\n\n

          Ao resolver casos previs\u00edveis e de alto volume, como consultas frequentes ou acompanhamento de entrega de cart\u00e3o, os agentes permitem que nossos especialistas se dediquem aos problemas mais complexos, que exigem empatia financeira real e julgamento humano.<\/p>\n\n\n\n

          Essa transi\u00e7\u00e3o, por\u00e9m, exige mais do que modelos melhores. Ela exige uma mudan\u00e7a de mentalidade.<\/p>\n\n\n\n

          No setor financeiro, onde a confian\u00e7a leva anos para ser constru\u00edda e segundos para ser perdida, a \u201cm\u00e1gica\u201d da autonomia precisa estar apoiada em rigor arquitetural. No fim das contas, quem vai prosperar nessa nova era s\u00e3o as organiza\u00e7\u00f5es que tratam a confian\u00e7a do cliente como seu ativo mais valioso, garantindo que cada intera\u00e7\u00e3o automatizada seja guiada por uma medi\u00e7\u00e3o obsessiva e sistem\u00e1tica de qualidade.<\/p>\n\n\n\n

          \n