Mantenimiento predictivo con IA: de la alerta a la orden de trabajo

Una alerta necesita un camino hasta mantenimiento

El mantenimiento predictivo utiliza datos del equipo para anticipar condiciones que podrían requerir una intervención. Su valor empresarial depende de que la señal llegue a una persona capaz de actuar, con antecedentes y tiempo suficiente. Para una empresa chilena que evalúa incorporar IA, proponemos empezar por ese recorrido completo: detección, revisión, decisión, orden de trabajo y cierre.

El 4 de agosto de 2026, Codelco informó que El Teniente desarrolla una Unidad de Inteligencia Operacional organizada en Aplicaciones y Analítica Avanzada y Datos. Esta última desarrolla modelos predictivos para activos críticos; Aplicaciones lleva las capacidades a herramientas de trabajo con controles y registro de actividades. El anuncio no entrega tasas de acierto ni ahorros medidos. Sirve como contexto de integración operacional, sin demostrar resultados transferibles a otra planta. Codelco, desarrollo en El Teniente.

Definir qué intervención podría cambiar el resultado

Nuestra recomendación es escoger una familia de equipos y un problema de mantenimiento delimitado. La ficha inicial debería identificar el activo, el evento que se busca anticipar, quién revisará la señal y qué acción podría tomar. Conviene incorporar al planificador y al técnico que conoce el equipo antes de seleccionar un modelo.

La ventana útil debe acordarse con esos responsables: depende del tiempo para inspeccionar, conseguir repuestos y coordinar una intervención. Una señal que aparece después de agotar esa ventana puede resultar interesante para investigar, pero no cumple el objetivo preventivo del piloto. Proponemos dejar ese criterio escrito para evitar que una demostración termine evaluándose solo por gráficos convincentes.

Distinguir una anomalía de una falla pronosticada

La documentación de AWS para mantenimiento predictivo distingue detección de anomalías cuando faltan fallas etiquetadas y clasificación supervisada cuando existe historial de eventos identificados. Su arquitectura también contempla seguir alertas hasta su resolución e integrarlas con la programación del mantenimiento. Es una referencia de proveedor para flotas; no acredita el desempeño de un equipo industrial chileno. AWS, Predictive Maintenance.

Para comprar o encargar una solución, sugerimos exigir que la salida explique qué representa: una desviación respecto del comportamiento habitual, una probabilidad de un evento definido o una estimación de tiempo restante. Cada afirmación requiere evidencia diferente. Si el piloto únicamente identifica desviaciones, su interfaz y sus informes deberían conservar ese alcance.

Una bomba y dos decisiones posibles

Imaginemos una bomba de una instalación industrial. Es un ejemplo hipotético, sin relación con un cliente ni con los equipos de El Teniente. El sistema marca una variación de vibración durante un cambio de carga. Proponemos que la alerta reúna identificación del activo, hora, señal observada, contexto de operación y antecedentes disponibles, para que el responsable pueda revisar el episodio.

La revisión podría encontrar una lectura defectuosa que requiere verificar el sensor, o evidencia que justifique una inspección del equipo. En ambos casos debe quedar registrada la decisión. La orden de trabajo tendría responsable, prioridad, evidencia adjunta y estado de cierre. Durante el piloto, esa decisión corresponde al personal autorizado; el modelo no modifica protecciones ni procedimientos de seguridad.

Medir las alertas que el equipo puede atender

La guía de IA industrial de NIST advierte que evaluar únicamente la exactitud puede ocultar un mal resultado operacional. Las falsas alarmas pueden generar inspecciones y detenciones innecesarias; incluso una detección correcta puede perder utilidad si no se conecta con la programación del mantenimiento. NIST MEP, consideraciones para implementar IA industrial.

Como pauta editorial, proponemos revisar alertas únicas por equipo y turno, tiempo hasta su revisión, proporción con evidencia suficiente y anticipación útil para intervenir. Agrupar avisos repetidos del mismo episodio ayuda a describir la carga de trabajo. También corresponde revisar fallas confirmadas sin aviso previo: atender bien las alertas recibidas no demuestra que se detecten todos los problemas.

El cierre necesita interpretación técnica. Si se intervino preventivamente y luego no ocurrió una falla, esa ausencia no basta para clasificar la alerta como falsa. Recomendamos distinguir hallazgo confirmado, aviso descartado y resultado incierto, conservando la evidencia de inspección. Esa separación evita presentar como éxito o error lo que todavía no puede comprobarse.

Una prueba que produzca una decisión de inversión

Proponemos iniciar la prueba con lectura de datos y revisión humana, manteniendo los controles existentes. La comparación debería usar el procedimiento actual como referencia y registrar tanto trabajo adicional como decisiones que cambiaron gracias a la alerta. El periodo de observación tiene que representar la operación que se pretende cubrir; unos días sin fallas no permiten prometer confiabilidad futura.

Para avanzar, mantenimiento y tecnología deberían acordar si la evidencia justifica ampliar equipos, ajustar la detección o detener la prueba. El presupuesto debe incluir sensores, integración, revisión y soporte. Nuestra guía para medir el costo de la IA por tarea resuelta ayuda a incorporar ese trabajo humano al análisis económico.

El próximo paso para una empresa en Chile

Una reunión útil puede terminar con un activo elegido, un evento definido, una muestra de datos y un responsable de mantenimiento. A partir de eso se puede evaluar la integración con el sistema de órdenes existente y el alcance de una automatización con IA. La decisión de inversión tendrá una base más clara cuando el piloto permita reconstruir qué señal apareció, quién la evaluó y qué acción produjo.