Hay un patrón que se repite en casi todas las organizaciones que intentan llevar la IA más allá de los proyectos piloto. Los modelos funcionan bien en las demos. Los resultados en producción decepcionan. Y el diagnóstico que suele emerger después de meses de trabajo y presupuesto gastado es siempre el mismo: el problema no estaba en el modelo.
Jay Kreps, CEO de Confluent, lo articuló con precisión en la apertura de Current 2026 en Londres, y merece más atención de la que suelen recibir los discursos de CEOs en eventos de producto. No porque sea nuevo, él mismo reconoce que la tesis central de Confluent lleva años siendo la misma, sino porque en 2026 el argumento ha ganado una urgencia diferente. Las organizaciones ya no están evaluando si quieren usar IA. Están descubriendo por qué no les funciona.
El cambio que nadie ha terminado de procesar
Durante décadas, construir software empresarial ha significado construir sistemas de reglas. Lógica de negocio codificada en if-else, flujos deterministas, comportamientos predecibles. Para validar que ese sistema funciona, se escriben tests unitarios que recorren todos los caminos posibles. Los datos son irrelevantes para esa validación: puedes usar datos ficticios, inventados, sin ninguna conexión con la realidad de producción, y el sistema funcionará igual.
Cuando introduces modelos probabilísticos en ese sistema, todo esto se rompe. No porque los modelos sean peores que las reglas, sino porque responden a una lógica diferente. No puedes validar un agente que va a gestionar incidencias de clientes usando datos ficticios. Necesitas datos reales, problemas reales, el desorden real de la operación. Y la validación no es binaria: no hay un test que pase o falle. Hay una métrica estadística que mejoras de forma incremental. «Resolvemos correctamente el 90% de los casos. Ahora el 94%.» Eso no es un bug que se corrige, es un proceso continuo de mejora.
Esta distinción tiene una implicación que muchos equipos de ingeniería están descubriendo tarde: en los sistemas de IA, el desarrollo y el dato son inseparables. No puedes construir el sistema y luego añadir los datos. El dato es parte del sistema desde el primer día, y la calidad del dato determina directamente la calidad del resultado.
Por qué el dato empresarial es el problema
Si aceptamos que el dato es parte del sistema, el siguiente problema es que el dato empresarial real es, en palabras de Kreps, un desastre. Bases de datos legadas, aplicaciones construidas en momentos distintos con esquemas distintos, silos que nunca fueron diseñados para hablar entre sí. Cualquier arquitecto que haya tenido que integrar sistemas en una organización mediana reconocerá esa descripción.
El reto no es acceder a ese dato. El reto es hacerlo de forma que el agente pueda usarlo de manera fiable, segura y evaluable. Y aquí es donde las dos soluciones obvias se quedan cortas.
La primera es la más tentadora: darle al agente acceso directo a todo. Las bases de datos, las APIs, los sistemas operacionales. Si el agente necesita contexto, que lo busque. En una demo, esto funciona sorprendentemente bien. En producción, los problemas son estructurales. El agente accede a datos que no debería ver. Consume recursos de sistemas productivos que no están diseñados para ese tipo de carga. Genera outputs que incluyen información sensible que no debería aparecer. Y lo más importante: es un entorno que no puedes controlar, versionar ni mejorar de forma sistemática. Si el agente da un resultado incorrecto, no sabes por qué ni cómo replicarlo.
La segunda solución es más ordenada: extraer los datos relevantes, transformarlos, cargarlos en una base de datos dedicada para el agente. Datos limpios, estructurados, exactamente lo que el agente necesita. El problema es el tiempo. Esos pipelines de extracción y transformación funcionan en batch. El dato que el agente recibe tiene horas de retraso, a veces días. Para un agente que gestiona interacciones en tiempo real con clientes, que toma decisiones sobre el estado actual de la operación, trabajar con una versión obsoleta de la realidad no es una limitación técnica menor. Es una invalidación del caso de uso.
El argumento del streaming como infraestructura natural
La propuesta de Confluent es que ninguna de las dos soluciones es correcta porque ambas asumen que el dato es estático. La alternativa es tratar el dato como lo que realmente es en cualquier organización que opera en tiempo real: algo que cambia continuamente y que necesita procesarse continuamente.
Esto es lo que el streaming resuelve en su formulación más simple. En lugar de mover datos desde los sistemas origen hacia un destino en momentos discretos, el streaming mantiene un flujo continuo en el que el dato se procesa, enriquece y gobierna mientras se mueve. El resultado es que el contexto que recibe el agente refleja el estado actual de la operación, no el estado de hace ocho horas.
Pero hay una complejidad que Kreps no elude y que distingue este argumento de un mensaje de ventas. Construir pipelines de streaming en producción es difícil. No porque la tecnología no funcione, sino porque el ciclo de desarrollo de un sistema de IA requiere algo que el streaming puro no facilita por defecto: la capacidad de iterar en entorno offline antes de desplegar en producción.
Si tienes un agente que procesa eventos en tiempo real y quieres mejorar el contexto que recibe, necesitas poder testear ese cambio sin tocarlo en producción. Necesitas poder simular qué habría pasado si hubieras aplicado ese cambio a los últimos seis meses de datos históricos. Eso requiere que el sistema de streaming tenga una representación histórica del dato que puedas consultar como si fuera un batch, con la misma lógica con la que opera en tiempo real.
La unificación de batch y streaming, que es en esencia lo que Confluent está construyendo con la combinación de Tableflow y Flink, no es un objetivo técnico en sí mismo. Es la condición necesaria para que el ciclo de desarrollo de sistemas de IA sea viable en entornos empresariales reales.
La ingeniería de contexto como disciplina emergente
Hay un cambio de perspectiva en el argumento de Kreps que vale la pena señalar explícitamente. En el ecosistema de IA, la atención se ha concentrado en los modelos: qué modelo es mejor, cómo se afina, cómo se evalúa. Eso tiene sentido en un momento en que los modelos fundacionales eran el factor limitante.
Pero los modelos han madurado. Para la mayoría de los casos de uso empresariales, el modelo disponible hoy es suficientemente bueno. El factor limitante ya no es la capacidad de razonamiento del modelo. Es la calidad y la frescura del contexto que se le proporciona.
Esto significa que el trabajo de mejora continua en un sistema de IA no está en el modelo, que probablemente no controlas porque lo provee un tercero, sino en el dato. En construir mejores pipelines de contexto, mejores esquemas, mejores transformaciones. En gobernar ese dato más cerca del origen para que llegue al agente con la estructura y la calidad que necesita.
Steffen Hoellinger, Field CTO de Confluent para EMEA, lo expresó de forma directa en una conversación con La Ecuación Digital: el contexto que le das a un agente determinará si tu organización prospera o no en la próxima década. No el modelo que eliges. No el framework de agentes que adoptas. El contexto.
Eso convierte la ingeniería de datos, que ha sido históricamente una función de soporte en muchas organizaciones, en una capacidad estratégica central. Y convierte el streaming, la infraestructura que hace posible que ese dato sea fresco, gobernado y reutilizable, en algo más parecido a una apuesta de fondo que a una elección tecnológica.
Lo que esto significa en la práctica
El argumento estratégico de Kreps tiene una consecuencia práctica que las organizaciones tienden a subestimar: el problema no se resuelve con una herramienta, se resuelve con una transformación en cómo se diseña la arquitectura de datos desde el principio.
Las empresas que están obteniendo valor real de la IA, según lo que se discutió en Current 2026, comparten una característica: han invertido en hacer el dato comprensible para los sistemas antes de intentar que esos sistemas lo usen. Esquemas bien definidos, linaje documentado, gobernanza en el origen. No como ejercicio de cumplimiento regulatorio, sino como condición previa para que cualquier sistema —humano o automatizado— pueda operar con él de forma fiable.
Gartner estima que la empresa Fortune 500 media tendrá más de 150.000 agentes operando en su organización en 2028. La mayoría de esos agentes necesitarán contexto para funcionar. Ese contexto tiene que venir de algún sitio, procesarse de alguna manera, y mantenerse actualizado de forma continua. Las organizaciones que no hayan construido esa infraestructura antes de que llegue esa escala se encontrarán con el mismo problema que tienen hoy con sus proyectos piloto, multiplicado por un orden de magnitud.
El streaming no es la solución a ese problema. Es la infraestructura que hace posible que la solución exista.
