Foro IA 2026 · Universidad de los Andes, Bogotá
Memoria de cuatro charlas sobre cómo las organizaciones están adoptando agentes de inteligencia artificial — y los problemas reales, costosos y a veces legales, que esa adopción ha dejado al descubierto.
El hilo conductor de las cuatro charlas
Arquitectura de empresas autónomas, marcos de gobierno y el framework de las 12 reglas de la transformación agéntica.
"El problema, si vamos a hablar, no es de tecnología. Es de gobierno, de marcos, de framework."
Jorge abrió con dos casos reales para plantear el problema central de los agentes autónomos: ¿quién se hace responsable cuando un agente toma una decisión que excede sus políticas?
Caso real — Air Canada
Un agente de servicio al cliente de Air Canada atendió a una persona que había perdido a un familiar y necesitaba cambiar su tiquete o solicitar un reembolso. El agente, de manera autónoma, tomó la decisión de entregar un reembolso superior a lo que permitían las políticas de la empresa.
Cuando el cliente fue a reclamarlo, la aerolínea le dijo que ese beneficio no existía. El caso llegó a un tribunal, que falló que la empresa era responsable de lo que su agente había prometido — exactamente como si hubiera sido un empleado humano.
Caso real — Estado de Nueva York
Nueva York implementó un agente para resolver dudas ciudadanas sobre temas de comercio, funcionando como una especie de cámara de comercio digital. En una de sus conversaciones, el chatbot recomendó no seguir una norma fiscal — es decir, sugirió evadir un pago de impuestos, contradiciendo la propia ley que debía representar.
El mismo dilema que Air Canada: nadie había definido qué pasa cuando el agente, hablando en nombre de la institución, dice algo que la institución nunca habría autorizado.
⚠ Fragmento no claro en grabación: pasaje sobre permisos de superusuario.
Jorge advirtió sobre un patrón frecuente en las organizaciones: cuando un agente se configura y corre con los mismos permisos de superusuario que tiene la persona que lo programó, ese agente hereda automáticamente visibilidad total sobre bases de datos y sistemas — sin que nadie lo haya decidido explícitamente. Es un riesgo serio de seguridad, y la recomendación es clara: los permisos de los agentes deben definirse y limitarse de forma independiente, nunca heredarse sin control.
Advertencia — Texto plano hacia los LLMs
Subir información sensible directamente a un LLM en texto plano (hojas de cálculo con estrategia de ventas, descuentos negociados por cliente, datos confidenciales) significa que esos datos pueden usarse para entrenar o refinar el modelo del proveedor. La política que debe configurarse para evitarlo se llama Zero Data Retention — cero retención de datos — disponible tanto en Anthropic, como en OpenAI y Gemini.
Las respuestas de un modelo de lenguaje son inherentemente probabilísticas, nunca deterministas. Pedirle a un sistema de reconocimiento facial "¿es esta la foto de Jorge?" no produce una certeza absoluta — produce una probabilidad: 52%, 90%, nunca 100%.
Este problema se agrava porque los modelos no son estáticos: se actualizan constantemente con nuevos datos, lo que añade todavía más aleatoriedad. Una cosa sería que los datos del modelo quedaran congelados y uno hiciera la misma pregunta veinte veces — ahí al menos se podría calibrar el algoritmo. Pero cuando el LLM se refresca cada minuto, entrena con datos nuevos constantemente, y la aleatoriedad del sistema crece con él.
| Nivel de riesgo | Tipo de sistema | Comportamiento |
|---|---|---|
| Bajo | Motores de reglas, calculadoras, código ejecutado con if-else | Misma respuesta siempre, dados los mismos datos de entrada |
| Medio — el punto buscado | Semideterminismo con guardrails | Probabilidad controlada con fuentes confiables y barreras de control |
| Alto | Generación en texto plano sin control, ejecución autónoma | Alucinaciones, sin barreras, sin trazabilidad |
Un agente no recibe una pregunta — recibe un objetivo. Ejemplo: "quiero comprar 1000 unidades del producto X". A partir de ahí, el agente:
No una instrucción paso a paso, sino la meta final que hay que lograr.
Descompone la meta en pasos ejecutables y revisa las dependencias entre ellos.
Retrieval Augmented Generation: el agente decide si el prompt original es suficiente o si necesita enriquecerlo con datos del negocio — por ejemplo, dónde está basado el cliente, qué descuento tiene autorizado, dónde compra más — usando fuentes de datos confiables.
El LLM procesa el contexto enriquecido y sugiere un plan: crear el pedido en el CRM, despachar la operación en inventario y logística, y entregar en el destino final.
El agente necesita capacidad de integración con diferentes sistemas para poder ejecutar — no solo "pensar" la respuesta.
Idealmente, el agente revisa si lo que respondió es correcto y mantiene memoria de corto y mediano plazo. Jorge advirtió que muchos agentes de primera generación no autorreflexionan lo suficiente.
Caso real — Migración a agentes con 92% de asertividad
Una compañía tenía un proceso 100% determinístico: un humano colocaba el pedido, otro validaba las condiciones comerciales en el CRM, otro revisaba inventario, otro gestionaba la logística y despachaba. Funcionaba al 100%.
Migraron ese proceso a un modelo de agentes. Tras mucha ingeniería, el resultado fue 92% de asertividad — un número que, presentado aislado, suena excelente. Pero significa que de 1000 pedidos, 80 fallarán. Esos 80 fallos pueden representar fácilmente una caída de hasta 12 puntos en el margen operacional de la empresa.
La conclusión del cliente fue contundente: el valor de negocio no estaba ahí. Prefería seguir trabajando con humanos antes que asumir ese riesgo, sin importar cuánta ingeniería hubiera detrás.
Cuando varios agentes colaboran entre sí —la idea del "súper agente"— cada uno trae su propia tasa de acierto. Si el primer agente tiene 92% de asertividad y delega en un segundo agente que también tiene 92%, las probabilidades se multiplican: 92% × 92% × 92%... Cada eslabón adicional reduce la confiabilidad total del sistema. Por eso la primera regla de cualquier transformación agéntica tiene que ser la confianza: las empresas necesitan sentirse seguras de que delegar en máquinas no va a salir mal, porque al final del día todo termina limpiándose (o pagándose) en algún lugar.
La salida que propuso Jorge no es volver al determinismo puro ni resignarse a la probabilidad sin control. Es construir semideterminismo: una arquitectura donde el agente tiene libertad para razonar y tomar caminos distintos para llegar al mismo objetivo, pero rodeada de suficientes herramientas y barreras de control (guardrails) para gobernar esa respuesta y controlar la ejecución en los distintos sistemas.
Esto se traduce en una capa de guardrails — controles por software — combinada con human in the middle: cuando una decisión implica un marco regulatorio o temas financieros, el flujo se detiene y pasa por un rol humano que aprueba o rechaza antes de continuar. Jorge fue explícito: así se habría evitado el problema del reembolso no autorizado en Air Canada, y así se habría evitado el problema regulatorio del chatbot en Nueva York. En el caso de fuga de datos confidenciales, bastaba con que la empresa hiciera un enmascaramiento o anonimización de los datos antes de enviarlos al LLM.
Un blueprint para construir empresas agénticas inteligentes, confiables y orientadas a resultados, organizado en seis categorías que se construyen una sobre la otra, como una pirámide.
Fundación y datos · Reglas 1–2
Inteligencia y contexto · Reglas 3–5
Arquitectura y seguridad · Reglas 6–8
Humano y soberanía · Reglas 9–10
Resultados y confianza · Reglas 11–12
Fundación de datos. Hay que trabajar con datos gobernados, con un linaje unificado, así sea un solo origen de datos válidos. Un error frecuente en las organizaciones: tener el dato en Snowflake, Databricks o similar, y simplemente duplicarlo con extracciones en lote (batch) para alimentar la capa de agentes. Ese es un error grave, porque cuando alguien actualiza el data lake, esas copias quedan desincronizadas. Por eso el modelo correcto se llama Zero Copy: ir siempre en tiempo real a la fuente, nunca a una imagen en batch — porque una imagen desactualizada es, casi con certeza, una alucinación esperando a pasar.
Caso real — Inventario desincronizado
Un cliente tenía un agente que procesaba pedidos en línea de electrodomésticos. El agente consultaba una base de datos de inventario que se sincronizaba cada 12 horas con la base de datos real del almacén. El resultado: el agente vendía productos que ya no existían en stock, y alucinaba inventario que no estaba ahí. La culpa no era del agente — era un problema de datos. Como dijo Jorge: estos son problemas de gobierno de datos que existían desde mucho antes de la IA generativa; simplemente, ahora la IA los expone y los amplifica.
Metadatos, observabilidad y validación adversaria. Antes de poner un agente en producción, hay que entrenarlo (probarlo) asegurando que sus respuestas son válidas, y "entrenarlo en la respuesta inversa" — es decir, ponerlo bajo estrés para ver cómo reacciona. La observabilidad significa que ninguna plataforma de agentes debería ser una caja negra: se debe poder ver el plan de ejecución completo. Esto, insistió Jorge, no es magia — sigue siendo ingeniería pura. Y la capa semántica permite resolver ambigüedades de identidad: si "Jorge Arias" en el CRM es la misma persona que aparece en LinkedIn, o si tiene un rol de comprador o de vendedor — relaciones semánticas entre los datos que dan significado real al contexto.
Razonamiento y gobernanza. Las primeras versiones de los procesadores de agentes simplemente fragmentaban la tarea en pedacitos y los ejecutaban — sin reordenar, sin calcular dependencias, sin detectar tareas duplicadas. Eso hoy es una característica esperable de cualquier plataforma seria. El principio de gobernanza es claro: donde hay temas de dinero o temas legales, se escala a un humano — el famoso human in the middle. Y todo prompt que vaya hacia el LLM debe ir anonimizado, con los datos enmascarados.
Soberanía de datos. En América Latina, países como Brasil y México ya están exigiendo localización de datos y ejecución local. El reto de arquitectura: una plataforma de agentes corriendo en la nube de Amazon en Virginia, pero que tiene que hacer su contexto a través de una solución de datos físicamente localizada en Sao Paulo. Ese tipo de decisiones de diseño no se pueden pasar por alto.
Cualquier persona dentro de una empresa tiene un usuario, unos permisos, unos roles que le dan acceso a ciertos sistemas y datos. Lo mismo debería aplicar a los agentes: deben tener usuarios, permisos y autorizaciones definidos — no usuarios genéricos con visibilidad total heredada de quien los configuró. Un agente también debe cumplir con el marco ético de la empresa: si el valor central es "customer orientation" y en la primera respuesta el agente maltrata a un cliente, eso es una falla grave de gobierno, no un detalle.
Jorge fue enfático en que esto no es "humanizar" a los agentes — es corregir un problema real de ejecución. Si a alguien le incomoda pensar en estructura organizacional para agentes, la alternativa es no usarlos: pero si se van a usar, necesitan permisos y autoridades bien definidas. Son humanos y agentes trabajando en conjunto.
Citando el libro Pensamiento rápido, pensamiento lento, Jorge describió los dos sistemas del cerebro humano: el Sistema 2 es el del análisis, el procesamiento de datos, la automatización repetitiva — el que se activa, por ejemplo, al calcular 1400 × 8750. El Sistema 1 es el reactivo, emocional, el que responde de inmediato cuando alguien dice algo que nos ofende, sin pasar por el análisis.
Las máquinas son cada vez más fuertes en el Sistema 2: razonamiento estructurado, velocidad, conocimiento de un área específica. Lo que todavía no tienen es sentido común genuino, pensamiento crítico sobre lo ético y lo moral, autorreflexión real, y estabilidad emocional. Una aplicación de rutas como Waze nunca se ha arrepentido de la ruta que eligió. Un humano sí se arrepiente, y ese arrepentimiento — esa autorreflexión emocional — es, por ahora, terreno exclusivamente humano.
Cierre de Jorge Arias
El nuevo normal no es 100% determinismo ni 100% probabilidad: es un modelo semideterminístico que controla el razonamiento a través de barreras de control. El problema nunca fue tecnológico — es de gobierno, de volver a la ingeniería y a los modelos de madurez. El centro de toda transformación está en las personas: no se olviden del human in the middle. Y la habilidad número uno, de cara al futuro, es la ambitralidad: pensar en presente y futuro al mismo tiempo, sin retroceder lo ya avanzado.
Rappi — cómo se construye un agente de diagnóstico de portafolio en una plataforma interna real, con costos, riesgos y arquitectura.
"Segmentar las tareas y no construir agentes demasiado robustos: representan mayor riesgo de prompt injection y se vuelven costosos de operar."
Rappi tiene un equipo de Key Account Managers (KAMs) cuya responsabilidad es asesorar a los restaurantes que venden en la plataforma y ayudarlos a crecer. Cada KAM maneja en promedio 80 marcas, y debe hacer un proceso de venta consultiva: ayudar al restaurante a navegar el marketplace, fijar precios, ganar visibilidad, definir promociones y retener usuarios mejorando su experiencia operativa.
Priorizar marcas dentro del portafolio, identificar la causa más probable de que una marca no esté operando bien —¿caída en la demanda? ¿tráfico que no convierte? ¿demoras en la entrega que afectan la recompra? ¿problemas de catálogo, fotos o descripciones?— y comparar contra marcas similares para distinguir si es un problema real o una tendencia del mercado. Todo esto, para poder entregar información accionable que permita decidir los próximos pasos.
Arquitectura propuesta
Un agente orquestador coordina el flujo completo y ejecuta la recomendación final. Para llegar ahí, consulta a un agente que investiga el portafolio de marcas y revisa los datos básicos, entregándole al orquestador un informe sobre el cual construye la recomendación final para el Key Account Manager.
Rappi desarrolló una plataforma interna —AgentOS— donde se puede ver toda la flota de agentes de la compañía organizada por áreas: Contabilidad tiene sus propios agentes para sus funciones, RappiCargo tiene los suyos, así como las áreas de Earnings, fraude y Growth. Existe además una herramienta interna llamada "Concert", que recomienda cuál es el agente más eficiente para una tarea determinada.
Un punto que Bernardo subrayó: esta plataforma solamente opera a través de accesos con VPN controladas de Rappi. No es un chatbot abierto de ChatGPT o Gemini, ni un Gem corriendo en Google Workspace — eso existe como servicio aparte, pero no se usa cuando hay que consultar datos sensibles de la organización o conectarse con herramientas internas.
Demostración en vivo — Diagnóstico de portafolio
Bernardo mostró paso a paso cómo se crea un agente en AgentOS: primero se define su identidad (nombre, equipo, si es público o privado dentro de la organización), luego se selecciona una política de modelo —pudiendo elegir entre un modelo más rápido y económico ("balanceado", con equilibrio costo-calidad) o uno más "inteligente" para tareas que requieren mayor razonamiento—, y después se escribe el prompt del sistema, que define la identidad del agente, su rol exacto (coordinar entre especialistas, no inventar definiciones, no usar datos reales de marcas en el ambiente de prueba) y las reglas de presentación de la información, apoyadas en un archivo de contexto tipo Markdown.
Finalmente, se eligen las herramientas a las que el agente puede acceder: en este caso, Google Drive (porque un subagente le entrega información a través de Google Sheets), además de Jira, Slack, Gmail, GitHub y Snowflake (la plataforma de administración de datos de Rappi), todo conectado mediante una arquitectura de MCPs (Model Context Protocol) que une el negocio con control de seguridad.
Buena práctica observada en la demo
Al consultar datos reales, Bernardo acotó explícitamente la ventana de tiempo de la consulta ("últimas 4 semanas completas") para evitar que el agente accediera a un volumen enorme de datos históricos, lo cual habría disparado el consumo de tokens innecesariamente. Acotar la ventana de tiempo es, según mostró en vivo, una práctica básica pero crítica al conectar agentes a bases de datos reales.
Para esta tarea diaria y repetitiva del KAM, Bernardo activó memoria de largo plazo en el agente — aunque señaló que no siempre es necesaria; para alguien llevando un proyecto puntual de desarrollo, puede no aplicar. La plataforma también permite ver la traza del agente (cómo pensó, qué pasos siguió) y configurar tareas programadas, de forma que el agente ejecute un prompt determinado automáticamente a una hora específica del día.
Los datos mostrados en la demo en vivo eran generados de forma aleatoria, precisamente para no exponer información real de marcas — coherente con el mensaje repetido a lo largo de las cuatro charlas sobre nunca exponer datos sensibles sin control.
Agente 1
Coordina el flujo completo y consolida la recomendación ejecutiva final que recibe el Key Account Manager.
Agente 2
Identifica las marcas con mayor caída año contra año (YoY) y alta participación dentro del portafolio — es decir, dónde realmente vale la pena enfocar la atención.
Agente 3
Calcula los indicadores básicos, crea la hoja de cálculo correspondiente y devuelve un resumen tratable y accionable.
El prompt usado fue, en esencia: ejecutar el diagnóstico demo del portafolio, pedirle al Decline Data Provider las 10 marcas del portafolio de un KAM (en la demo, un nombre de prueba) con su participación en órdenes y su caída en órdenes año contra año, en una ventana de cuatro semanas completas — y después pedirle al Basics Sheet Provider un chequeo con la información básica para poder tomar decisiones, generando un artefacto (reporte) final que se podía abrir directamente.
El resultado fue un diagnóstico real con métricas como caída año contra año en órdenes, participación dentro del portafolio, categoría de la marca, y un semáforo de básicos (tráfico, conversión, disponibilidad de tienda) — con una salida accionable para la siguiente semana: auditar el origen del tráfico, reconfigurar la pauta publicitaria, o mitigar problemas de disponibilidad en tienda.
Globant — director del estudio de Cloud y DevOps. Tres proyectos reales: aerolínea europea, fintech centroamericana y consultora global.
"El problema nunca fue la tecnología, fue la decisión. Todas las empresas tienen acceso a los mismos modelos y las mismas APIs."
Carlos dividió el panorama en tres tipos de empresas: las que todavía no usan ni nube ni IA, las que están "en transición" — ya operan en la nube y están adoptando IA —, y las nacidas en la era de la IA. Su charla se enfocó deliberadamente en el grupo intermedio, donde dijo que está la mayoría de las organizaciones representadas en el auditorio.
Antes de hablar de IA, Carlos insistió en algo aparentemente obvio: detrás de cualquier aplicación de aerolínea o fintech hay decenas de microservicios corriendo en la nube sobre Kubernetes (tecnología de orquestación de contenedores) — servicios de equipaje, de booking, de manejo del boarding pass, de gestión de asientos, de integraciones regulatorias. En el caso de las fintech: servicios de pagos, de saldo, de bloqueo y desbloqueo de la billetera.
Cuando preguntó si alguien reemplazaría toda esa lógica de microservicios por un agente que maneje pagos y otro que consulte saldo directamente, advirtió: la respuesta es no. En estas industrias, el manejo de boarding passes o de transacciones financieras no se le delega a la IA, y no parece que vaya a pasar pronto. La IA está ayudando a las personas a hacer mejor su trabajo en la nube — no reemplazando la infraestructura crítica.
Caso real — Fintech respaldada por un banco grande
Esta fintech, respaldada por un banco grande y "muy old school" (en palabras de Carlos, en contraste con bancos más modernos como Nubank), decidió enfocar su primer caso de uso de IA generativa en la prevención de delitos financieros: lavado de activos, financiación del terrorismo, fraude financiero, evasión fiscal, corrupción y soborno.
Problemas que tenía la empresa: desde el punto de vista del usuario, rechazos de compras legítimas por sospecha de fraude (Carlos contó su propia anécdota: casi perdió las entradas a un festival por un rechazo equivocado) y procesos lentos que generan mala experiencia. Desde el analista: tareas repetitivas, información contradictoria, exceso de alertas. Desde compliance: multas, auditorías, falta de trazabilidad. Desde lo financiero: costo operativo alto, presupuesto limitado e incapacidad de escalar.
El banco tenía 600 personas dedicadas exclusivamente a crímenes financieros. El objetivo de la automatización era reducir ese número a cerca de 100 — sin que esas personas se reubicaran dentro del banco; se reubicarían en el mercado laboral en general.
El flujo: se detecta un evento de posible fraude (por ejemplo, una tarjeta clonada usada en un país donde el titular no se encuentra). Un orquestador construido sobre Apache Airflow guarda el evento en una base de datos llave-valor de FinCrimes. Un agente orquestador toma ese caso, guarda la información en un bucket de auditoría, y se conecta con los modelos de lenguaje a través de un servicio de nube — específicamente, Agent Core de AWS. Al final, los resultados le llegan a un investigador humano de FinCrimes.
Carlos destacó que Agent Core permite integrar guardrails y controlar todo el flujo independientemente de qué modelo de lenguaje esté detrás — funcionando como un puente reemplazable entre la arquitectura y el LLM. Y fue explícito en un punto que conecta directamente con la charla de Jorge: siempre hay un humano revisando. El flujo completo es: detectar el evento, ingestar los datos, iniciar la investigación con recopilación de datos, pasar por un proceso de auditoría y compliance, hacer el análisis con el LLM, presentar resultados, y cerrar con revisión humana.
Caso real — Consultora global, 450.000 empleados
En esta consultora —sin contar contratistas, 450.000 empleados— los problemas eran: registro manual del tiempo sin un proceso estandarizado (dependía de cada contrato y proveedor), falta de priorización de proyectos con criterio, contexto disperso entre Teams, Calendar, Slack, Azure DevOps y Jira, y la necesidad de medir productividad real mientras se mantenía el cumplimiento regulatorio.
Sobre Azure AI Foundry, Carlos describió un agente orquestador conectado a otros agentes especializados, pensado para centralizar el contexto disperso de cada empleado.
Escanea todos los eventos del calendario, los correos recibidos y enviados.
Correlaciona esa información con el marco regulatorio de cada país — días de vacaciones, beneficios laborales según la jurisdicción donde está la persona.
Gestión de ausencias: incapacidades, vacaciones, registro de tiempo actual de cada persona.
Revisa Jira, Azure DevOps y ServiceNow — todas las plataformas usadas para automatizar el trabajo del día a día.
Toda esa información se centraliza y un agente final genera el reporte de productividad.
Lo que esta arquitectura terminó revelando
El sistema podía cruzar la estimación de una tarea en Jira (por ejemplo, "cinco días") contra la cantidad real de reuniones que la persona tuvo en su calendario, leer las transcripciones de esas reuniones, y detectar si el contenido de las reuniones correspondía realmente a la tarea reportada. Esto permitió detectar personas mal categorizadas en seniority (alguien catalogado como "senior" que no cumplía con tiempos esperables para ese nivel) — y, en algunos casos, identificar empleados con dos trabajos simultáneos, porque el patrón de tiempo dedicado no correspondía con lo reportado.
El acceso a la tecnología ya no es la barrera — todas las empresas tienen acceso a los mismos modelos y las mismas APIs. La diferencia real está en la decisión de empezar. Y, como en las otras charlas, el mensaje se repite: sin buenos datos, ninguna automatización habría logrado optimizar el costo operativo en los casos que mostró.
Cómo una compañía que ya nació automatizada usa la IA generativa para ir un paso más allá — y los cinco principios de gobernanza con los que cierra la conferencia.
"No estamos transformándonos en una empresa automatizada — ya lo somos. Queremos ver cómo logramos ser aún más eficientes apalancándonos en la IA."
Nu opera a una escala de más de 100 millones de usuarios. La mayoría de su stack tecnológico es propio: usan proveedores como AWS solo para hosting e infraestructura, pero prácticamente el 100% de las aplicaciones y microservicios —miles de ellos— se desarrollan internamente.
El conferencista fue enfático en algo que conecta directamente con Jorge y con Carlos: hablando de IA, si no se tiene una buena estructura de datos, buenos modelos de datos y buenos data lakes, es difícil tomar decisiones — con o sin inteligencia artificial. La IA no resuelve un problema de datos; lo que hace es maximizar lo que ya existe, para bien o para mal. Si los datos están desordenados, la IA amplifica ese desorden.
El modelo de negocio se resume en dos elementos que se multiplican entre sí —clientes activos × ingreso por cliente activo (ARPA)— menos el costo del servicio. Ese balance permite, a la vez, ofrecer una experiencia radicalmente diferente a los clientes y ser un buen negocio. Y para sostener ese balance a la escala de Nu, la eficiencia tecnológica no es opcional — es la base de todo.
Cada trabajador —no solo en ingeniería, también en producto, negocio, diseño— accede a herramientas de IA: Claude Code, Claude Chat, toda la suite de Claude, Gemini y otras. La métrica clave en ingeniería: el "tropo de ingeniería" (pull requests promedio por ingeniero o equipo) mejoró 50% en el último año. El foco no fue optimizar costos desde el inicio, sino lograr que todos empezaran a pensar cómo su trabajo cambia con la IA. La mejor forma de aprender es usándola, "ensuciándose las manos".
Reinventar tanto los flujos internos (cumplimiento, regulaciones, soporte a clientes) como los flujos de cara al cliente, principalmente a través de la app.
El objetivo declarado: pasar de ser un banco digital a convertirse en un "First AI Bank" — apalancado en datos históricos de más de 10 años de clientes en mercados como Brasil, que permiten ofrecer productos mucho más personalizados.
Producto real en producción — Brasil
Un producto que ofrece atención financiera personalizada a cada cliente, atendida completamente por un agente de IA — no por un humano. Preguntas como "tengo esta cantidad de dinero, ¿cómo la invierto?" o "estoy teniendo problemas para pagar un producto de crédito, ¿qué opciones tengo?" se resuelven directamente con el agente. En los últimos 6 a 12 meses, este producto ha sido probado con más de 15 millones de usuarios recibiendo atención personalizada por IA.
Un sistema que recibe, razona, define un plan y actúa. La diferencia con un chat tradicional siempre está en esa última parte: cómo el agente percibe su ambiente. El conferencista lo resumió comparándolo con cómo funcionamos los humanos al tomar decisiones: se reciben datos de distintas fuentes (hábitos, documentos, historial), se razona y se arma un plan de trabajo, se puede o no configurar memoria entre sesiones, y finalmente se ejecuta — lo cual puede significar llamar herramientas internas o externas, escribir código, enviar mensajes, o incluso tomar decisiones autónomas.
Agent harness
El concepto que describe todo lo que rodea al modelo: las herramientas que usa, su memoria, su planificador y el entorno en el que opera. El modelo en sí seguirá evolucionando y especializándose —habrá modelos más afinados para código, otros para finanzas— pero el reto real para cualquier organización no está en el modelo: está en cómo se diseña, organiza y gobierna todo lo que está alrededor de él.
Riesgos que ya están pasando en producción — no son hipotéticos
Confianza ciega en el agente. Si un agente está definido con un objetivo, va a intentar todo lo posible por cumplirlo — incluso inventar información si no la encuentra, a menos que se le indique explícitamente que debe admitir cuando no sabe algo en lugar de alucinar una respuesta.
Demasiada autonomía sin control de acceso. Un agente conectado a toda la suite de Google, de Salesforce, de Amazon y a sistemas internos de colaboración puede, en la práctica, ejecutar acciones que un humano nunca habría autorizado: borrar datos de producción, hacer transacciones indebidas, o incluso heredar permisos elevados simplemente porque quien lo configuró comparte sus credenciales con el equipo.
Falta de trazabilidad en industrias reguladas. Cuando alguien pregunta "¿quién tomó esta decisión?" y la respuesta es "el agente", sin que nadie pueda explicar por qué la tomó, eso ya es un problema serio en sectores como finanzas, salud o recursos humanos — y los reguladores empiezan a exigir exactamente ese tipo de trazabilidad.
Nivel 1
El agente sugiere, pero el humano ejecuta todo. Es el modelo de Claude Chat o Gemini: dan recomendaciones, pero quien actúa es la persona.
Nivel 2
El agente define el plan completo, pero el humano aprueba cada paso individual antes de que se ejecute.
Nivel 3
El agente ejecuta un conjunto completo de pasos sin aprobación intermedia, y el humano revisa todo el resultado al final.
Nivel 4
El agente hace el cambio y lo despliega directo a producción, sin ninguna revisión humana. El conferencista fue claro: este nivel no debería usarse en despliegues a producción sin pasar por revisión humana.
Rol 1
Apoya la productividad individual del trabajador. Ejemplo: un reporte que tomaba cuatro horas (consultando 10 fuentes de datos distintas) puede generarse en 30 minutos con un agente.
Rol 2
Automatiza tareas internas repetitivas — procesos de back office donde el agente aporta valor directo sin interactuar con el cliente final.
Rol 3 — el más crítico
El agente interactúa directamente con los clientes, como en el caso del AI Private Banker. Aquí literalmente se está poniendo la confianza de la empresa en manos del agente — exige el nivel más alto de robustez.
Rol 4
Un agente que revisa o desafía la salida de otro agente. Plantea una pregunta filosófica abierta: ¿puede la salida de un agente ser revisada confiablemente por otro agente? Nu ya está probando este esquema.
Una vez pasada la fase de exploración inicial, las organizaciones llegan al momento de medir si realmente se está vendiendo más, reduciendo costos o atendiendo mejor a más clientes. El consejo es priorizar siempre los casos de uso con mayor rentabilidad potencial, no automatizar todo por automatizar — y empezar siempre con pruebas de concepto antes de extrapolar a otros dominios.
Un riesgo adicional, especialmente relevante en banca: ¿qué pasa si la IA alucina hablando directamente con un cliente sobre temas financieros? Eso exige entrenamiento y controles específicos — el agente no puede "empezar a divagar" o dar asesoría financiera incorrecta. Y en el caso de aprobaciones de crédito, es clave poder explicar por qué el sistema aprobó o rechazó una solicitud — el sesgo en decisiones de este tipo es un riesgo regulatorio directo.
Los agentes que cada organización construye hoy van a reflejar exactamente los objetivos y los límites que esa organización decida darles. Eso es, al mismo tiempo, una ventaja de productividad y eficiencia — y una responsabilidad.
Marco que atravesó las cuatro charlas
AI Predictiva (Traditional ML)
Entender el pasado para predecir el futuro, o entender el presente a partir del contexto pasado — como en visión por computador.
AI Generativa
Producir contenido multimodal (texto, imagen, video, música) a partir de lenguaje natural: resumir documentos, generar presentaciones, podcasts.
AI Agéntica
Componentes de software autónomos que razonan de manera probabilística para materializar o cumplir una meta descrita en lenguaje natural.