Tu científico de datos no puede entender la planta: por qué el valor de la IA industrial depende del ingeniero de campo*
En la industria se discute mucho sobre si conviene nube o edge, qué stack usar, qué base de datos “gana”, o qué modelo de IA está de moda. Pero esa conversación suele estar desalineada con el problema real. La batalla decisiva no se gana en la arquitectura “cool”, sino en algo menos glamoroso: la traducción entre el mundo físico (equipos, operación, mantenimiento, restricciones reales) y el mundo digital (tablas, features, modelos).
Un modelo puede ser estadísticamente impecable y aun así producir conclusiones absurdas en operación. ¿Por qué? Porque en planta, el contexto manda.
El “Por qué” vale más que el “Qué”
Capturar millones de puntos de datos es relativamente fácil. Lo difícil es saber qué significa cada punto en el entorno real. Un mismo valor puede ser normal o anómalo dependiendo de condiciones que no están explícitas en el tag: modo operativo, cambios de blending, limpiezas, mantenimientos, intervenciones manuales, desvíos permitidos por seguridad, degradaciones conocidas, etc. Esa diferencia no vive en el data lake: vive en la experiencia del personal de campo.
En pocas palabras, la planta no es un dataset limpio. Es un sistema socio-técnico con decisiones humanas, restricciones físicas y excepciones permanentes.
De “Pipelines de datos” a “Pipelines de conocimiento”
Durante años, muchas estrategias se centraron en mover datos desde A hacia B: PLC → SCADA → historiador → nube → modelo. El problema es que el valor industrial no aparece porque los datos “viajen”, sino porque el conocimiento operativo se adjunte a esos datos.
El cambio clave es pasar de pipelines que solo transportan señales, a flujos que transporten significado:
- Anotaciones operativas en el momento: “válvula se pegó”, “se aplicó override manual”, “se operó en recirculación”, “se cambió setpoint por calidad”, etc.
- Vincular eventos de negocio/producción (lotes, campañas, órdenes) con firmas de datos de proceso (tendencias, vibración, energía, caudales).
- Registrar condiciones de frontera: paradas programadas, “micro-paros”, cambios de turno, variaciones por materia prima, restricciones por seguridad.
Ese “metadata contextual” es la piedra Rosetta de la analítica industrial, permite que un analista o un algoritmo interprete correctamente lo que ve. Si la data no la contiene, se tiene que construir en algún punto.
El primer error común: Resolver problemas de OT con herramientas de IT
Lo que hemos visto en los últimos años es que muchas empresas intentan resolver lo antes expuesto invirtiendo ingentes cantidades de dinero en construir “pipelines” de datos desde la planta: PLCs, SCADAs, Historians, Bases de Datos, etc. a aplicaciones cloud. Solo ese proceso de arquitectura/ingeniería de datos, es un proyecto en sí mismo y puede tomar meses o años, dependiendo de la madurez tecnológica de OT.
Pero hasta aquí no se ha generado valor, solo se han movido datos como se explicó anteriormente.
Ahora tenemos que tratar los datos y construir los casos de uso, modelos, reportes, dashboards, análisis avanzados, cálculos, entre otros. Entonces, muchas veces mal asesorados, se contratan primero plataformas tecnológicas típicas del entorno de TI para tratar los datos y luego analistas y científicos de datos que ven el dato como eso, un dato y punto.
Pero el dato industrial no es solo “un dato” tiene otro tipo de características, por mencionar ejemplos, en su mayoría son tags (VQT), sin el contexto no son entendibles, llegan a una frecuencia de muestreo que puede alcanzar los nanosegundos y tienen un volumen gigantesco, se calcula que una planta promedio genera datos pueden ir desde GB/día (solo series de tiempo típicas de historiador) hasta TB/día cuando agregas alta frecuencia, calidad, video, logs y más.
Utilizar herramientas y perfiles de TI para resolver ese problema es como intentar meter un círculo en un cuadrado. El problema es que muchas empresas ya empezaron a invertir dinero en esa arquitectura, poco escalable, usando las herramientas equivocadas y pidiéndole a perfiles no preparados para la tarea, que den resultados.
El rol crítico: el ingeniero “bilingüe” (OT–IT)
En casi toda planta que sí logra escalar analítica avanzada aparece (formal o informalmente) un perfil clave: el ingeniero bilingüe, alguien que entiende tanto el diagrama P&ID y la física del proceso, como los conceptos de datos, scripts y modelado.
Este rol evita el fracaso típico: “modelo brillante” que detecta una “anomalía” que, en realidad, fue una condición normal; por ejemplo: un modelo detecta ‘anomalía’ en potencia del motor. El ingeniero de campo sabe que esa firma coincide con el modo de recirculación por limpieza (CIP) o con un bypass temporal. Sin ese contexto, el modelo dispara falsos positivos y pierde confianza.
Invertir en este “puente” (personas + herramientas) suele mover más la aguja que discutir arquitecturas de ML antes de tiempo.
Primer paso pragmático: analítica descriptiva bien resuelta (historiadores + contexto)
Para empezar, es muy importante entender algunos conceptos clave como son:
- Analítica Descriptiva/diagnóstica: Nos responde las preguntas “¿Qué pasó y por qué probablemente pasó?” (tendencias, límites históricos, comparativos, reglas).
- Analítica Predictiva/prescriptiva: Nos responde las preguntas “¿Qué pasará y qué conviene hacer?” (Machine Learning, optimización).
Entonces, mucha gente se equivoca por exceso de ambición. Saltan directo a “IA en la nube” cuando todavía no dominan lo básico:
- Calidad de señal (timestamp, interpolación, gaps),
- trazabilidad de eventos,
- visualización rápida,
- KPIs y comparativos,
- cálculos estándar,
- contexto operacional y modelo de activos.
En la práctica, una enorme cantidad de casos de uso se resuelven con analítica descriptiva y diagnóstica bien implementada: tendencias, comparaciones por modo/lote, detección simple de outliers, balances, correlaciones básicas, límites estadísticos históricos, reglas y cálculos operativos.
Un historiador industrial existe precisamente para almacenar y servir datos de series de tiempo de automatización de forma eficiente. Canary, por ejemplo, está diseñado y optimizado para lectura/escritura de series de tiempo industriales con las características que se explicaron anteriormente, millones de tags, millones de escrituras por segundo, capacidad de contextualización a través de árboles de activos, etc. en definitiva, deja el dato listo y con contexto para ser procesado.
Además, el ecosistema de Canary incluye herramientas cliente para tendencias, tableros y reportes (Axiom), orientadas a autoservicio, incluyendo dashboards, trends, reportes y más.
Y, cuando necesitas ir más allá de “ver tendencias”, puedes incorporar cálculos y alarmas a nivel de plataforma (por ejemplo, funciones agregadas y librerías de cálculo).
¿Cómo podemos traducir esto al negocio? Si resuelves rápido la capa descriptiva/diagnóstica cerca de la operación, reduces la necesidad de construir pipelines complejos a la nube para problemas que no lo ameritan (y evitas depender de servicios especializados para cada iteración).
Cuando sí necesitas escalar: que el científico de datos venga al contexto industrial (no al revés)
Cuando el caso exige modelos más sofisticados (ML, híbridos, simulación, optimización, detección avanzada), el error común es “extraer todo” a un entorno donde se pierde el contexto, la trazabilidad y la velocidad de iteración con el personal de planta.
La alternativa más efectiva suele ser la contraria:
- Mantener el análisis “pegado” a la operación, esto no necesariamente significa que no se pueda hacer en herramientas SaaS en la nube, pero si en herramientas que le sean diseñadas para la operación.
- y habilitar al científico de datos a trabajar sobre ese contexto, con acceso gobernado, repetible y compartible.
Ahí entra la idea de una herramienta colaborativa, donde:
- el ingeniero de proceso/confiabilidad hace análisis en su lenguaje (tendencias, condiciones, comparativos, cálculos), parecido a lo que está acostumbrado en los sistemas SCADA o historiadores
- y el científico de datos puede profundizar (Python, notebooks, librerías, versiones, escalamiento).
Un concepto clave aquí es que el ingeniero “bilingüe” es el puente entre la operación y los científicos de datos, se encarga que los ingenieros de procesos entiendan y también hagan un poco de ciencia de datos, en sus capacidades –finalmente los ingenieros tienen una base matemática y estadística muy sólida para interpretar ciencia de datos-; pero que los científicos de datos también entiendan los bemoles de la planta industrial e incorporen las restricciones operativas en los modelos para que el resultado no sea la predicción de una falla cuando al equipo le toca limpieza. Para esto se necesita de un equipo: operación + ingeniero bilingüe + científico de datos trabajando colaborativamente, pero para eso se necesita una plataforma que lo permita.
Seeq como “Plataforma puente” entre ingeniería de planta y ciencia de datos
Seeq Workbench se posiciona precisamente como un entorno para analizar datos industriales (series de tiempo y fuentes industriales) en (casi) tiempo real, con foco en acceso, limpieza, cálculos y hallazgo de insights.
Dos perfiles, un mismo espacio de colaboración :
1) Ingeniero de campo “bilingüe” (y también el no-bilingüe):
Puede partir con análisis “point-and-click”: condiciones, overlays, cálculos, comparaciones por ventanas de operación, histogramas, diagramas de dispersión, etc. (Lo esencial para generar hipótesis con velocidad y con sentido operacional).
2) Científico de datos / analista avanzado:
Puede extender el trabajo con Python mediante Seeq Data Lab (Jupyter + librería spy), extrayendo datos a DataFrames y regresando resultados al entorno compartido.
Esto es clave: el científico de datos no trabaja “aislado”; trabaja sobre el mismo universo de datos industriales y devuelve resultados consumibles por operación.
Cuando los clientes deciden ir por el camino de la construcción de “pipelines” a la nube, en la práctica están aislando al ingeniero de campo del tratamiento de sus propios datos. Ellos tienen muchas cosas que hacer para volverse también en expertos certificados en plataformas Cloud para poder participar del proceso de ciencia de datos.
IA Generativa: acelerar el “Time-to-value” (si está conectada a datos reales)
La IA generativa no reemplaza el conocimiento de campo; lo potencia. Su impacto real aparece cuando:
- está conectada al contexto industrial (datos históricos + condiciones + metadatos),
- puede responder preguntas de operación,
- y ayuda a producir entregables accionables: explicaciones, hipótesis, borradores de análisis, y hasta código.
Veamos unos ejemplos concretos de como se puede usar la IA Generativa para generar valor con los datos industriales. Seeq ya presenta un AI Assistant integrado, con agentes seleccionables para ayudar en analítica y “how-to” dentro de la herramienta.
En un flujo maduro, esto habilita casos como:
- Consultas en lenguaje natural: “¿Qué cambió en las últimas 2 semanas cuando sube el consumo específico?”
- Hallazgo guiado de insights: sugerir variables candidatas, ventanas de comparación, breakdown por estados.
- Aceleración de programación: borradores de scripts, plantillas de transformaciones, ejemplos para librerías (con revisión humana).
Ojo: la IA generativa no valida la física del proceso. Lo que hace es reducir fricción en el trabajo analítico. La validación sigue siendo humana (ingeniería de campo + confiabilidad + proceso).
Finalmente, es importante mencionar que GenAI acelera análisis, pero requiere gobernanza: control de acceso, trazabilidad de fuentes, validación humana, y políticas de no ‘inventar’ conclusiones.
Un marco simple para decidir qué hacer primero.
1.Asegura la capa descriptiva (conectividad, historiador, trends, reportes, eventos, calidad de datos).
- Aquí Canary y la disciplina de contextos resuelven gran parte del valor inicial. En otro artículo hablaremos del valor del UNS y herramientas de conectividad, contextualización y DataOps que pueden ser un primer paso muy valioso, especialmente para manufactura discreta.
2.Institucionaliza el contexto (anotaciones, estados, modo operativo, lotes, mantenimiento).
3.Habilita colaboración real (ingeniero bilingüe + plataforma compartida).
4.Escala analítica avanzada donde vive la operación (no “exportando” el problema).
5.Introduce GenAI para acelerar, no para improvisar (asistente conectado a datos).
El futuro no es “más IA”, es “datos que cuentan la verdad de la planta”
En industria, la ventaja no la tiene quien acumula más tags, ni quien tiene un Data Lake más grande, ni más “pipelines”, ni quien prueba más modelos. La ventaja la tiene quien logra que sus datos cuenten una historia operacional verdadera: con contexto, estados, anotaciones y colaboración entre quienes saben operar y quienes saben modelar. Esa historia no la escribe un solo rol: la coescriben operación, ingeniería y analítica, sobre una plataforma diseñada para trabajar juntos.
*Articulo basado en “The New Industrial Trade: Your Data Scientist is Useless Without Your Floor Technician”