Construindo agentes de IA para 131 milhões de clientes

Written by: Aman Gupta, Daniel Braithwaite

No universo de alto risco das finanças globais, a margem para erro é zero. No Nu, atendemos 131 milhões de clientes no Brasil, México e Colômbia. Para um neobank dessa escala, a era do “chatbot” já ficou para trás. Nosso desafio agora é ir além da simples recuperação de respostas de FAQ e construir sistemas autônomos capazes de lidar com renegociação de dívidas, logística de cartões e prevenção a fraudes, sempre mantendo a confiança absoluta de uma base de clientes que espera suporte imediato, empático e factualmente correto.

Minha perspectiva vem de mais de uma década trabalhando em empresas como Apple, Amazon e LinkedIn, além de uma forte conexão com a comunidade de pesquisa, com publicações em conferências como NeurIPS, ICML e ICLR. Como criador do Quant Ease, o primeiro algoritmo de quantização em larga escala baseado em coordinate descent, e pesquisador em alinhamento de preferências para LLMs, aprendi que a “mágica” dos agentes de IA é, na verdade, um problema de infraestrutura. Para construir agentes que funcionem para centenas de milhões de usuários, é preciso abandonar a “bruxaria de prompts” e adotar o rigor arquitetural.

Estas são cinco das lições mais difíceis que aprendemos construindo agentes de IA em produção.

1. A abordagem “Evals-First”: de NPS para TNPS

Métricas tradicionais podem ser uma armadilha no desenvolvimento de IA. Muitas organizações 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ão tem poder estatístico suficiente para ciclos rápidos de testes A/B.

Para escalar, é preciso migrar para TNPS (Transactional Net Promoter Score), avaliando a interação específica com a IA imediatamente, e complementar isso com um framework de “LLM-as-a-judge”. Ao invés 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érios binários:

• Corretude: a resposta do agente contradiz nossa base de conhecimento interna?
• Concisão: o agente entregou uma resposta direta ou um “muro de texto”?
• Alinhamento de preferência: o agente respeitou a versão de tom e estilo definida para aquele mercado?

Ao sair de uma pequena amostra de pesquisas para uma auditoria completa das interações, conseguimos iterar diariamente sobre diferentes variantes. Como diz o princípio básico: se você não mede, não consegue melhorar.

2. Redefinindo o que é um agente: o paradigma ReAct

A palavra “agente” hoje está cercada de muito ruído. Em produção, um agente não é apenas um gerador de texto, é um sistema autônomo que segue o paradigma ReAct (Reasoning and Acting). Ou seja, um “cérebro” que raciocina e um conjunto de ferramentas que executam ações para resolver tarefas de ponta a ponta.

Arquiteturalmente, definimos o agente em três camadas:

• Prompt (o cérebro): o motor de raciocínio que decide qual será o próximo passo.
• Ferramentas (as mãos/APIs): ações determinísticas, como check_delivery_status ou trigger_debt_renegotiation.
• Dados (a memória): A camada de RAG (Retrieval-Augmented Generation) e o contexto da sessão que conectam o modelo ao histórico real do cliente.

Se o seu sistema não consegue executar uma ação no mundo real (como reenviar um cartão perdido ou atualizar um limite de crédito) então ele não é um agente. É apenas uma interface de busca.

3. Pare de escrever prompts: a era da otimização de prompts

Uma das conclusões mais contraintuitivas que encontramos é que humanos são ruins em escrever prompts para produção. Prompts escritos manualmente tendem a ser frágeis e altamente dependentes do modelo.

Já observamos situações em que migrar para modelos de nova geração (por exemplo, sair do GPT-4 para modelos mais avançados de raciocínio) quebra agentes existentes. Isso acontece porque modelos mais inteligentes fazem menos suposições implícitas, eliminando “ajudas invisíveis” das quais o prompt dependia.

Para lidar com isso, usamos Prompt Optimization e Semantic Versioning. Tratamos prompts como código, dividindo-os em módulos (por exemplo: Tone, Tooling, Safety) que evoluem de forma independente.

Utilizamos frameworks como DSPy e o otimizador Japa, desenvolvido em Berkeley. Nesse fluxo, o papel humano muda:

