Construyendo agentes de IA para 131 millones de clientes

Written by: Aman Gupta, Daniel Braithwaite

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éxico y Colombia. Para un neobanco de esta escala, la era del “chatbot” ya quedó atrás. Nuestro desafío ahora es ir más allá de la simple recuperación de respuestas de FAQ y construir sistemas autónomos capaces de manejar renegociación de deudas, logística de tarjetas y prevención de fraudes, manteniendo siempre la confianza absoluta de una base de clientes que espera soporte inmediato, empático y factualmente correcto.

Mi perspectiva se basa en más de una década trabajando en empresas como Apple, Amazon y LinkedIn, además de una estrecha relación con la comunidad de investigación, con publicaciones en conferencias como NeurIPS, ICML e ICLR. Como creador de Quant Ease —el primer algoritmo de cuantización a gran escala basado en coordinate descent— y como investigador en alineación de preferencias para LLMs, he aprendido que la “magia” 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 “brujería de prompts” y adoptar rigor arquitectónico.

Estas son cinco de las lecciones más difíciles que aprendimos al construir agentes de IA en producción.

1. Evals-first: de NPS a TNPS

Las métricas tradicionales pueden convertirse en una trampa en el desarrollo de IA. Muchas organizaciones utilizan el Net Promoter Score (NPS) para medir el éxito, pero en entornos de soporte de alto volumen el NPS funciona mal. Las tasas de respuesta suelen ser bajas, el feedback llega con días de retraso y la muestra carece del poder estadístico necesario para ciclos rápidos de pruebas A/B.

Para escalar, es necesario migrar a TNPS (Transactional Net Promoter Score) —evaluando la interacción específica con la IA de forma inmediata— y complementarlo con un framework de “LLM-as-a-judge”. En lugar de esperar una encuesta que quizá nunca llegue, utilizamos un segundo LLM, actuando como auditor, para evaluar el 100% de las conversaciones con base en criterios binarios:

• Corrección: ¿la respuesta del agente contradice nuestra base de conocimiento interna?
• Concisión: ¿el agente entregó una respuesta directa o un “muro de texto”?
• Alineación de preferencias: ¿el agente respetó la versión de tono y estilo definida para ese mercado?

Al pasar de una pequeña muestra de encuestas a una auditoría completa de las interacciones, podemos iterar diariamente sobre diferentes variantes. Como dice el principio básico: si no puedes medirlo, no puedes mejorarlo.

2. Redefiniendo qué es un agente: el paradigma ReAct

La palabra “agente” hoy está rodeada de mucho ruido. En producción, un agente no es simplemente un generador de texto: es un sistema autónomo que sigue el paradigma ReAct (Reasoning and Acting). Es decir, un “cerebro” que razona y un conjunto de herramientas que ejecutan acciones para resolver tareas de principio a fin.

Arquitectónicamente, definimos el agente en tres capas:

• Prompt (el cerebro): el motor de razonamiento que decide cuál será el siguiente paso.
• Herramientas (las manos/APIs): acciones determinísticas, com check_delivery_status o trigger_debt_renegotiation.
• Datos (la memoria): la capa de RAG (Retrieval-Augmented Generation) y el contexto de sesión que conectan el modelo con el historial específico del cliente.

Si tu sistema no puede ejecutar una acción en el mundo real —como reenviar una tarjeta perdida o actualizar un límite de crédito— entonces no es un agente. Es solo una interfaz de búsqueda.

3. Deja de escribir prompts: la era de la optimización de prompts

Uno de los hallazgos más contraintuitivos que encontramos es que los humanos son malos escribiendo prompts para producción. Los prompts escritos manualmente suelen ser frágiles y altamente dependientes del modelo.

Ya hemos observado situaciones en las que migrar a modelos de nueva generación —por ejemplo, pasar de GPT-4 a modelos más avanzados de razonamiento— rompe agentes existentes. Esto ocurre porque los modelos más inteligentes hacen menos suposiciones implícitas, eliminando “ayudas invisibles” de las que dependía el prompt.

Para resolver esto utilizamos Prompt Optimization y Semantic Versioning. Tratamos los prompts como código, dividiéndolos en módulos (por ejemplo: Tone, Tooling, Safety) que evolucionan de forma independiente.

