Hay un número que te ponen enfrente en cada feria este año. Millones de componentes analizados. Miles de plantas. Décadas de historial de fallas. El mensaje implícito es siempre el mismo: nuestra inteligencia artificial sabe más que las demás, porque la alimentaron con más datos.

Es un número impresionante. También es el número equivocado para comparar — y no lo digo por mercadotecnia, sino por cómo funcionan en realidad estos sistemas.

Respuesta corta. El conocimiento general del análisis de vibraciones —frecuencias de falla, normas, patrones de falla, las cuatro etapas de un defecto de rodamiento— está publicado, y cualquier modelo de lenguaje competente ya lo tiene incorporado. Ningún proveedor es dueño de ese conocimiento ni puede vendértelo. Lo que decide si un diagnóstico es correcto es cuánto sabe el sistema de tu máquina —su ficha técnica, sus rodamientos, su velocidad real de giro, sus modos de operación, su tendencia, su espectro, su forma de onda, las notas del analista— y que lo tenga todo enfrente al mismo tiempo, algo que ninguna persona puede hacer: nosotros leemos una pantalla a la vez. Y después, si se le permite ir a comprobar aquello de lo que no está seguro. Pídele a cualquier proveedor que te muestre las dos cosas. El tamaño de un corpus de entrenamiento es lo más fácil de afirmar para él y lo más difícil de verificar para ti.

Por qué un conjunto de entrenamiento más grande no da un mejor diagnóstico

Piensa en lo que ese número te está vendiendo en realidad: conocimiento general de vibraciones. Cómo se ve un defecto de rodamiento en un espectro de envolvente. Por qué la desalineación aparece axialmente en 2X. Cómo las bandas laterales alrededor de la frecuencia de engrane revelan un engrane excéntrico. Qué dice la ISO 20816 de una máquina de 200 kW sobre una cimentación rígida.

Nada de eso escasea ya. Está en los libros de texto, en las normas, en las ponencias de congresos y en cuarenta años de casos de estudio publicados, y cualquier modelo de lenguaje serio ya lo leyó completo. No tienes que comprárselo a nadie.

Lo que es escaso es algo que ninguna base de datos de fallas ajenas puede contener: tu máquina.

Diagrama que contrasta la pregunta general, que el conocimiento publicado ya responde, con la pregunta particular sobre una bomba concreta, que solo puede responder la base de datos de la propia planta; abajo, las herramientas con las que el asistente puede ir a comprobar
La pregunta de la izquierda la responde cualquier modelo capaz. La de la derecha la responden tus datos, y lo que al asistente se le permite hacer con ellos.

Lo que toda IA ya sabe, y lo que le es imposible saber

Pídele hoy a cualquier modelo competente que te explique cómo distinguir un desequilibrio estático de una desalineación paralela. Te dará una respuesta correcta y bien ordenada.

Ahora pregúntale cuál de los dos tiene tu ventilador. No tiene con qué trabajar — a menos que tú le des algo.

Ahí está la clave. Dentro de lo que parece una sola pregunta se esconden dos muy distintas:

La pregunta general

¿Cómo se ve un defecto en la pista externa?

La física, las normas, las frecuencias de falla, la progresión típica por las cuatro etapas, la razón por la que la envolvente lo detecta antes que la velocidad.

Ese conocimiento es público, estable y universal. Es el mismo en Monterrey y en Hamburgo, en una bomba de 1998 y en una de 2026. Nadie tiene una versión propietaria de él, y un modelo que leyó la literatura ya lo tiene incorporado.

La pregunta particular

¿Esta bomba lo tiene, hoy?

Los números de parte de sus rodamientos, su velocidad real de giro, los tres modos de operación que de verdad tiene, qué hizo su tendencia en los últimos once meses, cómo se compara el eje H con el eje A, qué escribió el analista en marzo.

Ese conocimiento existe en exactamente un lugar: tu planta. No está en el corpus de entrenamiento de ningún proveedor, no puede estarlo, y el tamaño de ese corpus no lo cambia.

Un sistema que responde de maravilla la pregunta general y no llega a la particular produce algo muy reconocible: una respuesta que pudo haberse escrito sobre cualquier máquina de ese tipo. Es el libro de texto el que habla. Los analistas con experiencia lo detectan en un párrafo, y poco después dejan de confiar en la herramienta.

El contexto es el noventa por ciento de la respuesta

