Qué merece la pena automatizar de verdad con IA en una fábrica

Casi nada de lo que decide un proyecto de IA en una fábrica es modelado. Es poner nombre al tipo de problema que se tiene, comprobar si los datos de ejecución pueden sostenerlo y diseñar qué ocurre cuando el modelo se equivoca.

Reglas, machine learning, optimización y modelos de lenguaje: qué encaja con cada problema

Las reglas y la estadística van primero, y merecen más respeto del que se les da. Si una regla que un ingeniero puede escribir en un papel captura la mayor parte del valor, la comparación honesta de cualquier modelo es contra esa regla, no contra no hacer nada.

El machine learning se gana su sitio donde la relación entre las entradas y el resultado es real pero nadie sabe escribirla: decenas de variables de proceso interactuando, un defecto que depende del lote de material, la humedad ambiente y la posición en la cavidad. Conoce las condiciones que se le mostraron y no dice nada útil sobre condiciones que nunca ha visto.

La optimización es una disciplina distinta y se etiqueta como IA continuamente. Programar una planta con capacidad finita, secuenciar para minimizar los cambios de formato, asignar operarios cualificados: son problemas de restricciones con una función objetivo. No necesitan ejemplos etiquetados, pero sí tiempos de proceso y restricciones honestos, que normalmente hay que medir en lugar de suponer. Para planificar, un solver capaz de expresar sus restricciones reales de utillaje y de secado es casi siempre la herramienta correcta, porque planificar es un problema de restricciones y no de predicción.

Los modelos de lenguaje son los últimos en llegar y su encaje es específico. Sirven para el trabajo con forma de documento y de conversación: leer una consulta entrante y redactar una estructurada, condensar un largo historial de mantenimiento en algo que un técnico pueda leer antes de acercarse a la máquina, responder qué dice una instrucción de trabajo sobre una preparación. No son instrumentos de medida: pedirle a uno que prediga el fallo de un rodamiento a partir de datos de vibración es usar un martillo con un tornillo.

Qué datos necesita realmente un proyecto de IA en una fábrica

Un modelo necesita ejemplos que emparejen una situación con un resultado, con contexto suficiente para distinguir una situación de otra: una señal o un conjunto de condiciones ligadas a un pedido, una máquina, un utillaje, un lote de material, un operario y una marca de tiempo que sea cierta. La marca de tiempo importa más de lo que se espera. Si las confirmaciones se registran a posteriori al final del turno, todos los eventos de ese turno comparten una hora aproximada, y cualquier cosa que dependa de la secuencia o de la duración aprende la costumbre de introducción de datos en lugar del proceso.

El lado del resultado suele estar peor. El mantenimiento predictivo necesita averías registradas como averías, con una causa y una fecha, no como una parada imprevista con el campo de motivo en blanco. La predicción de calidad necesita el rechazo imputado a la operación y al tipo de defecto que lo provocó, no agregado en una cifra mensual. La previsión necesita un histórico de consumo que no haya sido reescrito en silencio por regularizaciones de stock. En la mayoría de plantas las entradas viven en el historiador y los resultados viven en un cuaderno de mantenimiento o en la hoja de cálculo de una persona.

La prueba no es cuántos gigabytes guarda el historiador, sino si puede extraer, para una línea y una familia de producto, un año de filas donde cada fila lleve las condiciones y el resultado, y dos personas que conozcan el proceso coincidan en que las filas son ciertas. Si esa extracción cuesta una semana de conciliación manual, el proyecto no es el modelo; es el registro. Por eso la calidad de los datos del MES y del historiador es la restricción activa, y ninguna sofisticación de modelado recupera lo que nunca se capturó.

Previsión de demanda y de consumo, donde el retorno está más cerca

La previsión suele tener el camino más corto hasta el dinero, porque la alternativa es visiblemente floja: la mayoría de las plantas cogen el año pasado y le suman un porcentaje, o le piden a ventas un número que en realidad es un objetivo. Un modelo que use histórico de pedidos, estacionalidad, mix de clientes, cartera abierta y efectos de calendario gana a eso en los artículos con demanda regular y repetitiva. En los artículos intermitentes y de proyecto, que suelen ser la mayoría de las referencias y una parte pequeña del volumen, normalmente no gana, y es difícil batir a una referencia ingenua o de tipo Croston. La versión honesta segmenta primero el catálogo y deja esos artículos a una política de stock y al criterio humano.