Utilizamos frameworks como DSPy y el optimizador Japa, desarrollado en Berkeley. En este flujo, el rol humano cambia:

1. El humano define el objetivo: define los criterios de éxito de entrada y salida.
2. El humano etiqueta los ejemplos: proporciona entre 50 y 100 interacciones de alta calidad.
3. La máquina optimiza: el optimizador itera sobre el texto del prompt para encontrar el conjunto de instrucciones más eficiente para ese modelo.

Si estás escribiendo prompts de cinco páginas a mano, estás construyendo un sistema que se romperá en el momento en que el proveedor del modelo actualice sus pesos.

4. No hagas fine-tuning antes de tiempo

Existe una tendencia común de correr directamente hacia Supervised Fine-Tuning (SFT) o Reinforcement Learning (RL). Aunque mi investigación se centra en la alineación de preferencias, mi consejo estratégico suele ser el contrario: no hagas fine-tuning hasta haber agotado las capacidades de los modelos de frontera.

Tu verdadera ventaja competitiva rara vez está en los pesos del modelo. Está en tus capas de datos y acción. Además, el fine-tuning introduce riesgos arquitectónicos importantes:

• Model Drift: mejorar el modelo para una tarea específica puede degradar su razonamiento general.
• Problemas de capacidad: los modelos más pequeños pueden “olvidar” reglas de seguridad o instrucciones que no están explícitamente en el conjunto de entrenamiento.
• Sobrecarga de mantenimiento: pasas a ser responsable de todo el ciclo de vida del rendimiento de ese modelo.

A menos que estés optimizando el último 5% de precisión o requisitos específicos de latencia en tareas muy especializadas y de alto volumen, tu tiempo de ingeniería suele estar mejor invertido en construir herramientas robustas.

5. Mueve la lógica a las herramientas

Las alucinaciones a menudo son el resultado de pedirle al LLM que realice trabajo determinístico. Si un proceso tiene una secuencia fija, no le pidas al modelo que “razone” sobre él. Un ejemplo fue nuestro caso de entrega de tarjetas. Inicialmente dejamos que el LLM encadenara tres herramientas:

check status → verify address → trigger re-order

Con frecuencia el modelo alucinaba la secuencia o fallaba a mitad del flujo. Nos dimos cuenta de que estábamos pidiéndole al LLM que hiciera el trabajo de un script. La solución fue construir una Composite Tool: una única API determinística que maneja internamente toda la lógica de tres pasos. El LLM solo necesita decidir: “Fix Card Delivery”.

La regla es simple:

Si es determinístico, no hagas que el LLM haga el trabajo.

Al mover la lógica de negocio a las herramientas, reducimos significativamente las alucinaciones y mantenemos al agente como una interfaz confiable para nuestros servicios de backend.

El blueprint: simulación automatizada y bug-bashing

Antes de que una variante de agente llegue a un solo cliente, pasa por un entorno de Bug Bashing. Hemos dejado atrás el QA manual y adoptado un sistema de simulación automatizada y red teaming. Usando nuestros dashboards internos y sistemas de trazabilidad, simulamos miles de conversaciones para “atacar” al agente.

Monitoreamos los traces —toda la cadena de interacciones entre mensajes del LLM, entradas del cliente y llamadas a herramientas. También trabajamos con socios de simulación para probar escenarios extremos que un tester humano quizá no anticiparía, asegurando que el agente no exponga PII ni se desvíe de sus responsabilidades financieras antes de entrar en producción.

El futuro de las finanzas autónomas

Los agentes de IA no están aquí para reemplazar a nuestros X-Peers, sino para potenciar su impacto. Al resolver casos previsibles y de alto volumen —como consultas frecuentes o seguimiento de envíos de tarjetas— los agentes permiten que nuestros especialistas dediquen su experiencia a los desafíos más complejos, aquellos que requieren empatía financiera real y juicio humano.

Esta transición, sin embargo, exige algo más que mejores modelos. Requiere un cambio de mentalidad. En el sector financiero, donde la confianza tarda años en construirse y segundos en perderse, la “magia” de la autonomía debe estar respaldada por rigor arquitectónico. Al final, quienes prosperen en esta nueva era serán las organizaciones que traten la confianza del cliente como su activo más valioso, asegurando que cada interacción automatizada esté guiada por una medición obsesiva y sistemática de la excelencia.