1. O humano define o objetivo: define os critérios de sucesso de entrada e saída.
2. O humano rotula os exemplos: fornece de 50 a 100 interações de alta qualidade.
3. A máquina otimiza: o otimizador itera sobre o texto do prompt para encontrar o conjunto de instruções mais eficiente para aquele modelo.

Se você está escrevendo prompts de cinco páginas manualmente, está construindo um sistema que vai quebrar assim que o provedor do modelo atualizar os pesos.

4. Não faça fine-tuning antes da hora

Existe uma tendência comum de correr direto para Supervised Fine-Tuning (SFT) ou Reinforcement Learning (RL). Apesar de minha pesquisa se concentrar em alinhamento de preferências, meu conselho estratégico costuma ser o oposto: não faça fine-tuning até extrair tudo o que os modelos de ponta já conseguem fazer.

Seu verdadeiro diferencial competitivo raramente está nos pesos do modelo. Ele está nas camadas de dados e ação. Fine-tuning também traz riscos arquiteturais relevantes:

• Model Drift: melhorar o modelo para uma tarefa específica pode degradar seu raciocínio geral.
• Problemas de capacidade: modelos menores podem “esquecer” regras de segurança ou instruções fora do conjunto de treinamento.
• Sobrecarga de manutenção: você passa a ser responsável pelo ciclo completo de desempenho do modelo.

A menos que você esteja perseguindo os últimos 5% de precisão ou requisitos específicos de latência em tarefas muito especializadas e de alto volume, o tempo de engenharia costuma ser melhor investido em ferramentas robustas.

5. Tire lógica do LLM e coloque nas ferramentas

Alucinações muitas vezes são resultado de pedir que o LLM execute trabalho determinístico. Se um processo tem uma sequência fixa, não peça ao modelo para “raciocinar” sobre ele.

Um exemplo foi nosso caso de entrega de cartão. Inicialmente deixamos o LLM encadear três ferramentas:

check status → verify address → trigger re-order

Com frequência, o modelo alucinava a sequência ou falhava no meio do fluxo. Percebemos que estávamos pedindo ao LLM para fazer o trabalho de um script.

A solução foi criar uma Composite Tool: uma única API determinística que executa internamente toda a lógica de três etapas. O LLM só precisa decidir: “Fix Card Delivery”.

A regra é simples:

Se é determinístico, não deixe o LLM fazer o trabalho.

Ao mover a lógica de negócio para as ferramentas, reduzimos drasticamente alucinações e mantemos o agente como uma interface confiável para os serviços de backend.

O blueprint: simulação automatizada e bug-bashing

Antes que qualquer variante de agente chegue a um único cliente, ela passa por um ambiente de Bug Bashing. Saímos de um modelo de QA manual para um sistema de simulação automatizada e red teaming. Usando nossos dashboards internos e sistemas de rastreamento, simulamos milhares de conversas para “atacar” o agente.

Monitoramos os traces, que representam toda a cadeia de interações entre mensagens do LLM, entradas do cliente e chamadas de ferramentas. Também usamos parceiros de simulação para testar cenários extremos que um testador humano talvez não antecipasse, garantindo que o agente não exponha PII ou desvie de suas responsabilidades financeiras antes de ir para produção.

O futuro das finanças autônomas

Agentes de IA não existem para substituir nossos X-Peers, mas para ampliar seu impacto.

Ao resolver casos previsíveis e de alto volume, como consultas frequentes ou acompanhamento de entrega de cartão, os agentes permitem que nossos especialistas se dediquem aos problemas mais complexos, que exigem empatia financeira real e julgamento humano.

Essa transição, porém, exige mais do que modelos melhores. Ela exige uma mudança de mentalidade.

No setor financeiro, onde a confiança leva anos para ser construída e segundos para ser perdida, a “mágica” da autonomia precisa estar apoiada em rigor arquitetural. No fim das contas, quem vai prosperar nessa nova era são as organizações que tratam a confiança do cliente como seu ativo mais valioso, garantindo que cada interação automatizada seja guiada por uma medição obsessiva e sistemática de qualidade.