El valor aparece aguas abajo y no en la previsión en sí: se mueven los stocks de seguridad, cambia el momento de compra de los artículos con plazo largo, y los cambios de formato de emergencia que destrozan un programa se vuelven más raros. Un porcentaje de exactitud de la previsión en una diapositiva no es un beneficio; los días de inventario y el número de urgencias sí lo son.

Mantenimiento predictivo, solo donde el modo de fallo es realmente predecible

Aquí todo depende de si el fallo se desarrolla gradualmente y deja una firma en algo que se pueda medir. Degradación de rodamientos, desequilibrio, desalineación, obstrucción progresiva en un filtro o en un circuito de refrigeración, deriva de la presión hidráulica, corriente del motor subiendo poco a poco en la misma operación: se desarrollan a lo largo de semanas o meses, ocasionalmente solo horas, lo que suele ser demasiado tarde para que merezca la pena instrumentarlo, y se ven en vibración, corriente, temperatura o presión. Un modelo puede verlos, y a menudo también un umbral bien elegido, que es precisamente por lo que aquí importa la comparación contra la estadística simple.

Una tarjeta de control que muere, una herramienta rota por una plaquita defectuosa, un daño por un error del operario: son prácticamente instantáneos, y ningún modelo los predice a partir de una tendencia que no existe.

La segunda condición es que el aviso tiene que comprar tiempo que se pueda usar. Si la pieza tiene un plazo de entrega largo y la línea no puede parar antes del fin de semana, la inversión rentable es una política de repuestos, no un modelo. Calcule la ventana de intervención antes que el presupuesto de sensores.

Predicción de calidad y reducción de rechazo

La calidad es donde suele estar el mayor dinero y donde los requisitos de datos son más exigentes. La versión atractiva predice, a partir de las condiciones durante la tirada, qué piezas o lotes están en riesgo, para que alguien pueda corregir antes de generar el rechazo en lugar de encontrarlo en la inspección final.

Funciona cuando el proceso está instrumentado con la resolución de aquello que se quiere predecir, y cuando el rechazo lleva un código de causa real contra la operación. Falla en silencio cuando el rechazo se imputa al cierre del pedido y contra el pedido entero, porque entonces el modelo no puede saber qué condiciones produjeron qué fallo.

Un paso nada glamuroso se paga solo antes de que lo haga ningún modelo: capturar los motivos de rechazo en la máquina, en el momento, desde una lista corta de causas que el operario reconozca. Muchas plantas que piden predicción de calidad descubren solo con esos datos que un número pequeño de causas concentra la mayor parte de la pérdida, y cierran la mayor con un cambio de ingeniería. Eso es un buen resultado, no un proyecto fallido.

IA para la programación de la producción: por qué es un problema de optimización y no de predicción

Si el plan se cae todas las semanas, la causa rara vez es falta de inteligencia y casi siempre falta de restricciones. Lo que lo cambia es un programador que respete el utillaje compartido, las familias de cambio de formato, las cualificaciones de los operarios, los tiempos de curado y las ventanas de mantenimiento que usted pretende mantener.

El aprendizaje ayuda aquí de una forma estrecha y real: los tiempos de proceso. Un programa construido sobre tiempos estándar que nadie ha vuelto a medir en años es preciso sobre los números equivocados, y las duraciones reales capturadas a través del MES pueden actualizar aquello con lo que planifica el programador. Juzgue una propuesta de programación por las restricciones que sabe expresar y por lo rápido que replanifica cuando algo se rompe; un plan que tarda toda la noche en regenerarse acaba sobrescrito a mano en la reunión de la mañana.

Detección de anomalías en señales de energía y de proceso

La detección de anomalías aprende qué aspecto tiene lo normal y señala la desviación. Encaja con señales continuas donde hay abundante comportamiento bueno y pocos fallos etiquetados: consumo eléctrico por ciclo, consumo de aire comprimido, rendimiento de una enfriadora, una señal de proceso cuya forma es estable cuando las cosas van bien.

