{"id":36480,"date":"2026-03-23T13:43:15","date_gmt":"2026-03-23T16:43:15","guid":{"rendered":"https:\/\/building.nubank.com\/?p=36480"},"modified":"2026-03-25T10:05:21","modified_gmt":"2026-03-25T13:05:21","slug":"construyendo-agentes-de-ia-para-127-millones-de-clientes","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/es\/construyendo-agentes-de-ia-para-127-millones-de-clientes\/","title":{"rendered":"Construyendo agentes de IA para 131 millones de clientes"},"content":{"rendered":"\n

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

En el entorno de alto riesgo de las finanzas globales, el margen de error es cero. En Nu, atendemos a 131 millones de clientes en Brasil, M\u00e9xico y Colombia. Para un neobanco de esta escala, la era del \u201cchatbot\u201d ya qued\u00f3 atr\u00e1s. Nuestro desaf\u00edo ahora es ir m\u00e1s all\u00e1 de la simple recuperaci\u00f3n de respuestas de FAQ y construir sistemas aut\u00f3nomos capaces de manejar renegociaci\u00f3n de deudas, log\u00edstica de tarjetas y prevenci\u00f3n de fraudes, manteniendo siempre la confianza absoluta de una base de clientes que espera soporte inmediato, emp\u00e1tico y factualmente correcto.<\/p>\n\n\n\n

Mi perspectiva se basa en m\u00e1s de una d\u00e9cada trabajando en empresas como Apple, Amazon y LinkedIn, adem\u00e1s de una estrecha relaci\u00f3n con la comunidad de investigaci\u00f3n, con publicaciones en conferencias como NeurIPS, ICML e ICLR. Como creador de Quant Ease<\/strong> \u2014el primer algoritmo de cuantizaci\u00f3n a gran escala basado en coordinate descent\u2014 y como investigador en alineaci\u00f3n de preferencias para LLMs, he aprendido que la \u201cmagia\u201d de los agentes de IA es, en realidad, un problema de infraestructura. Para construir agentes que funcionen para cientos de millones de usuarios, es necesario abandonar la \u201cbrujer\u00eda de prompts\u201d y adoptar rigor arquitect\u00f3nico.<\/p>\n\n\n\n

Estas son cinco de las lecciones m\u00e1s dif\u00edciles que aprendimos al construir agentes de IA en producci\u00f3n.<\/p>\n\n\n\n

1. Evals-first<\/em>: de NPS a TNPS<\/h2>\n\n\n\n

Las m\u00e9tricas tradicionales pueden convertirse en una trampa en el desarrollo de IA. Muchas organizaciones utilizan el Net Promoter Score (NPS) para medir el \u00e9xito, pero en entornos de soporte de alto volumen el NPS funciona mal. Las tasas de respuesta suelen ser bajas, el feedback llega con d\u00edas de retraso y la muestra carece del poder estad\u00edstico necesario para ciclos r\u00e1pidos de pruebas A\/B.<\/p>\n\n\n\n

Para escalar, es necesario migrar a TNPS (Transactional Net Promoter Score)<\/strong> \u2014evaluando la interacci\u00f3n espec\u00edfica con la IA de forma inmediata\u2014 y complementarlo con un framework de \u201cLLM-as-a-judge\u201d. En lugar de esperar una encuesta que quiz\u00e1 nunca llegue, utilizamos un segundo LLM, actuando como auditor, para evaluar el 100% de las conversaciones con base en criterios binarios:<\/p>\n\n\n\n

    \n
  • Correcci\u00f3n:<\/strong> \u00bfla respuesta del agente contradice nuestra base de conocimiento interna?<\/li>\n\n\n\n
  • Concisi\u00f3n:<\/strong> \u00bfel agente entreg\u00f3 una respuesta directa o un \u201cmuro de texto\u201d?<\/li>\n\n\n\n
  • Alineaci\u00f3n de preferencias:<\/strong> \u00bfel agente respet\u00f3 la versi\u00f3n de tono y estilo definida para ese mercado?<\/li>\n<\/ul>\n\n\n\n

    Al pasar de una peque\u00f1a muestra de encuestas a una auditor\u00eda completa de las interacciones, podemos iterar diariamente sobre diferentes variantes. Como dice el principio b\u00e1sico: si no puedes medirlo, no puedes mejorarlo<\/em>.<\/p>\n\n\n\n

    2. Redefiniendo qu\u00e9 es un agente: el paradigma ReAct<\/h2>\n\n\n\n

    La palabra \u201cagente\u201d hoy est\u00e1 rodeada de mucho ruido. En producci\u00f3n, un agente no es simplemente un generador de texto: es un sistema aut\u00f3nomo que sigue el paradigma ReAct (Reasoning and Acting)<\/strong>. Es decir, un \u201ccerebro\u201d que razona y un conjunto de herramientas que ejecutan acciones para resolver tareas de principio a fin.<\/p>\n\n\n\n

    Arquitect\u00f3nicamente, definimos el agente en tres capas:<\/p>\n\n\n\n

      \n
    • Prompt (el cerebro):<\/strong> el motor de razonamiento que decide cu\u00e1l ser\u00e1 el siguiente paso.<\/li>\n\n\n\n
    • Herramientas (las manos\/APIs):<\/strong> acciones determin\u00edsticas, com check_delivery_status o trigger_debt_renegotiation.<\/li>\n\n\n\n
    • Datos (la memoria):<\/strong> la capa de RAG (Retrieval-Augmented Generation<\/em>) y el contexto de sesi\u00f3n que conectan el modelo con el historial espec\u00edfico del cliente.<\/li>\n<\/ul>\n\n\n\n

      Si tu sistema no puede ejecutar una acci\u00f3n en el mundo real \u2014como reenviar una tarjeta perdida o actualizar un l\u00edmite de cr\u00e9dito\u2014 entonces no es un agente. Es solo una interfaz de b\u00fasqueda.<\/p>\n\n\n\n

      3. Deja de escribir prompts: la era de la optimizaci\u00f3n de prompts<\/h2>\n\n\n\n

      Uno de los hallazgos m\u00e1s contraintuitivos que encontramos es que los humanos son malos escribiendo prompts para producci\u00f3n<\/strong>. Los prompts escritos manualmente suelen ser fr\u00e1giles y altamente dependientes del modelo.<\/p>\n\n\n\n

      Ya hemos observado situaciones en las que migrar a modelos de nueva generaci\u00f3n \u2014por ejemplo, pasar de GPT-4 a modelos m\u00e1s avanzados de razonamiento\u2014 rompe agentes existentes<\/strong>. Esto ocurre porque los modelos m\u00e1s inteligentes hacen menos suposiciones impl\u00edcitas, eliminando \u201cayudas invisibles\u201d de las que depend\u00eda el prompt.<\/p>\n\n\n\n

      Para resolver esto utilizamos Prompt Optimization<\/strong> y Semantic Versioning<\/strong>. Tratamos los prompts como c\u00f3digo, dividi\u00e9ndolos en m\u00f3dulos (por ejemplo: Tone<\/em>, Tooling<\/em>, Safety<\/em>) que evolucionan de forma independiente.<\/p>\n\n\n\n

      Utilizamos frameworks como DSPy<\/strong> y el optimizador Japa<\/strong>, desarrollado en Berkeley. En este flujo, el rol humano cambia:<\/p>\n\n\n\n

        \n
      1. El humano define el objetivo:<\/strong> define los criterios de \u00e9xito de entrada y salida.<\/li>\n\n\n\n
      2. El humano etiqueta los ejemplos:<\/strong> proporciona entre 50 y 100 interacciones de alta calidad.<\/li>\n\n\n\n
      3. La m\u00e1quina optimiza:<\/strong> el optimizador itera sobre el texto del prompt para encontrar el conjunto de instrucciones m\u00e1s eficiente para ese modelo.<\/li>\n<\/ol>\n\n\n\n

        Si est\u00e1s escribiendo prompts de cinco p\u00e1ginas a mano, est\u00e1s construyendo un sistema que se romper\u00e1 en el momento en que el proveedor del modelo actualice sus pesos.<\/p>\n\n\n\n

        4. No hagas fine-tuning antes de tiempo<\/h2>\n\n\n\n

        Existe una tendencia com\u00fan de correr directamente hacia Supervised Fine-Tuning (SFT)<\/strong> o Reinforcement Learning (RL)<\/strong>. Aunque mi investigaci\u00f3n se centra en la alineaci\u00f3n de preferencias, mi consejo estrat\u00e9gico suele ser el contrario: no hagas fine-tuning hasta haber agotado las capacidades de los modelos de frontera.<\/strong><\/p>\n\n\n\n

        Tu verdadera ventaja competitiva rara vez est\u00e1 en los pesos del modelo. Est\u00e1 en tus capas de datos<\/strong> y acci\u00f3n<\/strong>. Adem\u00e1s, el fine-tuning introduce riesgos arquitect\u00f3nicos importantes:<\/p>\n\n\n\n

          \n
        • Model Drift:<\/strong> mejorar el modelo para una tarea espec\u00edfica puede degradar su razonamiento general.<\/li>\n\n\n\n
        • Problemas de capacidad:<\/strong> los modelos m\u00e1s peque\u00f1os pueden \u201colvidar\u201d reglas de seguridad o instrucciones que no est\u00e1n expl\u00edcitamente en el conjunto de entrenamiento.<\/li>\n\n\n\n
        • Sobrecarga de mantenimiento: <\/strong>pasas a ser responsable de todo el ciclo de vida del rendimiento de ese modelo.<\/li>\n<\/ul>\n\n\n\n

          A menos que est\u00e9s optimizando el \u00faltimo 5% de precisi\u00f3n o requisitos espec\u00edficos de latencia en tareas muy especializadas y de alto volumen, tu tiempo de ingenier\u00eda suele estar mejor invertido en construir herramientas robustas.<\/p>\n\n\n\n

          5. Mueve la l\u00f3gica a las herramientas<\/h2>\n\n\n\n

          Las alucinaciones a menudo son el resultado de pedirle al LLM que realice trabajo determin\u00edstico. Si un proceso tiene una secuencia fija, no le pidas al modelo que \u201crazone\u201d sobre \u00e9l. Un ejemplo fue nuestro caso de entrega de tarjetas<\/strong>. Inicialmente dejamos que el LLM encadenara tres herramientas:<\/p>\n\n\n\n

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

          Con frecuencia el modelo alucinaba la secuencia o fallaba a mitad del flujo. Nos dimos cuenta de que est\u00e1bamos pidi\u00e9ndole al LLM que hiciera el trabajo de un script. La soluci\u00f3n fue construir una Composite Tool<\/strong>: una \u00fanica API determin\u00edstica que maneja internamente toda la l\u00f3gica de tres pasos. El LLM solo necesita decidir: \u201cFix Card Delivery\u201d.<\/p>\n\n\n\n

          La regla es simple:<\/p>\n\n\n\n

          Si es determin\u00edstico, no hagas que el LLM haga el trabajo.<\/p>\n\n\n\n

          Al mover la l\u00f3gica de negocio a las herramientas, reducimos significativamente las alucinaciones y mantenemos al agente como una interfaz confiable para nuestros servicios de backend.<\/p>\n\n\n\n

          El blueprint: simulaci\u00f3n automatizada y bug-bashing<\/h2>\n\n\n\n

          Antes de que una variante de agente llegue a un solo cliente, pasa por un entorno de Bug Bashing. Hemos dejado atr\u00e1s el QA manual y adoptado un sistema de simulaci\u00f3n automatizada y red teaming<\/strong>. Usando nuestros dashboards internos y sistemas de trazabilidad, simulamos miles de conversaciones para \u201catacar\u201d al agente.<\/p>\n\n\n\n

          Monitoreamos los traces \u2014toda la cadena de interacciones entre mensajes del LLM, entradas del cliente y llamadas a herramientas. Tambi\u00e9n trabajamos con socios de simulaci\u00f3n para probar escenarios extremos que un tester humano quiz\u00e1 no anticipar\u00eda, asegurando que el agente no exponga PII ni se desv\u00ede de sus responsabilidades financieras antes de entrar en producci\u00f3n.<\/p>\n\n\n\n

          El futuro de las finanzas aut\u00f3nomas<\/h2>\n\n\n\n

          Los agentes de IA no est\u00e1n aqu\u00ed para reemplazar a nuestros X-Peers<\/strong>, sino para potenciar su impacto. Al resolver casos previsibles y de alto volumen \u2014como consultas frecuentes o seguimiento de env\u00edos de tarjetas\u2014 los agentes permiten que nuestros especialistas dediquen su experiencia a los desaf\u00edos m\u00e1s complejos, aquellos que requieren empat\u00eda financiera real y juicio humano.<\/p>\n\n\n\n

          Esta transici\u00f3n, sin embargo, exige algo m\u00e1s que mejores modelos. Requiere un cambio de mentalidad. En el sector financiero, donde la confianza tarda a\u00f1os en construirse y segundos en perderse, la \u201cmagia\u201d de la autonom\u00eda debe estar respaldada por rigor arquitect\u00f3nico. Al final, quienes prosperen en esta nueva era ser\u00e1n las organizaciones que traten la confianza del cliente como su activo m\u00e1s valioso<\/strong>, asegurando que cada interacci\u00f3n automatizada est\u00e9 guiada por una medici\u00f3n obsesiva y sistem\u00e1tica de la excelencia.<\/p>\n\n\n\n

          \n