El director de producción con el que negociamos el año pasado tenía una pregunta sencilla: «¿Cuántos meses tardará vuestro sistema de IA en salvar el primer motor de un fallo?» Nos esperaba una respuesta incómoda pero verdadera: depende de cuánto tiempo lleváis recogiendo datos. Si menos de seis meses — probablemente ni un año sea suficiente.
El mantenimiento predictivo (PdM) pertenece a las áreas donde la IA/ML aporta resultados verificables. Una reducción de paradas no planificadas del 30 – 50 % es un número que se repite en proyectos de distintos sectores industriales. Al mismo tiempo es un área donde el hype de marketing y los resultados reales en producción divergen más que en cualquier otra parte. El objetivo de este artículo es trazar dónde un modelo de ML ayuda de verdad, qué requisitos de datos hay que cumplir y cuándo tiene más sentido empezar con lógica basada en reglas.
Qué resuelve realmente el mantenimiento predictivo
El mantenimiento tradicional funciona en dos modos: reactivo (repara después del fallo) y preventivo (sustituye según calendario sin tener en cuenta el estado real). Ambos tienen debilidades evidentes — el reactivo genera paradas no planificadas, el preventivo lleva a sustituciones anticipadas de piezas que todavía tenían años de vida.
El mantenimiento predictivo añade un tercer modo: intervienes justo cuando el equipo empieza a degradarse, ni antes ni después. En la práctica eso significa:
- Recogida continua de datos de sensores (vibraciones, temperatura, emisión acústica, espectro de corriente)
- Detección de anomalías o estimación directa de la vida útil restante del equipo (RUL — Remaining Useful Life)
- Aviso a los operarios con un adelanto típico de 3 – 14 días antes del fallo previsto
Funciona bien en equipos con un proceso de degradación bien caracterizado — rodamientos, motores eléctricos, compresores, bombas, engranajes. Precisamente en estos tipos de equipos los espectros de frecuencia de vibración son un portador fiable de información sobre el desgaste.
Dónde aporta valor real un modelo de ML
Detección de anomalías sin etiquetas
El punto de entrada más universal es entrenar un modelo exclusivamente sobre estados normales del equipo. El modelo aprende la distribución de la señal «sana» y cualquier desviación — incluso una que nadie haya visto antes — dispara una alerta. Técnicamente se trata de autoencoders o métodos como Isolation Forest, o bien Vision Transformers entrenados sobre espectrogramas de vibración.
Ventaja: no necesitas registros históricos de fallos. Desventaja: mayor tasa de falsos positivos en los primeros meses de operación, hasta que los umbrales se calibran al equipo concreto.
Clasificación de averías y estimación de RUL
Cuando se dispone de suficiente histórico — y eso es lo clave — el modelo puede clasificar el tipo concreto de avería y estimar la vida útil restante. Aquí se alcanzan cifras de 88 – 97 % de precisión en la predicción con equipos bien instrumentados tras 6 – 12 meses de recogida de datos. Pero ese número proviene de datasets de benchmark, no necesariamente del primer año en producción de tu equipo concreto.
Fusión multimodal de señales
La combinación de vibraciones, temperatura, emisión acústica y espectro de corriente en un único modelo aporta una precisión significativamente mejor que los enfoques con un solo sensor. En la práctica eso implica más sensores y un pipeline de datos más robusto, pero para equipos críticos la inversión está justificada.
Datos sintéticos generativos para fallos infrecuentes
Uno de los mayores problemas del PdM: los fallos catastróficos son raros. El modelo no recibe suficientes ejemplos. El enfoque actual que ha demostrado eficacia es la generación de eventos de fallo sintéticos mediante GAN o modelos de difusión — así puedes ampliar artificialmente el conjunto de entrenamiento donde los datos reales sencillamente no existen.
Requisitos de datos — lo que el vendedor no te dirá
Antes de cualquier decisión sobre el despliegue de una solución de ML hay que responder estas preguntas:
- 1.¿Cuánto tiempo llevamos recogiendo datos de sensores? — Menos de seis meses significa un problema de cold start. El modelo no sabe qué es «anormal» porque no ha visto suficientes estados normales ni sus variaciones estacionales.
- 2.¿Tenemos registrados los eventos de fallo? — Las fechas y los tipos de averías deben estar en el sistema. Sin ellos no es posible entrenar un modelo de clasificación de fallos ni un modelo de RUL.
- 3.¿Están los datos sincronizados? — Los sensores, SCADA, ERP y los logs de mantenimiento deben tener timestamps consistentes. Una hora de desfase entre fuentes puede desestabilizar todo el modelo.
- 4.¿Cuál es la frecuencia de muestreo? — Los análisis de vibración requieren típicamente cientos de Hz. La temperatura basta con una vez por minuto. Una señal submuestreada no detecta el problema.
- 5.¿Están los datos limpios? — Sensores muertos, valores congelados, interrupciones de comunicación. La calidad del dato es en la práctica un problema mayor que la elección del modelo.
Hemos visto proyectos donde la empresa pagó por una plataforma de ML antes de tener en orden el pipeline de recogida de datos. El resultado: el modelo se entrenó sobre ruido y las primeras alarmas fueron falsos positivos. Eso disuade rápidamente a los clientes de confiar en el sistema — lo que es una situación peor que si el PdM no existiera.
Cuándo basta con una regla más sencilla
Un modelo de ML no es siempre la elección correcta. Existen escenarios donde un sistema basado en reglas o el control estadístico del proceso (SPC) ofrece el mismo o mejor resultado por una fracción del coste:
- Equipos con valores de umbral inequívocos — si un motor sube a 95 °C, eso es una alarma. Para eso no necesitas una red neuronal.
- Equipo nuevo sin histórico — el modelo no tiene nada con lo que entrenar, las reglas funcionan desde el primer día.
- Pocos equipos del mismo tipo — los modelos de ML no demuestran su valor con muestras pequeñas.
- Procesos regulados con auditabilidad — la regla «alarma al superar X» es fácil de explicar al regulador. Un modelo de caja negra mucho menos.
La vía razonable: empieza con reglas y SPC, recoge datos, y cuando tengas 12+ meses de histórico con suficientes eventos de fallo registrados — entonces merece la pena plantearse el ML.
La realidad del ROI: qué calcular y qué no
Los materiales de marketing citan reducciones de paradas no planificadas del 30 – 50 %. Esas cifras son realistas — pero alcanzarlas lleva tiempo. El cálculo real del ROI debe contabilizar:
En el lado de los beneficios: - Reducción del coste de la parada no planificada (tarifa horaria de la línea × duración media de la parada × frecuencia) - Extensión de la vida útil de los componentes — menos sustituciones anticipadas - Reducción del stock de seguridad de repuestos
En el lado de los costes: - Infraestructura de sensores (el retrofitting de equipos antiguos es caro) - Pipeline de datos e integración con SCADA/ERP - Licencias o desarrollo interno de la plataforma de ML - Tiempo de calibración del modelo — los primeros 3 meses con falsos positivos son improductivos - Gestión continua del modelo (drift, nuevos equipos, actualizaciones de firmware)
Con decenas de despliegues vemos que el break-even llega típicamente en el año 2 – 3, no en el año 1 — cuando se parte de cero. Si tienes un sistema OPC-UA o SCADA existente con datos históricos limpios, puedes ser más rápido.
Relacionado con esto está también la cuestión del presupuesto de hardware — más en el artículo Copilot de IA para operarios, donde analizamos la economía de los dispositivos AI en el edge.
Integración con los sistemas existentes
El mantenimiento predictivo no es un módulo aislado — debe conectarse con tus sistemas existentes:
- CMMS/EAM (Computerized Maintenance Management System) — una alerta de PdM debe generar automáticamente una orden de trabajo, no solo un mensaje en el dashboard. Si el operario tiene que transcribir manualmente la alarma al CMMS, el sistema deja de usarse muy rápido.
- SCADA / OPC-UA — protocolos estándar para datos industriales; la mayoría de las plataformas modernas de PdM los soportan de forma nativa.
- ERP — la conexión con los pedidos de repuestos es crítica para cerrar el bucle.
Una arquitectura donde el PdM se erige como silo con su propio dashboard sin conexión con los procesos operativos es una de las causas más frecuentes por las que los proyectos no aportan el ROI esperado. Sobre la integración de sistemas BMS con la capa SCADA habla con más detalle el artículo sobre BMS, KNX y Loxone.
Gemelo digital y enfoques multi-agente
En la generación actual de soluciones PdM aparece una nueva arquitectura: el gemelo digital del equipo combinado con agentes de IA. En lugar de un único modelo clasificador tienes una red de agentes — uno recoge y limpia datos, otro clasifica el tipo de degradación, un tercero simula la vida útil restante sobre un modelo físico del equipo, un cuarto genera la recomendación para el personal técnico.
Este enfoque es más potente que un modelo de ML monofunción, pero también más costoso de implementar y operar. Merece la pena donde el equipo es suficientemente valioso (centro CNC, turbina, estación de compresores) y donde una predicción errónea significa costes realmente elevados. Para bombas corrientes en un circuito secundario resulta sobredimensionado.
Sobre las arquitecturas de sistemas multi-agente escribimos con más detalle en IA en la práctica: sistemas multi-agente.
Mantenimiento predictivo vs. inspección visual por IA — dónde está el límite
El mantenimiento predictivo y la inspección visual son dos dominios distintos, aunque ambos pertenecen al «IA en la industria». El PdM trabaja con series temporales de datos de sensores y responde a la pregunta cuándo fallará el equipo. La inspección visual trabaja con imagen y responde a la pregunta si una pieza concreta tiene o no un defecto. Más sobre inspección visual en Control de calidad visual con IA.
Lo interesante es que estos dominios empiezan a solaparse — los espectrogramas de vibración se procesan con modelos visuales (CNN), los sistemas de cámara monitorizan simultáneamente perfiles de temperatura. La fusión multimodal es la dirección hacia la que avanza todo el campo.
Preguntas frecuentes
¿Cuánto tarda un sistema PdM en funcionar de forma fiable?
En la práctica cuenta con 6 – 12 meses desde el inicio de la recogida de datos hasta las primeras predicciones fiables. Los primeros 3 meses se caracterizan por una mayor tasa de falsos positivos (alrededor del 10 – 15 %), hasta que el modelo se calibra al equipo concreto y sus ciclos de operación. Este tiempo puede acortarse si dispones de datos históricos archivados del sistema SCADA — pero deben estar limpios y sincronizados con los logs de mantenimiento.
¿Basta con instalar sensores IoT industriales comunes para el PdM?
Los sensores son solo el primer paso. Igual de importante es garantizar una sincronización temporal consistente, una transmisión de datos fiable sin interrupciones y su almacenamiento correcto con una retención de al menos 2 años. La mayoría de los fallos en proyectos PdM no tiene que ver con la elección del modelo, sino con un pipeline de datos de mala calidad — sensores muertos, valores congelados, desfases temporales entre fuentes.
¿Cuándo tiene sentido usar ML en lugar de reglas?
Un modelo de ML merece la pena cuando tienes al menos 12 meses de datos de sensores limpios con suficientes eventos de fallo registrados, equipos del mismo tipo en número suficiente y un proceso de degradación que no se puede capturar trivialmente con un umbral simple. Para equipos con un valor límite inequívoco (temperatura, presión, corriente) las reglas son más sencillas, auditables e igualmente eficaces.
¿Cuál es la precisión de predicción real?
En condiciones ideales — equipo bien instrumentado, 6 – 12 meses de datos, tipos de fallo recurrentes — se citan valores de 88 – 97 % de precisión. Esas cifras provienen principalmente de datasets de benchmark y estudios controlados. En el primer año de producción real con equipos nuevos cuenta con menor precisión hasta que el modelo absorba las variaciones estacionales y los distintos modos de operación.
¿Tengo que cambiar todo el sistema CMMS para poder desplegar PdM?
No. La mayoría de las plataformas modernas de PdM saben integrarse via API o conectores estándar con los sistemas CMMS y ERP existentes. Lo clave es que la alerta de PdM genere automáticamente una orden de trabajo — la transcripción manual no es sostenible a largo plazo. Si tu CMMS no tiene API, habitualmente existen soluciones middleware que salvan ese puente sin necesidad de sustituir el sistema.
*Si estás decidiendo si y cómo desplegar el mantenimiento predictivo en tu planta, con mucho gusto evaluamos el estado de tu infraestructura de sensores y de tus datos — y te decimos directamente si tiene sentido empezar con ML o si el paso más sensato es otro. Contáctanos para una consulta sin compromiso.*