Su fuerza es reaccionar a lo que nadie había anticipado. Su debilidad es que solo dice que algo es inusual, nunca qué va mal, y una planta que recibe alertas inexplicadas aprende a ignorarlas. El trabajo de diseño no es el detector sino el encaminamiento: qué alertas van a quién, cuál es la primera comprobación, y cómo se registra la respuesta para que la siguiente alerta de la misma forma llegue con su histórico adjunto.

IA en ventas y en la relación con el cliente, donde el trabajo tiene forma de documento

La parte comercial de una empresa de fabricación funciona con documentos y conversaciones: consultas, especificaciones, ofertas, confirmaciones de pedido, preguntas sobre entregas, reclamaciones. Aquí es donde los modelos de lenguaje encajan de verdad, porque el trabajo consiste en leer, extraer, redactar y resumir.

En concreto: una consulta entrante interpretada en pieza, cantidad, fecha solicitada y requisitos especiales, con las ofertas anteriores puestas al lado. Un hilo de correo condensado en un registro del CRM que recoja el compromiso adquirido y la siguiente acción.

Dos reglas evitan que esto se tuerza. El modelo redacta y una persona envía, al menos hasta que se conozca la tasa de error en ese flujo de trabajo. Y todo lo que sea un dato — precio, plazo, stock, fecha comprometida — sale del sistema de registro y no del modelo, que debe citar un valor consultado y nunca generarlo. Una automatización del CRM que se inventa un plazo de entrega es peor que ninguna, porque compromete a la empresa.

Cuantificar lo que está en juego antes de comprar nada

Ponga nombre a la pérdida en las unidades que su planta ya mide: coste de rechazo al mes en la familia de producto en cuestión, horas de parada imprevista en la máquina restricción multiplicadas por lo que vale allí una hora en margen de contribución y no en tarifa de máquina, portes urgentes, inventario inmovilizado en las piezas que una previsión movería, horas a la semana dedicadas a reteclear entre sistemas.

Después estime, de forma pesimista, qué parte de esa pérdida podría atacar de manera plausible la aplicación. El mantenimiento predictivo no elimina las paradas; como mucho convierte algunas paradas imprevistas en planificadas, para los modos de fallo que cubre. Un modelo de calidad no elimina el rechazo; acorta el tiempo entre que un proceso se tuerce y alguien se da cuenta.

Si ese número honesto, puesto frente a un coste total a lo largo de la vida útil que usted realmente vaya a planificar, incluyendo la integración y las personas que lo van a llevar, no supera el listón que su departamento financiero aplica a cualquier otra inversión de ese tamaño, el proyecto es un experimento científico. Está permitido, pero debe financiarse y juzgarse como tal.

Lo que cuesta de verdad la integración

El modelo suele ser la parte barata; el coste vive en las costuras. Sacar las señales de las máquinas va primero, y una planta real es un parque mixto: algunos activos hablan OPC UA, otros Modbus o un protocolo serie, otros ofrecen un contacto libre de potencial, y algunos controles cerrados necesitan un sensor retrofit en el husillo, en el circuito hidráulico o en la línea de alimentación. Después la salida tiene que aterrizar en algún sitio donde provoque una acción: una pantalla que el operario ya mira, una orden de trabajo abierta en mantenimiento, una restricción alimentada al programador, un bloqueo aplicado en calidad.

Luego viene la conciliación de datos maestros que nadie incluye en el alcance. Códigos de artículo que difieren en un sufijo entre sistemas, unidades de medida que no cuadran, una BOM mantenida en dos sitios, identificadores de máquina que cambiaron cuando se reordenó la línea. Nada de esto es difícil y todo lleva más tiempo que el software. Una propuesta que pone precio al modelo y deja las costuras como «integración por definir» no es un precio.

Quién opera el modelo, y qué pasa cuando se equivoca

Todo modelo desplegado necesita un responsable con nombre y apellidos, y la pregunta de compra es quién será esa persona en su organización. Esa persona tiene que saber con qué se entrenó, qué condiciones quedan fuera de eso, por qué produjo una salida determinada, y cómo sacarlo del bucle sin parar la producción. Un modelo que deja de responder debe recaer en lo que controlaba el proceso antes que él — el plan de muestreo, el umbral, la comprobación del operario — y no en una puerta abierta ni en una línea bloqueada. Decida cuál de ellas es antes de la puesta en marcha.