Por eso las herramientas importan tanto. No son un segundo ingrediente junto al contexto — son la manera en que el sistema sale a buscar más contexto cuando el que recibió no alcanza.

Un analista humano no diagnostica mirando una sola pantalla. Hace zoom en la zona alrededor de 1X para ver si de verdad hay bandas laterales ahí. Cambia esa misma medición a envolvente. Abre la forma de onda para revisar si los impactos son periódicos. Compara el eje horizontal con el vertical. Abre la captura de hace tres meses y la pone junto a la de hoy. Revisa que el sensor esté sano antes de creer nada de lo que dice.

Nada de eso es conocimiento. Es procedimiento — y un asistente que no puede hacerlo queda reducido a comentar la captura de pantalla que le entregaron.

En EI-Analytic™ el asistente se llama Erby, y dispone de esos mismos pasos en forma de herramientas. Puede:

  • pedir la tendencia de cualquier periodo
  • leer las bandas de octava
  • abrir una captura específica
  • hacer zoom en un rango de frecuencia
  • comparar ejes, y comparar momentos en el tiempo
  • consultar la ficha técnica del activo
  • revisar la salud del sensor
  • consultar la vista general de la planta

Cuando no está seguro, va a comprobarlo, exactamente como lo haría una persona — y cada paso que da queda visible para ti dentro de la respuesta.

Las capturas de abajo corresponden a una consulta real sobre una bomba real. Nada está preparado de antemano: a Erby se le pidió un diagnóstico, y esto es lo que hizo antes de darlo.

Una consulta en curso: el asistente ha invocado las herramientas Comparar momentos y Fase entre ejes, afirma que la energía subió entre 630 y 700 Hz y entre 1.1 y 1.3 kHz y no en 1X ni en 2X, y traza la tendencia del punto del motor del lado del acoplamiento, con cada medición coloreada según su modo de operación
Cada etiqueta corresponde a una herramienta que el asistente decidió invocar, junto con el costo de esa consulta. La conclusión nombra frecuencias, no adjetivos — y la tendencia de abajo va coloreada por modo de operación, con los límites aprendidos trazados.

Fíjate de qué está hecha la conclusión. No vibración alta en el motor, sino esto: la energía subió entre 630 y 700 Hz y entre 1.1 y 1.3 kHz, y no en 1X ni en 2X. Es decir, un defecto de rodamiento que excita una resonancia — no un desequilibrio ni una desalineación.

Esa afirmación se puede refutar. Ve al espectro y revisa los números. Que es exactamente lo que hace a continuación, sin que nadie se lo pida.

Los espectros de antes y después del mismo punto superpuestos, agosto en azul y septiembre en verde, con los dos picos que aparecieron marcados en 670 Hz y 1283 Hz
La prueba que él mismo se traza: el mismo punto de medición con seis semanas de diferencia, con los dos picos nuevos marcados.

Así que la comparación que importa no es quién tiene el conjunto de entrenamiento más grande. Es a cuánta de la situación real tiene acceso el sistema, y cuántos de los pasos de un analista puede dar de verdad.

En resumen

  • La física general del análisis de vibraciones es conocimiento publicado; cualquier modelo moderno ya lo tiene, y ningún proveedor vende acceso exclusivo a él.
  • Lo que decide si una respuesta es correcta es el contexto específico de la máquina — ficha técnica, rodamientos, modos de operación, tendencia, espectro, forma de onda, notas, casos abiertos.
  • Casi igual de decisivo: si el asistente puede usar las herramientas del propio analista para ir a comprobar, en vez de comentar una sola captura de pantalla.
  • Un historial de fallas ajenas es realmente útil como punto de partida, y realmente incapaz de decirte qué está haciendo tu máquina hoy.
  • El diagnóstico sigue teniendo que ser auditable y confirmable por una persona. El contexto mejora una respuesta; no la convierte en palabra definitiva.
  • La memoria que vale la pena no es la que el modelo trae de fábrica. Es la que construye a partir del analista — sus criterios, sus excepciones, su forma de trabajar.

Dónde sí ayuda de verdad una base de datos de fallas

Sería deshonesto dejar esto fuera, así que seamos precisos.

Un gran acervo de fallas históricas de muchas plantas sí es valioso, para un conjunto específico y limitado de tareas:

  • límites de alarma iniciales razonables por tipo de componente
  • marcos de criticidad
  • modos de falla típicos a considerar para una clase de activo
  • cuánto suele tardar en progresar un defecto determinado

