Por Andrew Tan
¿Suficientemente fresco para un agente de IA? El presupuesto de frescura de datos que nadie define
La mayoría de los equipos hablan del contexto de IA como un problema de almacenamiento. La pregunta más difícil es si los datos son lo suficientemente frescos para la acción que el agente está a punto de tomar.
Muchas conversaciones sobre infraestructura de IA todavía están dirigidas al cuello de botella equivocado.
Los equipos debaten sobre bases de datos vectoriales, almacenamiento en caché de prompts, memoria a largo plazo, servidores MCP y qué modelo debería estar detrás del agente. Todo eso importa. Nada de eso responde a la pregunta que realmente determina si un agente es seguro para usar en producción.
¿Qué tan frescos son los datos cuando el agente decide hacer algo?
Esa pregunta suena aburrida. No es aburrida cuando el agente envía el reembolso incorrecto, aprueba el pedido equivocado, escala el incidente incorrecto o llama a la herramienta equivocada porque está mirando un registro de cliente de hace veinte minutos.
La mayoría de los equipos de datos ya entienden la calidad, el linaje y la deriva de esquemas. La frescura se trata como algo agradable de tener hasta que los agentes entran en escena. Entonces, la frescura deja de ser una preferencia de tablero y se convierte en un límite operativo.
El contexto no es lo mismo que el permiso
Esta es la parte que muchos equipos omiten.
Un agente puede tener mucho contexto y aún así tener el contexto incorrecto para la acción que deseas que tome. Diez millones de filas en un almacén no ayudan si el único campo que importa cambió hace tres minutos y tu sincronización se ejecuta cada hora.
Esa es la diferencia entre datos informativos y datos accionables.
Los datos informativos ayudan a un agente a explicar lo que sucedió la semana pasada. Los datos accionables le permiten decidir qué debería suceder ahora mismo.
Esas no son la misma carga de trabajo.
Un copiloto de soporte que resume los últimos cinco tickets puede tolerar cierto retraso. Un agente que decide si un reembolso ya ocurrió no puede.
Un asistente de ventas que redacta un informe de cuenta puede trabajar con sincronizaciones nocturnas de CRM. Un agente que enruta un cliente potencial en vivo basado en el uso actual del producto probablemente necesite datos que tengan unos pocos minutos de antigüedad como máximo.
Un bot de finanzas que prepara un resumen de variación mensual puede permanecer en lote. Un agente que congela un pago sospechoso no puede.
El error es tratar todo el contexto de IA como una categoría llamada "datos listos para IA."
No es una categoría. Es una pila de decisiones con diferentes requisitos de frescura.
El presupuesto de frescura
La forma más clara de pensar en esto es un presupuesto de frescura.
Cada tarea del agente tiene un retraso máximo aceptable entre lo que sucedió en el sistema fuente y lo que el agente ve cuando actúa.
Ese presupuesto de retraso depende de la consecuencia de estar equivocado.
Aquí hay una versión simple:
| Tarea del agente | Presupuesto típico de frescura | Qué sucede si lo pierdes |
|---|---|---|
| Resumen de cuenta semanal | 24 horas | Narrativa ligeramente obsoleta |
| Preguntas y respuestas de KPI interno | 1 a 4 horas | Respuestas confusas, baja confianza |
| Enrutamiento de clientes potenciales de ventas | 5 a 15 minutos | Mala priorización, seguimiento más lento |
| Decisión de reembolso de soporte al cliente | Menos de 5 minutos | Reembolsos duplicados, errores de política |
| Intervención de fraude o riesgo | Segundos a 1 minuto | Pérdida real de dinero |
Esta no es una tabla universal. Es una función de forzamiento.
La mayoría de los equipos nunca definen estos números en absoluto. Solo dicen que quieren "IA en tiempo real" o "pipelines listos para IA" y esperan que la pila se resuelva sola más tarde.
No lo hará.
Si no defines un presupuesto de frescura, el presupuesto predeterminado se convierte en "lo que sea que el pipeline ya haga." Eso suele ser un accidente, no una elección de diseño.
El procesamiento por lotes sigue siendo adecuado para mucho trabajo de IA
No creo que la respuesta sea empujar toda carga de trabajo hacia el streaming.
Eso es costoso. También crea una nueva clase de problemas operativos si el equipo no lo necesita.
Algunos casos de uso de IA están perfectamente felices en lote:
- Redacción de resúmenes internos
- Preparación de informes de investigación
- Etiquetado de conversaciones de soporte para análisis de tendencias
- Redacción de notas de preparación para renovación
- Enriquecimiento de documentos de planificación
- Creación de resúmenes ejecutivos semanales
Estas tareas se benefician más de la completitud que de la inmediatez.
Por lo general, deseas el registro completo, no el evento más reciente de hace quince segundos.
Esto importa porque mucho del mensaje de IA en este momento enmarca el futuro como un gran sistema en tiempo real. Esa es una buena manera de gastar de más.
La mejor pregunta es más estrecha: ¿dónde realmente cambia la calidad de la acción con datos de baja latencia?
Si la respuesta es en ningún lugar, mantenlo en lote.
Si la respuesta son interfaces específicas, mueve esas interfaces primero.
El peligroso medio
El verdadero problema no es claramente por lotes y no es verdaderamente en tiempo real.
Es el medio confuso donde los equipos tienen pipelines que se actualizan cada hora, o cada treinta minutos, o cuando un conector siente que debe ponerse al día, y luego entregan esos datos a un agente con permiso para actuar.
Ahí es donde los errores se vuelven costosos.
La frescura por hora suena decente hasta que la mapeas al workflow.
Si un cliente se actualiza a las 10:02 y el agente ve el plan antiguo hasta las 11:00, tienes casi una hora donde puede negar un derecho que el cliente ya pagó.
Si un pedido se cancela a las 2:11 y tu asistente de inventario no se entera hasta las 3:00, puede reordenar stock que ya no necesitas.
Si una bandera de contracargo llega a un sistema antes que a otro, tu agente de riesgo puede ver una cuenta saludable y aprobar la siguiente transacción con plena confianza.
Nada está obviamente roto en esos ejemplos. Los trabajos se ejecutaron. Las tablas se actualizaron. El tablero probablemente se ve bien.
El problema es que la ventana de acción es más ajustada que la ventana de datos.
Esa brecha es donde viven los fallos del agente.
Las puertas de aprobación también son una estrategia de frescura
Hay otro punto que se pierde en la prisa por automatizar.
A veces la respuesta correcta no son datos más rápidos. A veces la respuesta correcta es una puerta de aprobación.
Si un agente trabaja con contexto obsoleto o ambiguo, no siempre necesitas bloquear el caso de uso para siempre. Puede que solo necesites cambiar el último paso.
Deja que el agente recopile datos. Deja que redacte la respuesta. Deja que recomiende la acción. Luego requiere una aprobación humana si el presupuesto de frescura no se cumple o si la decisión toca dinero, cumplimiento, acceso o riesgo de cara al cliente.
Esto no es un fracaso de la automatización. Es parte del diseño.
Los buenos sistemas de IA no solo piensan en la calidad del modelo. Piensan en cuándo no actuar solos.
Eso es especialmente cierto cuando los datos subyacentes llegan a través de una mezcla de sincronizaciones por lotes, pipelines de CDC, flujos de eventos y APIs externas que se mueven a diferentes velocidades.
Necesitas frescura por interfaz, no por lema de plataforma
Mucho del posicionamiento de los proveedores difumina esto a propósito.
La promesa suele sonar algo así: conecta todos tus datos, alimenta a tus agentes, desbloquea decisiones en tiempo real.
Está bien. Pero, ¿qué decisiones?
No necesitas un objetivo de frescura gigante para toda la empresa. Necesitas objetivos de frescura por interfaz.
Comienza con los lugares donde un agente cruza de consejo a acción:
- aprobar o denegar algo
- enviar una comunicación al cliente
- cambiar acceso o derechos
- mover dinero
- abrir o cerrar incidentes
- activar sistemas descendentes automáticamente
Esas interfaces merecen límites de retraso explícitos, monitoreo, comportamiento de respaldo y propiedad.
Si el pipeline no cumple con el presupuesto, ¿qué debería suceder?
Quizás la acción se pausa.
Quizás el agente aún pueda redactar pero no enviar.
Quizás pueda operar en un subconjunto seguro de herramientas.
Quizás necesite un humano en el bucle.
El punto es definir esto antes de que el primer incidente te lo enseñe.
Lo que esto significa para la pila de datos
Una vez que defines los presupuestos de frescura, la conversación sobre la pila se vuelve más fácil.
Puedes dejar de discutir sobre lote versus streaming como ideología.
Algunas interfaces necesitan procesamiento impulsado por eventos. Algunas necesitan CDC con SLAs ajustados. Algunas están bien con sincronizaciones programadas. Algunas necesitan un camino híbrido donde el mismo workflow maneje tanto rellenos históricos como actualizaciones de baja latencia.
Esa última categoría es la que se vuelve dolorosa rápidamente si tu arquitectura divide lote y streaming en sistemas separados.
Ahora estás manteniendo dos versiones de la misma lógica de negocio. Una responde a preguntas históricas. Otra impulsa acciones en vivo. Se desincronizan. Tu agente obtiene un estado inconsistente dependiendo de qué camino tocó.
Por eso creo que el mejor diseño a largo plazo no es "tiempo real en todas partes." Es un runtime que puede manejar tanto lote como streaming, además de la orquestación a su alrededor, sin forzar al equipo a reconstruir el workflow cada vez que cambia un requisito de frescura.
Ahí es también donde encaja layline.io. El punto no es convertir cada pipeline en un stream. El punto es permitir que los equipos ajusten la frescura donde la acción lo requiere, mantengan el lote donde es suficiente y gestionen ambos en un solo modelo operativo.
La prueba práctica
Si tu equipo está implementando agentes de IA ahora mismo, haz una pregunta para cada acción del agente:
¿Cuál es la edad máxima de los datos que podemos tolerar antes de que esta acción se vuelva insegura, incorrecta o embarazosa?
Escribe el número.
Si nadie puede responderlo, aún no tienes un problema de IA. Tienes un problema de requisitos.
Y si la respuesta es "depende," está bien. Desglósalo por interfaz hasta que deje de depender.
Los equipos que hagan esto bien no serán los que tengan la pila de IA más ruidosa. Serán los que sepan qué decisiones necesitan segundos, cuáles necesitan minutos, cuáles pueden esperar hasta mañana y dónde aún pertenece un humano en el bucle.
Eso suena menos emocionante que las demostraciones habituales de agentes.
También es la diferencia entre un sistema útil y uno que crea un nuevo tipo de rotación de guardia.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresariales que maneja tanto cargas de trabajo por lotes como en tiempo real a escala.
