Todo equipo que monitoriza sensores empieza igual: fija un límite y avisa cuando una lectura lo cruza. Temperatura por encima de 8 grados, vibración por encima de 4 mm/s, corriente por encima de 20 amperios. Para límites físicos duros, eso es exactamente lo correcto.
Pero los fallos que cuestan dinero de verdad casi nunca se anuncian con una lectura fuera de rango. Se esconden dentro de lecturas que, una a una, parecen normales. Un compresor se desvía dos grados a lo largo de tres semanas. Un caudalímetro se queda callado a las 2 de la mañana y nadie lo nota hasta el turno de mañana. Una anomalía no es “un número grande”. Es una lectura, o la ausencia de lecturas, que el patrón normal no habría predicho.
Las cuatro formas de anomalía en datos de sensores
En la práctica, las anomalías de sensor aparecen en cuatro formas, y solo la primera es visible para un límite fijo.
Los picos son la forma obvia. Un valor salta muy por fuera de su rango reciente y vuelve. Algunos picos son eventos reales, muchos son ruido eléctrico o un fallo momentáneo del sensor, y distinguirlos suele exigir mirar más de una lectura.
La deriva es más lenta y más cara. Un sensor, o el proceso que hay detrás, se aleja poco a poco de su línea base sin salirse de los límites de alerta en ningún momento. La pérdida de calibración, los filtros que se obstruyen y las fugas de refrigerante se presentan como deriva. Cuando un umbral fijo por fin salta, el problema tiene semanas.
El silencio es la anomalía que la mayoría de las monitorizaciones olvida. Un dispositivo que deja de reportar no produce ningún dato que evaluar, así que las reglas basadas en valores nunca saltan con él. Los datos que faltan también son datos.
Los fallos correlacionados atraviesan dispositivos. Un gateway se cuelga y treinta sensores se callan juntos, o todas las unidades de una misma fase eléctrica dan un pico en el mismo minuto. Ninguna regla por dispositivo ve esto, porque el patrón solo existe a escala de flota.
Detectar es además un trabajo distinto de predecir. Si lo que quieres es un aviso antes de que un valor cruce un límite, y no una señal después de que se comporte de forma extraña, eso es previsión, y la diferencia entre las dos decide cuál deberías construir.
Umbrales y estadística: cuándo bastan los métodos clásicos
No te saltes las herramientas clásicas, porque para buena parte de las anomalías son la respuesta correcta y no un apaño.
Un umbral estático es barato, transparente y exactamente correcto cuando el límite es físico o contractual. Una nevera de vacunas tiene que mantenerse por debajo de 8 grados, y nadie necesita machine learning para hacerlo cumplir. Las Actions de TagoIO lo resuelven directamente: defines la condición, defines la respuesta, listo.
Una línea base estadística cubre el siguiente nivel. Calcula media y desviación típica móviles por sensor, marca lecturas más allá de tres desviaciones típicas, y capturas picos y derivas que los límites fijos se pierden, porque la banda se mueve con los datos. Segmenta esa línea base por hora del día o modo de operación y la precisión mejora otra vez: una temperatura normal a las 2 de la mañana puede ser anómala a las 2 de la tarde. El silencio necesita otra regla, un tiempo límite: si un dispositivo no ha reportado en el doble de su intervalo habitual, eso es una anomalía al margen de los valores.
Es estadística sin glamour, y le gana a un modelo de IA ingenuo en la mayoría de los flujos de sensores porque codifica lo que de verdad sabes del proceso.
Donde los métodos clásicos se agotan es justo donde el trabajo se vuelve tedioso: elegir la ventana adecuada por variable, tratar la estacionalidad, comparar comportamiento entre cientos de dispositivos, correlacionar varias variables a la vez. Nada de eso es conceptualmente difícil. Todo eso son horas de código y decisiones de criterio por flota, y por eso la mayoría de los equipos se queda en los umbrales y convive con los puntos ciegos. Ese hueco es el que la IA llena de verdad.
Qué aporta la IA, con honestidad
“Detección de anomalías con IA” se vende como un modelo que sabe por arte de magia que algo va mal. El encuadre más útil: la IA quita el trabajo pesado entre saber cómo es un buen pipeline de detección y tener uno funcionando contra tu propia flota.
Los modelos de machine learning entrenados sí se ganan su sitio en la parte alta, para patrones multivariantes, estacionalidad fuerte y flotas demasiado grandes para ajustar sensor a sensor. Antes de ese punto, un asistente de IA que puede ver tus dispositivos y datos reales derrumba el coste de construir el propio pipeline clásico, y ahí es donde la mayoría de los equipos obtiene el retorno más rápido.
Explorar tu flota con TagoAI
TagoAI es el asistente de IA integrado en el Admin de TagoIO, detrás del icono de estrella. Está anclado en la documentación oficial y en tu propia cuenta: puede inspeccionar tus Devices, Dashboards, Actions y scripts de Analysis, y es sensible al contexto, así que abrirlo desde una página de Analysis o Dashboard significa que ya sabe qué está mirando.
Lo que importa para el trabajo con anomalías es que ejecuta operaciones de análisis de datos a lo largo de tus dispositivos. Puedes preguntar, en lenguaje corriente, qué sensores han reportado valores a más de tres desviaciones típicas de su propia media de dos semanas, qué dispositivos tienen huecos de más de una hora en el último día, o si las unidades detrás del gateway 7 se quedaron calladas al mismo tiempo. Eso es detección exploratoria de anomalías sin código, y así aprendes cómo es lo normal en tu flota antes de automatizar nada.
También se comporta como debe comportarse un asistente con acceso a la cuenta. Arranca en solo lectura, tú subes sus permisos por sesión, nunca cambia nada en silencio y todo lo que hace queda registrado en el Audit Log. El recorrido paso a paso cubre el cambio de modos y los hábitos que merece la pena crear, y las decisiones de proveedor y privacidad se exponen por separado.
Generar la lógica de detección como código de Analysis
La exploración encuentra anomalías una vez. La detección en producción tiene que ejecutarse cada pocos minutos, sin supervisión. En TagoIO, eso es una Analysis: un script que corre según un calendario, lee los datos recientes, aplica tu lógica de detección y escribe de vuelta una marca de anomalía como variable.
En lugar de escribir ese script desde una página en blanco, pide a TagoAI que lo genere. Como puede inspeccionar tus dispositivos y formatos de datos reales, el código que produce se dirige a tus nombres de variable, unidades e intervalos de reporte auténticos y no a un ejemplo genérico. Describe la lógica que fijaste durante la exploración: línea base móvil por sensor, tres desviaciones típicas, segmentada por hora, más una comprobación de silencio al doble del intervalo de reporte. Revisa el código, ajústalo y publícalo. Cuando un script dé problemas más adelante, TagoAI lo depura con el mismo contexto de cuenta.
El resultado es una lógica de detección que puedes leer, versionar y en la que puedes confiar, producida en minutos en lugar de días. La IA hizo el trabajo pesado; la lógica sigue siendo tuya y sigue siendo auditable. Recorrimos este flujo en directo, desde la descripción en lenguaje corriente hasta una Analysis funcionando, en el webinar AI Meets IoT: A Practical Experience with TagoAI.
Alertar con Actions
La detección y la alerta deberían estar separadas. La Analysis escribe una marca de anomalía; una Action de TagoIO vigila esa variable y se encarga de la respuesta, sea correo, SMS, notificación push o un webhook hacia tu sistema de tickets.
Mantenerlas separadas permite endurecer la lógica de detección sin tocar el enrutado de alertas, y permite llevar la misma variable de anomalía a equipos distintos según la severidad.
Investigar lo que se marca
Una línea base te dice que la Unidad 4 se salió a las 3:20. No te dice por qué, ni si forma parte de un patrón, ni qué hacer. Esa investigación, correlacionar el desvío con otras variables, comprobar si la misma unidad se portó mal la semana pasada y redactar el arreglo, es exactamente lo que un asistente de IA hace bien cuando alcanza tus datos reales.
Si tu asistente vive fuera de TagoIO, el TagoIO MCP server le da el mismo alcance: traer las lecturas de alrededor, revisar el historial del dispositivo y proponer una Action más estricta. La detección sigue siendo estadística y auditable mientras la IA se ocupa de la correlación tediosa y del primer borrador de la respuesta. El panorama más amplio está en qué significa MCP para IoT.
Un orden de construcción que sobrevive a producción
Empieza con Actions en tus límites duros de verdad, hoy, sin IA. Después usa TagoAI para explorar cómo se comporta realmente tu flota y encontrar qué variables derivan, dan picos o se callan. A continuación, pídele que genere la Analysis que codifica lo aprendido, y conecta una Action a la marca de anomalía. Añade comprobaciones a escala de flota para los fallos correlacionados cuando la detección por dispositivo esté estable. Recurre a modelos de machine learning entrenados solo cuando el pipeline estadístico se pierda de forma demostrable patrones que te importan.
La trampa a evitar es empezar por el final. Una IA investigando anomalías que aún no has aprendido a detectar de forma fiable es una conjetura segura sobre un cimiento inestable. Detección primero, explicación después.
La conclusión
Las anomalías en datos de sensores llegan como picos, deriva, silencio y fallos correlacionados, y tres de las cuatro son invisibles para los umbrales fijos. La estadística clásica las detecta bien, pero cuesta tiempo real de ingeniería por flota, y ese tiempo es el coste que la IA elimina: TagoAI para explorar el comportamiento entre dispositivos, código de Analysis generado para la detección en producción, Actions para alertar y un asistente para investigar lo que se marca.
Construye en ese orden y tendrás un sistema preciso, depurable y realmente útil, en lugar de una demo impresionante en la que nadie confía en producción. Consulta Analysis y Actions en la documentación, o empieza gratis en TagoIO y marca tu primera anomalía esta semana.