La explicabilidad no es una preocupación filosófica en una planta, es un requisito de adopción. Una recomendación que dice qué señal se movió, cuánto y contra qué referencia, se acaba ejecutando. Una puntuación sin razonamiento se sobrescribe, y en cuanto sobrescribir se vuelve rutina el sistema es decoración.

El exceso de alertas destruye la confianza más rápido que los fallos no detectados, por la misma razón que el exceso de rechazo en un puesto de inspección: una falsa alarma es visible al instante y para todos, mientras que un fallo no detectado permanece invisible hasta que llega la avería. Diseñe la tasa de alertas en torno a la atención realmente disponible en planta, y encamine la franja dudosa a una persona, no a la línea.

Gobierno, deriva y la carga de mantenimiento que nadie presupuesta

Un modelo es una foto de su proceso en el momento en que se entrenó, y su proceso se mueve: un proveedor nuevo, un utillaje reacondicionado, una revisión de pieza, una reordenación de línea, un mix de producto distinto, un sensor sustituido por otro ligeramente diferente. Cada una puede desplazar las entradas lo suficiente para que el modelo de ayer esté hoy silenciosamente equivocado, y el modo de fallo no es un mensaje de error sino un consejo progresivamente peor.

Vigile las entradas además de las salidas, porque la deriva de las entradas se ve antes que la degradación del resultado. Mantenga un conjunto de prueba reservado con casos reales, incluidos los dudosos, para poder comparar honestamente un modelo nuevo con el actual. Versione el modelo y registre qué versión produjo qué recomendación; después de un reentrenamiento, las salidas de ayer venían de otro juez.

Y presupueste el esfuerzo continuo. Un modelo en producción es un activo que se mantiene, más cerca de un equipo de proceso que de un informe comprado. Si nadie tiene tiempo asignado a reentrenar, revisar alertas y comprobar que los datos siguen llegando, se degradará hasta que la gente deje de usarlo.

Un primer proyecto realista, con criterios de aceptación

Elija una pérdida concreta en una línea o una familia de producto, formulada como una frase con un número dentro: rechazamos esto en esta operación, perdemos estas horas en la máquina restricción, mantenemos este stock porque no sabemos prever esta familia. Si el proyecto no se puede enunciar así, no está listo.

Antes de comprar nada, haga la extracción de datos. Un año, una línea, condiciones y resultados en las mismas filas, dos personas que conozcan el proceso confirmando que las filas son ciertas. Después compárelo con la alternativa simple: un umbral, un gráfico de control o el criterio del planificador actual.

Escriba los criterios de aceptación en unidades de planta antes de la puesta en marcha, por pares, para que la contrapartida quede explícita. Para mantenimiento predictivo, un número declarado de modos de fallo cubiertos detectados con al menos una semana de aviso, frente a un tope de falsas alertas al mes. Para previsión, una reducción declarada de días de inventario en las familias modeladas sin aumentar las roturas de stock. Para calidad, una reducción declarada de rechazo en la operación objetivo frente a los mismos meses del año anterior, con los cambios de proceso registrados al lado.

Ponga nombre al responsable, al comportamiento ante fallo y al calendario de reentrenamiento en el mismo documento, y fije una fecha de revisión con la opción honesta de parar. Un primer proyecto que termina en la decisión de no ampliar, tomada sobre evidencia, es un éxito. Un piloto que se convierte en una demostración permanente, no.

Dónde encaja Meta Smart Factory

Meta Smart Factory es modular, y eso importa aquí porque el módulo de IA y machine learning se apoya sobre la capa de ejecución en lugar de ponerse al lado. El MES aporta los eventos y el contexto, la conectividad IIoT y OPC UA aportan las señales de máquina, Calidad aporta el rechazo con sus causas, Mantenimiento aporta el histórico de averías, y el APS consume la salida cuando la respuesta es un programa y no una predicción.

Puede empezar con un módulo contra una restricción concreta y añadir el siguiente cuando el primero esté en uso. Lo que ninguna plataforma elimina es la parte difícil: acordar qué significan los números, conseguir que las causas se capturen en la máquina, y decidir quién es el responsable de un modelo cuando se equivoca. Hablar de esa secuencia para una planta concreta es una primera conversación más útil que una demostración, porque una demostración siempre funciona.