La mayoría de los proyectos de IoT se detienen en el dashboard. Los sensores vuelcan temperatura, vibración, presión y corriente en gráficos, y el equipo mira. Los dashboards hacen bien su trabajo: muestran lo que pasó. El problema es que nada en un dashboard avisa de que una bomba va a fallar el jueves que viene.
Los modelos de analytics cierran esa brecha. Aprenden el comportamiento normal de cada activo a partir de su propio historial y luego evalúan cada lectura nueva contra ese patrón. La salida no es otro gráfico que interpretar. Es una probabilidad, una previsión o una cuenta atrás sobre la que se puede actuar: pedir la pieza, programar al equipo, mover la carga antes del pico.
Este artículo trata de qué es realmente un modelo de analytics, por qué un modelo estadístico ajustado supera a un modelo de IA de propósito general al evaluar telemetría, qué familia de modelos responde cada pregunta y qué dice la investigación publicada sobre el retorno. Para la introducción a la analítica descriptiva, predictiva y prescriptiva, empieza por qué significa la analítica predictiva para IoT.
Cómo funciona la analítica de IoT, del sensor a la decisión
El pipeline corre en cuatro pasos: recopilar datos de los sensores, entrenar un modelo sobre ese historial, ejecutar inferencias sobre lecturas nuevas y actuar sobre el resultado.
La recopilación es la parte que la mayoría de los equipos de IoT ya tiene. Los dispositivos reportan según un intervalo, la plataforma guarda las lecturas como series temporales y se acumulan unas semanas de historial. Ese historial es la materia prima de todo lo demás. Cuánto necesitas depende del modelo y de la estacionalidad que quieras capturar, y conviene resolverlo antes de entrenar nada.
El entrenamiento ocurre de vez en cuando. El modelo lee el historial una vez y extrae la estructura: el ciclo diario, el ciclo semanal, la tendencia, la relación entre variables. La inferencia ocurre de forma continua y cuesta casi nada. Cada lectura nueva se evalúa contra el patrón aprendido en milisegundos. Para la mecánica de dónde corre el entrenamiento y dónde la evaluación, consulta cómo ejecutar machine learning sobre datos de IoT.
El último paso es donde aparece el valor. Una previsión que cruza un límite puede abrir una orden de trabajo. Una puntuación de anomalía puede avisar a un técnico. Una predicción de demanda puede aterrizar en el mismo dashboard que ya usa el equipo de operaciones, junto a las lecturas en vivo.
¿Qué es un modelo de analytics en IoT?
Un modelo de analytics es una descripción matemática de cómo se comporta una variable a lo largo del tiempo, ajustada a tus propios datos de sensores. Una vez ajustado, responde preguntas que los datos brutos no responden: cuánto marcará este sensor la semana que viene, si el patrón de vibración de hoy es inusual, cuántos días faltan para que un tanque alcance su límite.
El modelo también cambia lo que puede ser un KPI. La disponibilidad del mes pasado y la temperatura media de ayer son números que miran atrás; describen un pasado que nadie puede cambiar. Un modelo produce KPIs que miran adelante: probabilidad de fallo este mes, días hasta el límite, un índice de salud por activo, demanda prevista con intervalo de confianza. Esos son los KPIs sobre los que alguien puede actuar, porque el evento que describen todavía no ha ocurrido.
Los intervalos de confianza importan más de lo que parece. Una previsión de “82 kWh mañana, entre 76 y 88 con un 95% de confianza” permite planificar con riesgo conocido en lugar de por intuición. Esa es la diferencia entre echar un ojo a un gráfico y tomar una decisión que puedes defender.
Los dashboards siguen en escena. La idea no es sustituirlos, sino cambiar lo que muestran: las salidas del modelo llegan como variables nuevas, así que la misma pantalla que muestra las últimas 24 horas también puede mostrar los próximos 7 días.
| Dashboards | Modelos de analytics con buenos KPIs | |
|---|---|---|
| Pregunta que responden | “¿Qué pasó?” | “¿Qué es probable que pase, y con cuánta certeza?” |
| Horizonte temporal | Del pasado al presente | Del presente al futuro |
| Salida | Gráficos que alguien interpreta | Previsiones, probabilidades, puntuaciones de anomalía |
| Cómo empieza la acción | Alguien lo nota y entonces reacciona | Las alertas y órdenes de trabajo se disparan antes del fallo |
| Apoyo a la decisión | Contexto y rastro de auditoría | Margen de tiempo y confianza cuantificada |
¿Por qué usar modelos estadísticos en lugar de IA para analizar datos de sensores?
Porque evaluar datos de sensores es un problema numérico, y un modelo entrenado lo resuelve por una fracción mínima de lo que cuesta la IA de propósito general. Los modelos de lenguaje están hechos para texto y razonamiento. Apuntar uno a telemetría bruta significa pagar precio de GPU, en cada pregunta, por una aritmética que un modelo ajustado ejecuta en una CPU en milisegundos.
La diferencia estructural está en dónde ocurre la lectura. Un modelo estadístico lee tu historial una sola vez, durante el entrenamiento. Después, cada inferencia solo toca los puntos más recientes. A un asistente de IA al que se le pregunta “¿está sano este compresor?” no le queda ningún modelo ajustado en el que apoyarse, así que tendría que reprocesar los datos relevantes cada vez. Nadie quiere un LLM releyendo miles de millones de puntos de datos porque alguien repitió la pregunta.
El determinismo es la otra brecha. Un modelo ajustado da la misma respuesta para la misma entrada, con un intervalo de confianza que puedes auditar y explicar a una responsable de operaciones o a un organismo regulador. La salida de la IA generativa puede variar entre ejecuciones, lo que encaja mal con una alerta que despierta a alguien a las 3 de la mañana.
| Modelos de analytics entrenados | IA de propósito general (LLMs) | |
|---|---|---|
| Hechos para | Series temporales numéricas | Lenguaje y razonamiento general |
| Hardware por inferencia | CPU | Clústeres de GPU |
| Coste por inferencia | Fracciones de céntimo | Órdenes de magnitud mayor |
| Latencia | Milisegundos | Segundos |
| Tratamiento de los datos | Entrena una vez sobre el historial, evalúa solo los puntos nuevos | Reprocesa los datos en cada pregunta |
| Repetibilidad | Determinista, misma entrada, misma salida | La salida puede variar entre ejecuciones |
| Explicabilidad | Tendencia, estacionalidad y límites auditables | Difícil de auditar |
| Escala a una flota | Miles de dispositivos evaluados de forma continua a coste estable | El coste crece con cada token procesado |
La IA sigue teniendo su sitio. Los asistentes sirven para construir soluciones, escribir scripts y explicar resultados, y puedes hacer preguntas a tus datos de IoT en lenguaje natural con uno. La evaluación continua y de alto volumen de datos de sensores es trabajo de modelos, igual que no contratarías a una consultora para sumar una hoja de cálculo cada hora.
¿Qué modelo encaja con cada problema?
Empieza por la pregunta que necesitas responder y solo entonces elige la familia.
Previsión responde “¿cómo se comportará esta variable a continuación?” El suavizado exponencial (ETS) y Holt-Winters proyectan una serie hacia adelante ponderando el historial reciente y sus ciclos estacionales. Son los caballos de batalla del campo, tratados en profundidad en Forecasting: Principles and Practice de Hyndman y Athanasopoulos, de la Monash University. La descomposición MSTL maneja series con varios patrones estacionales a la vez, como el consumo de energía con ciclo diario y semanal. Para ver cómo se comparan ARIMA, Prophet y las opciones neuronales sobre una misma serie, consulta qué modelo de previsión encaja con tu serie temporal de IoT.
Detección de anomalías responde “¿esto es normal?” El agrupamiento K-Means, habitual en el plan de estudios de machine learning de Stanford, agrupa los estados de operación de un activo, de modo que las lecturas nuevas que no caen en ningún grupo destacan. DBSCAN encuentra grupos por densidad, lo que ayuda a detectar el único dispositivo que se comporta distinto a sus pares. Isolation Forest separa valores atípicos rápido incluso en conjuntos grandes. La detección y la previsión resuelven problemas distintos, y recurrir a la equivocada es un error frecuente al principio.
Detección de deriva responde “¿esto está empeorando poco a poco?” Los gráficos de control EWMA, documentados en el e-Handbook of Statistical Methods del NIST/SEMATECH, ponderan las lecturas recientes contra una línea base y señalan desviaciones pequeñas y persistentes mucho antes de que revienten un límite fijo. Filtros que se incrustan, rodamientos que se desgastan y calibraciones que se van tienen exactamente esa forma.
Estimación y tiempo hasta el límite responden “¿qué determina este resultado, y cuánto tiempo tengo?” La regresión multivariante estima un objetivo a partir de los factores que lo mueven, útil cuando lo que te importa no tiene sensor propio. Combinar una previsión con un barrido de umbral convierte “el tanque está al 63%” en “el tanque llega a su límite en unos 9 días”, y eso es un plan de mantenimiento, no un gráfico.
¿El mantenimiento predictivo compensa de verdad?
Las cifras publicadas dicen que sí. El Operations & Maintenance Best Practices Guide del Departamento de Energía de Estados Unidos estima que un programa de mantenimiento predictivo en marcha ahorra entre un 8% y un 12% frente a un programa preventivo, y entre un 30% y un 40% en instalaciones que vienen de mantenimiento reactivo, del tipo funcionar hasta romper. El Pacific Northwest National Laboratory mantiene la misma línea: la programación basada en condición gana tanto al calendario como a la avería. Un estudio revisado por pares sobre mantenimiento predictivo en la Industria 4.0 llega a la misma conclusión a lo largo de decenas de estudios. La técnica funciona cuando funciona el pipeline de datos que la sostiene.
Las cifras de disponibilidad y coste de mantenimiento de Deloitte están desglosadas en simplificar el mantenimiento predictivo y no se repiten aquí.
Una advertencia honesta: las ganancias dependen de actuar. Una predicción que nadie encamina a una orden de trabajo es solo otro gráfico. El paso de acción del pipeline no es opcional.
Cómo empezar sin un equipo de ciencia de datos
Todo lo anterior se puede construir a mano con bibliotecas de código abierto, algún sitio donde ejecutarlas y alguien que mantenga el pipeline. Eso es un proyecto de verdad: extracción de datos, calendarios de reentrenamiento, almacenamiento de modelos y conexión de las salidas de vuelta a las alertas.
TagoIO Analytics empaqueta ese pipeline dentro de la plataforma a la que tus dispositivos ya reportan. Eliges una variable, un asistente entrena el modelo con los datos que ya son tuyos, y las predicciones vuelven como variables normales. Aterrizan en dashboards, disparan Actions y alimentan alertas sin una línea de código de ML.
Los pasos pesados, entrenamiento e inferencia, corren en el servicio sight.tago.io, mientras tus datos, dashboards y Actions se quedan en tu cuenta de TagoIO. El pipeline del principio de este artículo se traslada ahí directamente.
La lista de modelos se corresponde con las familias de arriba: Seasonal Forecasting (descomposición MSTL con suavizado exponencial ETS), Demand Prediction (Prophet con previsión de factores), Estimation from Drivers (regresión OLS multivariante), Quick Health Check (Isolation Forest), Continuous Monitoring (agrupamiento K-Means), Peer Comparison (agrupamiento por densidad DBSCAN), Slow Drift Detection (gráfico de control EWMA sobre una línea base estacional) y Time to Threshold (previsión Holt-Winters o AutoETS con barrido de umbral).
Si tus sensores ya están enviando datos, el paso de entrenamiento arranca desde un historial que ya es tuyo. Mira los modelos en tago.io/analytics o agenda una demo para recorrer uno con tus propias lecturas.
Fuentes
- Hyndman, R.J. y Athanasopoulos, G. (Monash University), Forecasting: Principles and Practice, 3.ª ed.
- Taylor, S.J. y Letham, B., Forecasting at Scale (Prophet), PeerJ Preprints
- Liu, F.T., Ting, K.M. y Zhou, Z.-H., Isolation Forest, IEEE ICDM 2008
- Ng, A. (Stanford University), CS229 Lecture Notes: The k-means clustering algorithm
- NIST/SEMATECH, e-Handbook of Statistical Methods: EWMA Control Charts
- Departamento de Energía de Estados Unidos, Operations & Maintenance Best Practices Guide, Release 3.0
- Pacific Northwest National Laboratory, O&M Best Practices: Maintenance Approaches
- Predictive maintenance in Industry 4.0: a survey of planning models and machine learning techniques, revisión con revisión por pares
