Por Andrew Tan
Por qué el 85% de las empresas no están listas para la IA
El benchmark de Fivetran de 2026 encontró que el 85% de las empresas ejecutan IA agentica en infraestructura que no está lista. El modelo no es el problema. Los data pipelines que lo alimentan sí lo son.
Aquí hay un patrón que está apareciendo en un número creciente de lugares:
Una empresa pasa seis meses evaluando LLMs: Ejecutan benchmarks, negocian contratos, construyen una prueba de concepto. El modelo se ve genial. Luego lo despliegan en producción y los agentes comienzan a alucinar de maneras que no tienen nada que ver con el modelo en absoluto.
La IA está bien, pero los datos que la alimentan no lo están.
Esto es lo que realmente mide el Informe de Benchmark de Infraestructura de Datos Empresariales 2026 de Fivetran cuando dice que el 85% de las empresas no están listas para la IA agentica. No es que sus modelos estén equivocados, sino que sus pipelines están equivocados.
Lo que realmente significa "no estar listo"
La frase "infraestructura lista para IA" se usa para vender muchas cosas. Usualmente significa algo vago sobre la escalabilidad en la nube. Eso no es lo que mide el informe de Fivetran.
Los tres problemas concretos que identificaron:
Datos obsoletos. El agente está razonando sobre el estado de ayer. Para un agente de servicio al cliente, eso significa que no sabe que ya se emitió un reembolso. Para un agente de detección de fraudes, está trabajando con patrones que tienen 18 horas de antigüedad. Los pipelines por lotes que se ejecutan por hora o por noche no pueden soportar agentes que necesitan actuar sobre lo que está sucediendo ahora.
Sin aplicación de esquemas. Los sistemas de origen cambian constantemente. Las columnas se renombran, los tipos se amplían, aparecen nuevos campos. Si tu pipeline no aplica contratos de esquema aguas abajo, un agente puede recibir datos malformados que parecen válidos y actuar con confianza sobre ellos.
Sin observabilidad. La mayoría de los monitoreos de pipelines te dicen si un trabajo se ejecutó. No te dicen si los datos son correctos. Un agente puede estar consumiendo datos de un pipeline que técnicamente está funcionando pero que está dejando caer silenciosamente el 20% de los eventos. No lo sabrás hasta que alguien note que el agente está actuando de manera extraña, y para entonces el daño ya está hecho.
Estos no son problemas nuevos. Son los mismos problemas de calidad de datos que han plagado a los equipos de análisis durante años. Lo que cambió es el radio de explosión. Un problema de calidad de datos en un panel de BI es un gráfico incorrecto. Un problema de calidad de datos en un sistema agentico es una decisión autónoma tomada con información incorrecta.
La desajuste de la pila
El problema de la pila de datos lista para IA es un desajuste profundo en las suposiciones de arquitectura.
La mayoría de las pilas de datos empresariales se construyeron en torno al procesamiento por lotes. Trabajos ETL nocturnos. Actualizaciones diarias del almacén de datos. Paneles que se actualizan cada mañana. Todo el sistema estaba optimizado para el throughput sobre la frescura.
Los agentes de IA tienen diferentes requisitos. Necesitan datos que estén actualizados, no solo precisos. Necesitan actuar sobre lo que está sucediendo en los últimos segundos o minutos, no en las últimas doce horas. Y cuando están equivocados, necesitan que el sistema lo detecte, no solo lo registre y siga adelante.
Las empresas que están listas, el 15%, no necesariamente reemplazaron toda su pila. La mayoría de ellas cambiaron a tiempo real donde importa y mantuvieron el procesamiento por lotes donde tiene sentido. El flujo de pedidos de clientes se ejecuta en tiempo real. La contabilidad de costos trimestral todavía se ejecuta por la noche. La diferencia es la intencionalidad: tomaron decisiones explícitas sobre qué datos necesitan frescura y construyeron pipelines en consecuencia.
Las tres propiedades que realmente importan
Hay mucho ruido sobre lo que requiere la infraestructura "lista para IA". Usualmente es una lista de verificación de un proveedor que convenientemente se ajusta a su producto. Así que aquí está la versión que se ajusta a los modos de falla reales:
Frescura. No solo "tiempo real para todo", eso es caro y a menudo innecesario. Pero para los datos sobre los que tus agentes realmente actúan, necesitas conocer el retraso y tener garantías sobre él. Si tus datos de clientes tienen 4 minutos de antigüedad, está bien, siempre y cuando tu agente lo sepa y actúe en consecuencia. Lo que rompe a los agentes es cuando asumen que los datos están actualizados y no lo están.
Consistencia. Los agentes a menudo combinan datos de múltiples fuentes para tomar una decisión. Si esas fuentes están funcionando en diferentes horarios o en diferentes niveles de frescura, obtienes inconsistencias sutiles que son difíciles de depurar. Una búsqueda de cliente dice que la cuenta está activa; el flujo de transacciones no se ha actualizado y la muestra como pendiente de cierre. El agente toma una decisión que es correcta para cada fuente individualmente pero incorrecta para el estado combinado.
Observabilidad a nivel de evento. El monitoreo de pipelines te dice sobre trabajos. La confiabilidad del agente requiere monitoreo de eventos individuales. ¿Se están procesando o descartando eventos? ¿El esquema coincide con lo que el agente espera? ¿Hay ráfagas que abruman a los consumidores aguas abajo? Esta es una clase diferente de monitoreo de la que la mayoría de los equipos han construido.
Lo que esto significa para la decisión de construir vs. comprar
La ola de IA está sacando a la luz una factura que se ha estado acumulando en muchas organizaciones de ingeniería: el costo de tratar la infraestructura de datos como un problema resuelto.
Los equipos que construyeron pipelines por lotes personalizados hace dos años y lo dieron por terminado ahora enfrentan una elección difícil: adaptar el tiempo real a un sistema que no fue diseñado para ello, o reconstruir. Ninguna opción es barata. Adaptar tiende a producir el problema de dos pipelines: un sistema por lotes para el historial, un sistema de streaming para el tiempo real, dos bases de código haciendo aproximadamente lo mismo con lógica ligeramente diferente y resultados perpetuamente divergentes.
Los equipos que manejan esto bien son los que no tienen que tomar esa decisión. Cuando el procesamiento por lotes y el streaming se ejecutan como los mismos pipelines con las mismas herramientas, cambiar un Workflow de horario a tiempo real es un cambio de configuración, no una reescritura. La observabilidad, la aplicación de esquemas, el manejo de fallas, viene con la plataforma, no como una construcción personalizada encima.
Eso es para lo que layline.io está construido. No solo tiempo real por su propio bien, sino la capacidad de tomar decisiones explícitas e intencionales sobre la frescura de los datos en toda la pila, sin mantener dos sistemas separados para llegar allí.
La pregunta para reflexionar
El número del 85% es impactante. Pero la pregunta más interesante es: ¿cuántas de esas empresas saben que están en ese 85%?
Los equipos que están en problemas no suelen ser los que tienen pipelines obviamente rotos. Son los que tienen pipelines que parecen funcionar: trabajos ejecutándose, paneles cargándose, sin incidentes activos, pero con problemas de confiabilidad silenciosos que solo aparecen cuando un agente de IA comienza a tomar decisiones importantes sobre los datos.
Si tus agentes están actuando de manera extraña y ya has descartado el modelo, mira los datos.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresariales que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.
