Por qué los datos de fábrica nunca llegan a IA

El paradójico desperdicio de datos en plantas conectadas

La automatización industrial en las últimas dos décadas ha transformado el panorama de captura de datos. Plantas mineras en Perú y Chile, refinerías en México, y fábricas de alimentos en Brasil han invertido decenas de millones en sensores de presión, temperatura, vibración y corriente. Los equipos generan terabytes diarios de información operativa. Sin embargo, ese caudal de datos termina archivado en silos de históricos sin procesar, nunca alimentando algoritmos de inteligencia artificial que podrían anticipar fallas, optimizar energía o mejorar calidad. Es una paradoja de inversión: se pagó por los datos, pero no por la arquitectura para usarlos.

Donde se atora el flujo: tres nudos arquitectónicos

En la cumbre de IA industrial 2026, especialistas de tres empresas clave revelaron que el problema no es técnico sino estructural. Albemarle Corporation, Cybus y HiveMQ identificaron tres patrones recurrentes:

Historiadores sin contexto. Los sistemas SCADA y DCS tradicionales almacenan series de tiempo en bases de datos de históricos (InfluxDB, Wonderware, OSIsoft PI) que capturan magnitudes pero pierden metadatos operacionales. Un sensor de presión registra “4.2 bar” pero no queda vinculado a qué línea de producción lo generó, bajo qué receta, o si había una alarma previa. Este aislamiento semántico hace que los modelos de aprendizaje automático reciban ruido sin estructura.

Aplicaciones desconectadas. Cada software de planta (MES, ERP, sistema de mantenimiento predictivo) opera en su propia base de datos. El MES de Schneider Electric o Dassault sabe qué ordenes están en proceso, pero no dialoga en tiempo real con el historiador que almacena variables de máquina. La información se exporta en lotes nocturnos en archivos CSV, lo que introduce latencias de horas o días fatales para decisiones en línea.

Falta de orquestación. No existe capa middleware que normalice formatos, limpie anomalías ni enrute datos según quién los necesita. Sin brokers de mensajes con inteligencia (OPC UA con capacidades edge, MQTT con reglas condicionales), el dato bruto nunca llega filtrado a plataformas de IA.

Cómo funciona una arquitectura que detiene datos

Un ejemplo concreto: en una planta de procesamiento de minerales, un PLC Siemens S7-1500 captura 150 variables cada 500 milisegundos. El historiador OSIsoft PI las almacena comprimidas. Pero el modelo de IA para detección de desgaste de molino entrenado en TensorFlow necesita esas 150 variables más cinco etiquetas de contexto (humedad del mineral, densidad, temperatura ambiente, velocidad de alimentación teórica, código de producto). Hoy eso requiere que un ingeniero manualmente ejecute un script Python que consulta el PI, luego busca manualmente en el MES, luego normaliza formatos, luego alimenta el modelo. Ese pipeline semanal nunca captura eventos sorpresivos.

La solución requiere una arquitectura de tres capas: (1) capa de captura normalizada con protocolos OPC UA o MQTT que extraigan datos con metadatos contextuales; (2) capa de mediación (ej. brokers como HiveMQ o plataformas Cybus) que limpien, fusionen y enruten hacia sistemas aguas abajo; (3) capa de consumo donde modelos de IA acceden a datos listos, con baja latencia, sin transformaciones manuales.

Lectura para la industria latinoamericana

Esta realidad toca duramente al sector manufacturero de la región. En México, Brasil, Colombia y Perú, muchas plantas medianas y grandes instalaron automatización hace 10-15 años bajo arquitectura puramente de control: los datos eran un subproducto, no un activo. Hoy tienen historiadores llenos pero ninguna estrategia de AI.

Los proveedores regionales como Schneider Electric (presente en todas partes), ABB, Siemens e integradores locales (Asegeya en Colombia, Multibras en Brasil, Pirelli en Perú) ofrecen modernizaciones puntuales (cambiar PLC viejo, actualizar HMI), pero rara vez abordan la orquestación de datos para IA. Cybus —empresa alemana en expansión en LatAm— y HiveMQ ofrecen middleware especializado, pero requieren buena gobernanza interna.

Para un ingeniero de planta en Monterrey, Lima o São Paulo, el aprendizaje concreto es: antes de licitar un modelo de IA predictiva, audita tu arquitectura de datos. Pregunta: ¿El histórico de tu SCADA tiene metadatos contextuales o solo timestamps y valores? ¿Tu MES conversa en tiempo real con tu historiador o exporta CSVs nocturnos? ¿Qué protocolo usa tu PLC para salir de la máquina: OPC UA (recomendado) o puertos heredados (riesgoso para datos limpios)? Si la respuesta a estas tres preguntas no es satisfactoria, invertir 200 mil dólares en consultoría IA fracasará.

Además, la brecha de talento es real: contratar un especialista en OPC UA, MQTT y arquitectura de datos es difícil en regiones donde los ingenieros de PLC siguen siendo mayoría. Esto favorece a integradores calificados que pueden subsanar la brecha.

Vigilancia futura y opciones técnicas

En los próximos años, se espera que plataformas como Cybus (que automatiza la ingeniería de conectividad) y brokers MQTT evolucionados (ej. HiveMQ Enterprise con procesamiento de reglas) se conviertan en estándares regionales. También surgirán más soluciones edge que limpien datos in situ antes de enviar a la nube, reduciendo ancho de banda.

El estándar IEC 61131-3 evolucionará hacia lenguajes que permitan contexto semántico integrado en el controlador, no solo después. Y las certificaciones CMMC en ciberseguridad OT también empezarán a requerir auditorías de arquitectura de datos, no solo perímetro.

Para ingenieros que hoy planifican modernizaciones, el mensaje es claro: gastar en sensores sin invertir en la tubería que lleva datos a IA es tirar dinero. La próxima ola no será de hardware, sino de software de orquestación.