Eso es valor de ingeniería real, y es el núcleo honesto de lo que venden esas cifras de millones de componentes. Cuando pones en marcha una máquina nueva que no tiene historial propio, la estadística de máquinas parecidas es la mejor primera aproximación disponible — y quien te diga lo contrario también te está vendiendo algo.

Lo que esa base de datos no puede hacer es hablarte de tu máquina en vez de hablarte de máquinas como la tuya. Dos bombas idénticas —mismo modelo, mismo año, mismo servicio— montadas a cuarenta metros una de otra tendrán líneas base distintas: distinta rigidez de la cimentación, distintos esfuerzos de la tubería, distintas resonancias. La población te dice qué esperar. Nunca te dice qué está pasando.

Y hay otro problema, más discreto. Cuando un historial de fallas es propietario, el razonamiento que sale de él también es propietario. Te dicen que componentes parecidos fallaron así, y no puedes inspeccionar esa afirmación. Es el argumento de la caja negra entrando por una puerta nueva — y ya hemos escrito antes sobre por qué no lo aceptamos.

Cómo construye EI-Analytic™ la respuesta: tres capas

Vale la pena dejar claro qué hace cada capa — porque en nuestro software la inteligencia artificial no es la que emite el diagnóstico.

El motor de reglas nombra la falla. Trece tipos de falla, cada uno un conjunto de condiciones con su aritmética a la vista: qué amplitud, comparada con cuál, con qué factor, cumplida o no. Funciona desde la primera medición, sin historial y sin entrenamiento. Y puedes editar cada regla cuando se equivoque con tu ventilador de veinte años. Esto es lo que produce el diagnóstico que ves en el panel.

El panel de autodiagnóstico: fallas candidatas ordenadas con su conteo de reglas, la aritmética de la regla seleccionada y el espectro abajo con los picos que esa regla midió marcados
El diagnóstico es un conjunto ordenado de hipótesis, cada una con la aritmética que la sostiene.

El aprendizaje automático aprende tu máquina — no la de otro. El clustering agrupa las mediciones de cada punto en los modos de operación que esa máquina realmente tiene, sin que nadie etiquete nada, y avisa cuando aparece un modo que nunca se había visto. Los límites de alarma se aprenden de un periodo sano que tú seleccionas, en ese punto específico. Ambos se entrenan con tus datos, sobre tu equipo — el único entrenamiento que se traslada a tus decisiones.

Erby lee el panorama completo y lo explica. Antes de responder, el software arma un paquete de contexto y te lo muestra primero: qué capas entran, qué tan grande es cada una, y una opción para anonimizar los nombres de empresa y área antes de que se envíe nada. Luego trabaja con las herramientas de arriba y devuelve un reporte con su evidencia adjunta —amplitudes por eje, frecuencias, relaciones respecto a 1X, frecuencias de falla de rodamiento obtenidas de la envolvente— de modo que cada afirmación se pueda rastrear hasta un número medido.

Y la última regla es la que no cambiaríamos por más precisión que nos ofrecieran: el asistente no actúa por su cuenta. Puede preparar un caso, una nota, una ruta o un reporte, pero la ventana se abre ya rellenada y una persona es quien presiona guardar. Tus datos se quedan en tu plataforma. Cada respuesta muestra lo que costó.

La memoria que importa no es la del modelo. Es la tuya.

Un modelo de lenguaje llega con una memoria genérica: todo el mundo y todas las cosas, promediados. Es un buen punto de partida y un mal punto de llegada. Así que dejamos ir buena parte de esa memoria y la reemplazamos por algo que vale muchísimo más: la memoria que el sistema construye a partir del analista que lo usa.

Cómo te gusta configurar las alarmas. Qué máquinas ya decidiste ignorar, y la razón que diste. Que el compresor del área 4 siempre parece alarmante en el arranque y nunca lo está. La forma en que redactas un caso antes de entregarlo a producción. El punto en el que dejas de observar y tomas el teléfono.

Erby guarda todo eso, de forma visible y reversible, y lo trae a la siguiente pregunta. No está aprendiendo vibraciones de ti. Ya sabe vibraciones. Te está aprendiendo a ti.

Qué preguntarle a cualquier proveedor sobre su IA

Si este año estás evaluando plataformas, el tamaño de un corpus de entrenamiento es lo más fácil de afirmar para un proveedor y lo más difícil de verificar para ti. Estas seis preguntas son más difíciles de esquivar:

