IA y visión
Detección de anomalías y predicción sobre datos operativos
Las señales que se apartan de lo habitual llegan priorizadas a quien debe revisarlas, junto con las variables que explican la desviación.
Las señales de una operación, como consumos, temperaturas, tiempos de ciclo, llamadas de soporte o ventas diarias, tienen un comportamiento habitual. Detectar cuándo se apartan de él, o estimar cómo evolucionarán, puede adelantar un problema o ayudar a planificar. Pero un modelo no encuentra nada útil si el histórico tiene huecos, si nadie ha registrado qué pasó realmente en cada incidencia o si se confunde una parada programada con una avería. El trabajo empieza por entender los datos y acordar qué se considera anómalo, y continúa con modelos sencillos antes que complejos. Cada alerta debe poder explicarse y cada predicción ir acompañada de su margen de error medido sobre periodos que el modelo no vio.
- Entrada de datos
- Series del historiador
- Calendario de paradas y cambios
- Validación
- Huecos y cambios de sensor
- Separación temporal de periodos
- Procesamiento
- Modelo de comportamiento normal
- Puntuación de desviación
- Control humano
- Técnico decide si inspecciona
- Valoración útil, falso o conocido
- Trazas
- Versión del modelo y umbral
- Error medido por periodo
- Sistemas de salida
- Aviso en el CMMS
- Previsión con su intervalo
Antes y después
Qué cambiaría en la operación
Ejemplo hipotético: una depuradora que mueve agua entre balsas con varias bombas cuyos consumos eléctricos ya se registran en el sistema de supervisión.
01 · Antes
Mantenimiento mira las curvas de consumo solo cuando una bomba ya se ha parado, y nadie distingue a simple vista un arranque normal de un esfuerzo anómalo.
02 · Sistema propuesto
Un modelo aprende el consumo habitual de cada bomba según caudal y régimen, descuenta los arranques programados y genera un aviso cuando la desviación supera el umbral acordado.
03 · Después
Mantenimiento ve qué bombas se apartan de su comportamiento con el gráfico del periodo, decide si inspecciona y registra si cada aviso fue útil o falso.
Alcance
Qué resuelve y qué no
Qué puede resolver
- Señalar lecturas o combinaciones de variables que se apartan del comportamiento habitual de un equipo, una línea o un servicio.
- Agrupar incidencias similares y detectar repuntes que no se ven revisando los tickets uno a uno.
- Estimar demanda, consumo o carga de trabajo para las próximas semanas, con un intervalo de incertidumbre explícito.
- Priorizar qué revisar primero cuando hay muchas señales y poco tiempo, ordenando por grado de desviación.
Qué no resuelve
- No equivale a un programa de mantenimiento predictivo acreditado: una alerta de anomalía no certifica el estado de un equipo ni sustituye las inspecciones obligatorias.
- No predice sucesos sin precedentes en los datos: si un fallo nunca se ha registrado, el modelo no puede aprenderlo.
- No ofrece una precisión fija de antemano; solo puede medirse después, con datos reales y periodos de prueba separados.
- No interviene en funciones de seguridad ni en el control de máquinas.
Escenarios operativos
Cómo funcionaría en la práctica
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Comportamiento inusual de un equipo
- Entrada
- Series de vibración, temperatura, corriente o presión de un equipo, junto con su calendario de producción y paradas.
- Procesamiento
- Se modela el comportamiento normal por régimen de trabajo, descontando arranques y paradas programadas, y se calcula una puntuación de desviación con umbrales ajustados junto a mantenimiento.
- Salida
- Aviso en el sistema de mantenimiento con las variables que más contribuyen a la desviación y el gráfico del periodo, para que un técnico decida si inspecciona.
02
Repunte de incidencias en un servicio
- Entrada
- Tickets de soporte o partes de incidencia con fecha, categoría, ubicación y texto libre descriptivo.
- Procesamiento
- Se agrupan las incidencias por similitud de contenido y ubicación, y se compara su frecuencia con la esperada para ese día y franja horaria.
- Salida
- Alerta temprana de posible incidencia común, con los tickets agrupados enlazados para que el equipo confirme o descarte.
03
Previsión de demanda semanal
- Entrada
- Histórico de ventas o pedidos por referencia y punto, calendario de festivos, promociones y roturas de stock registradas.
- Procesamiento
- Se comparan métodos estadísticos clásicos y modelos de aprendizaje automático con validación por periodos sucesivos, y se elige el que mejor funciona en cada familia de productos.
- Salida
- Previsión por referencia con su intervalo, disponible para compras o planificación, y un informe de error comparado con la previsión anterior.
04
Estudio previo de datos
- Entrada
- Exportaciones del historiador, del MES, del ERP o del gestor de incidencias y el registro de fallos conocidos.
- Procesamiento
- Análisis de cobertura, huecos, cambios de sensor y coherencia entre fuentes, y prueba de un modelo base sobre un periodo reservado.
- Salida
- Informe sobre si los datos permiten el objetivo planteado, qué falta registrar y qué rendimiento cabe esperar antes de invertir más.
Integración
Cómo se conecta con lo que ya existe
Los modelos se alimentan de las mismas fuentes que ya registran la operación: historiadores de planta, MES, ERP, gestores de incidencias o almacenes de datos. Se define con qué frecuencia se recalculan, dónde se publican las alertas y previsiones y cómo se recoge la respuesta de quien las revisa, porque esa retroalimentación es la que permite mejorar umbrales y modelos con el tiempo.
- Extracción periódica o en continuo desde historiador, MES, ERP o gestor de tickets
- Almacén de características y de resultados con versión del modelo que los generó
- Publicación de avisos en el CMMS, en la herramienta de soporte o por notificación
- Registro de la valoración humana de cada aviso: útil, falso o ya conocido
- Panel de seguimiento del error de previsión y de la tasa de falsas alarmas
Modalidades de despliegue que suelen plantearse
Se elige en cada proyecto tras evaluar requisitos y sistemas existentes.
Antes de desarrollar
Datos, validaciones y permisos
- Histórico suficientemente largo y continuo para cubrir estacionalidades y regímenes de funcionamiento relevantes.
- Registro fiable de qué ocurrió: averías, intervenciones, promociones, cambios de proceso o de sensor.
- Definición acordada de qué es una anomalía relevante y cuánto cuesta una falsa alarma frente a un aviso perdido.
- Personas que revisen las alertas en un plazo razonable y registren su valoración.
- Acceso estable a las fuentes de datos y responsables de su calidad.
Supervisión
Riesgos, límites y mantenimiento
- Demasiadas falsas alarmas hacen que se ignoren todas; los umbrales se ajustan con quien recibe los avisos y se revisan periódicamente.
- Los modelos se degradan cuando cambian los equipos, los procesos o los hábitos de compra; hay que vigilar su error y prever reentrenamientos.
- Un buen resultado en el histórico puede no repetirse en producción si la validación no respetó el orden temporal de los datos.
- Presentar una previsión sin su incertidumbre invita a decisiones con más confianza de la justificada.
Sectores, servicios y lecturas relacionadas
Sectores donde se aplicaría
Cómo se contrata
Para profundizar
Preguntas frecuentes
¿Cuánto histórico hace falta para detectar anomalías?
Depende de la variabilidad de la señal y de los ciclos que tenga. Una señal con estacionalidad anual necesita, como mínimo, cubrir varios de esos ciclos. Lo prudente es hacer primero un estudio de los datos disponibles y decidir con él si el objetivo es viable.
¿Es mejor un modelo de aprendizaje automático o uno estadístico?
No hay una respuesta general. Los métodos estadísticos suelen ser más fáciles de explicar y funcionan bien con pocos datos; los de aprendizaje automático aportan cuando hay muchas variables y relaciones complejas. Se comparan sobre los mismos periodos de prueba y se elige el que mejor rinde y mejor se entiende.
¿Una alerta de anomalía significa que el equipo va a fallar?
No necesariamente. Indica que el comportamiento es distinto del habitual, lo que puede deberse a un desgaste, a un cambio de producto, a un sensor defectuoso o a una operación poco frecuente. La decisión sobre si intervenir corresponde a mantenimiento tras revisar el aviso.
Cuéntanos qué datos registras y qué te gustaría anticipar
Cuéntanos qué datos y sistemas intervienen en tu proceso. Estudiaremos qué puede automatizarse, cómo se integraría y qué convendría validar antes de desarrollar. Ver todas las capacidades.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.