El lote nocturno ya no alcanza: por qué tus agentes IA necesitan datos en movimiento

Cuando un piloto de agentes IA no llega a producción, la conversación casi siempre gira alrededor del modelo. Que si hay que ajustar las instrucciones, que si conviene cambiar de proveedor, que si hace falta afinar el modelo con datos propios. En nuestra experiencia implementando plataformas de datos en América Latina, la causa suele estar en otra parte y es mucho menos glamorosa: el agente está mirando datos viejos.

El agente no sabe que está desactualizado

Un modelo de lenguaje no tiene forma de saber si el dato que le entregaste corresponde a hace tres segundos o a hace catorce horas. Responderá con la misma seguridad en ambos casos. Esa es exactamente la propiedad que lo hace peligroso cuando el contexto llega tarde.

Piensa en un agente de atención al cliente en un banco. Le preguntas por el estado de una transferencia. El agente consulta el almacén de datos, que se alimenta de un proceso nocturno, y responde que la transferencia está en proceso. En realidad se rechazó hace dos horas y el cliente ya recibió la notificación. El agente no mintió: respondió correctamente sobre un estado que dejó de ser cierto.

Ninguna cantidad de ingeniería de instrucciones corrige eso.

Por qué la arquitectura por lotes sobrevivió tanto tiempo

El modelo de mover datos copiándolos funcionó durante décadas por una razón sencilla: las decisiones podían esperar. El reporte de ventas del día servía para la reunión de la mañana siguiente. La conciliación bancaria cerraba en la noche. Nadie necesitaba saber el estado del inventario en el segundo exacto.

Ese supuesto se rompió por dos frentes al mismo tiempo.

El primero es el negocio. El fraude se decide dentro de la transacción, no en la revisión del día siguiente. El cliente que abandona el carrito lo hace en el minuto, no en el trimestre. La caída de red que va a generar reclamos ya está ocurriendo mientras el tablero se actualiza.

El segundo es el agente. Un agente autónomo no consulta datos para informar a una persona que va a aplicar su criterio. Consulta datos para actuar. Y actuar sobre un estado que ya cambió no es un error de reporte, es una decisión equivocada ejecutada de verdad.

La trampa de conectar el agente directo a la base

La reacción natural cuando alguien se da cuenta de esto es evidente: si el almacén está viejo, que el agente consulte la base transaccional directamente.

Esto funciona con un agente y un caso de uso. Deja de funcionar rápido.

• Cada agente nuevo abre otra conexión contra el sistema que sostiene la operación. El core bancario, el sistema de inventario o el de facturación no fueron diseñados para absorber consultas analíticas de agentes que razonan en voz alta.
• Las consultas de un agente son impredecibles en forma y en volumen. Un pico de conversaciones se convierte en un pico de carga sobre el sistema crítico.
• Cada integración es punto a punto. Con diez sistemas y diez agentes tienes cien caminos posibles, y todos hay que mantenerlos.
• No queda registro de qué vio el agente. Cuando alguien pregunte por qué decidió lo que decidió, no hay forma de reconstruirlo.

Ese último punto es el que suele frenar el proyecto en banca y telecomunicaciones. No basta con que el agente acierte: hay que poder explicarlo después.

Poner los eventos en el centro

La alternativa que implementamos es distinta en un punto que parece pequeño y lo cambia todo: en lugar de que cada consumidor vaya a buscar el dato donde vive, cada sistema publica lo que le ocurre como un evento, y quien lo necesite lo consume desde ahí.

Un pago aprobado es un evento. Un cambio de dirección es un evento. Una celda de red degradada es un evento. Un producto que sale de bodega es un evento.

Sobre ese flujo se resuelven las tres cosas que la arquitectura anterior no podía dar:

El contexto se construye mientras los datos se mueven. El perfil de comportamiento de un cliente no se recalcula cada noche: se mantiene actualizado a medida que llegan sus transacciones. Cuando el agente pregunta, la respuesta ya está lista y ya está fresca.

La complejidad deja de crecer al cuadrado. Un sistema nuevo publica sus eventos una vez y cualquier consumidor los toma. No hay que construir una integración por cada par.

Cada decisión queda registrada. Si la decisión del agente también se publica como evento, el registro completo de qué datos existían y qué se decidió sobre ellos queda en el mismo lugar. Se puede auditar y se puede reproducir.

Dónde empieza esto en la práctica

No empieza comprando una licencia. Empieza eligiendo un caso de uso donde el tiempo real cambie un resultado medible, y trayendo al flujo solo los eventos que ese caso necesita.

Hemos visto proyectos que arrancan queriendo publicar todo el core como eventos y se atascan seis meses en modelado. Y hemos visto proyectos que arrancan con tres tipos de evento, resuelven un caso de fraude concreto y a partir de ahí crecen por demanda real, no por planificación especulativa.

El segundo camino llega a producción. El primero suele terminar como una presentación.

Lo que conviene revisar antes de sumar otro agente

Si estás evaluando llevar un agente a producción, estas preguntas separan los pilotos que sobreviven de los que no:

1. ¿De dónde sale el dato que va a ver el agente, y con qué antigüedad llega?
2. Si ese dato cambia mientras el agente razona, ¿qué pasa?
3. ¿Puedes reconstruir, seis meses después, qué información tenía disponible cuando decidió?
4. Cuando agregues el quinto agente, ¿cuántas integraciones nuevas van a hacer falta?

Si alguna de las cuatro no tiene respuesta clara, el problema no está en el modelo.