Pregunta esto Cómo se ve una buena respuesta
¿Qué ve exactamente la IA sobre mi máquina antes de responder? Una lista que puedas inspeccionar, e idealmente una pantalla que te la muestre antes de enviar
¿Puede ir a comprobar algo de lo que no está segura? Herramientas con nombre que pueda usar sobre tus datos —tendencias, capturas, zoom, ejes— no una sola foto fija
¿De dónde sale el diagnóstico en sí? Reglas o modelos que puedas abrir, leer y modificar
¿Qué pasa con mis datos? Se quedan en tu base de datos; anonimización disponible; nada se envía sin que lo veas
¿Puede actuar sin mí? No debería. Preparado para ti, confirmado por ti
Si la respuesta está mal, ¿con qué puedo rebatirla? Los números que usó, por eje y por frecuencia, no un porcentaje de confianza a secas

La pregunta que de verdad separa una IA de vibraciones de otra

La industria está a punto de pasarse un año discutiendo quién tiene el corpus más grande. Es una discusión cómoda para los proveedores, porque se puede afirmar sin que nadie pueda comprobarlo.

La pregunta útil es más simple, y mucho más difícil de falsear. Una IA de vibraciones vale exactamente lo que sabe de la máquina que tiene enfrente, y lo que se le permite hacer para averiguar más. El conocimiento general ya viene gratis con el modelo. El historial de tu máquina, sus modos, su línea base y sus casos abiertos no — y son toda la diferencia entre una respuesta sobre bombas y una respuesta sobre esta bomba.

La nuestra la construimos sobre esa premisa. Deberías hacer que cada proveedor, nosotros incluidos, te muestre exactamente qué está viendo su IA.

Mira lo que Erby está viendo

Preguntas frecuentes sobre la IA en el análisis de vibraciones

¿Un conjunto de entrenamiento más grande hace más preciso el diagnóstico de vibraciones?

No más allá de cierto punto. El conocimiento general que supuestamente aporta un corpus grande —frecuencias de falla, normas, patrones de falla, límites ISO— ya está publicado, y cualquier modelo de lenguaje competente lo ha leído. Ejemplos adicionales de fallas de otras plantas no le dicen nada al sistema sobre la velocidad, el montaje, los modos de operación ni el historial de la máquina que de verdad estás mirando. Esa información existe únicamente en tu propia base de datos.

¿Qué necesita saber una IA para diagnosticar una máquina específica?

Su ficha técnica y los números de parte de sus rodamientos, su velocidad real de giro, los modos de operación que realmente tiene, su tendencia a lo largo del tiempo, el espectro y la forma de onda de la medición en cuestión, cómo se compara un eje con otro, y qué han escrito los analistas sobre ella antes. En EI-Analytic™ ese paquete de contexto se arma desde tu propia base de datos y se te muestra antes de que se envíe nada, con la opción de anonimizar primero los nombres de empresa y área.

¿Puede un asistente de IA comprobar algo de lo que no está seguro?

Puede, si se le han dado herramientas para hacerlo. Un asistente que solo ve una captura de pantalla no puede hacer otra cosa que comentar esa captura. Erby puede pedir la tendencia de cualquier periodo, abrir una captura específica, hacer zoom en un rango de frecuencia, cambiar a envolvente, comparar ejes y comparar dos momentos en el tiempo — los mismos pasos que da un analista humano, con cada uno visible en la respuesta.

Entonces, ¿una base de datos de fallas es inútil para el monitoreo de condición?

No. Es realmente útil para un conjunto específico de tareas: límites de alarma iniciales razonables por tipo de componente, marcos de criticidad, los modos de falla que conviene considerar para una clase de activo, y cuánto suele tardar en progresar un defecto determinado. En una máquina nueva sin historial propio, la estadística de máquinas parecidas es la mejor primera aproximación disponible. Lo que una población no puede hacer es decirte qué está haciendo hoy una máquina individual.

¿El historial de una máquina puede predecir lo que hará una máquina idéntica?

No de forma confiable. Dos bombas idénticas —mismo modelo, mismo año, mismo servicio— montadas a cuarenta metros una de otra mostrarán líneas base distintas, porque la rigidez de la cimentación, los esfuerzos de la tubería y las resonancias locales no son los mismos. Los datos poblacionales te dicen qué esperar de esa clase de máquina; solo la línea base de esa máquina te dice si algo cambió.


Para seguir leyendo