La IA generativa en fabricación aporta más valor cuando trabaja sobre datos reales de planta en lugar de sobre conocimiento general. Este artículo recorre los casos de uso que resisten en un taller real, la infraestructura de datos que necesitan y las salvaguardas que mantienen un modelo de lenguaje útil en lugar de arriesgado. Al terminar sabrás con qué proyecto empezar y cómo alimentarlo con datos de máquina en directo por MQTT.
Por qué se estancan los proyectos de IA generativa en fabricación
La mayoría de los primeros experimentos impresionan en una demo y luego se desvanecen. El patrón es conocido: alguien pega unos cuantos códigos de alarma en una ventana de chat, obtiene una explicación plausible y el equipo concluye que el modelo "conoce" las máquinas. Una semana después, explica con total seguridad una alarma que no existe en ese controlador.
El problema de fondo es el anclaje en los datos. Un gran modelo de lenguaje tiene amplios conocimientos sobre máquinas CNC, PLC y métodos de calidad, pero no sabe nada de tu línea 3, de tu receta para la pieza 4711 ni de que el horno del turno de noche siempre trabaja diez grados por encima. Sin ese contexto, rellena el hueco con suposiciones.
Así que la pregunta útil no es "¿qué puede hacer la IA generativa?", sino "¿qué tareas consisten sobre todo en convertir datos y documentos existentes en texto, y dónde podemos darle esos datos al modelo de forma fiable?". Ese replanteamiento conduce a una lista corta de casos de uso que funcionan.
Casos de uso que funcionan hoy
| Caso de uso | Datos de entrada | Salida | Nivel de riesgo |
|---|---|---|---|
| Informes de turno y de paradas | Estados de máquina, contadores, alarmas del turno | Resumen legible para el siguiente turno | Bajo |
| Asistente de diagnóstico | Alarmas en directo, telemetría reciente, manuales, incidencias anteriores | Causas probables ordenadas y comprobaciones | Medio |
| Preguntas sobre datos en lenguaje natural | Historian o base de datos de series temporales | Respuesta más la consulta ejecutada | Bajo a medio |
| Ayuda con código y configuración | Tags de PLC, estructura de topics, payloads de ejemplo | Borradores de scripts, funciones de Node-RED, SQL | Medio (requiere revisión) |
| Redacción de instrucciones de trabajo | SOP existentes, cambios de ingeniería | Borradores de instrucciones para revisión | Bajo |
| Informes de desviaciones de calidad | Mediciones, especificaciones, resultados de inspección | Primer borrador de un informe de no conformidad | Medio |
Informes de turno y resúmenes de paradas
Es la victoria más fácil. En todas las plantas hay alguien que dedica la última media hora del turno a recopilar lo ocurrido: qué máquinas pararon, por qué, cuántas piezas se produjeron y qué debe vigilar el siguiente turno. Los datos ya existen como estados de máquina y contadores. Un pequeño servicio puede recoger los eventos del turno, construir un resumen estructurado (con las cifras calculadas en código, no por el modelo) y pedir al modelo de lenguaje que lo convierta en prosa legible.
La decisión de diseño importante es dejar que el modelo redacte, no que calcule. Calcula el OEE, los minutos de parada y el número de piezas en Python o SQL, pásalos como hechos e indica al modelo que use solo esos valores. Si quieres ver este patrón con más detalle, consulta resúmenes de datos de sensores con LLM.
Asistentes de diagnóstico
Cuando una máquina salta en alarma a las 3 de la madrugada, el técnico necesita la página del manual, la última incidencia similar y el estado actual de las señales relacionadas. Un asistente de diagnóstico recupera esas piezas y las presenta juntas con una lista de comprobaciones sugerida. La recuperación sobre manuales e incidencias anteriores es el núcleo, y por eso este caso de uso suele basarse en la generación aumentada por recuperación para datos industriales.
La parte en directo importa tanto como los documentos. Un asistente que ve "temperatura del husillo subiendo durante 20 minutos, caudal de refrigerante caído a las 02:41" da sugerencias mucho mejores que uno que solo ve el número de alarma.
Ayuda con código e integración
Los ingenieros dedican una cantidad sorprendente de tiempo a escribir código de unión: una función de Node-RED para remodelar un payload, un suscriptor en Python, una consulta SQL para un informe. Los modelos de lenguaje redactan bien este tipo de código cuando ven ejemplos reales. Dale al modelo un payload MQTT de ejemplo y tu convención de topics y podrá redactar un parser en segundos. Trata el resultado como el código de un compañero nuevo: revísalo, pruébalo con el broker público de pruebas y después promuévelo.
Copilotos industriales
Combina los tres anteriores y obtendrás lo que los fabricantes llaman un copiloto de IA industrial: una única interfaz donde un operario hace preguntas, obtiene resúmenes y redacta acciones. Empieza con acceso de solo lectura. Escribir consignas o comandos desde un modelo es un problema distinto y mucho más difícil, con sus propias salvaguardas.
La base de datos: transmitir datos de planta por MQTT
Todos los casos de uso anteriores dependen de datos actualizados y estructurados. MQTT encaja de forma natural porque las máquinas, los gateways y los dispositivos de borde ya publican en él, y cualquier número de consumidores puede suscribirse sin tocar las máquinas.
Una estructura de topics práctica sigue los niveles de ISA-95 para que tanto las personas como los modelos puedan leerla:
connectmq/factory1/production/line1/cnc1/telemetry
connectmq/factory1/production/line1/cnc1/state
connectmq/factory1/production/line1/cnc1/alarms
Un payload de telemetría típico:
{
"ts": "2026-10-16T02:41:12Z",
"spindleTempC": 61.4,
"coolantFlowLpm": 8.2,
"spindleLoadPct": 74,
"partCount": 1532
}
Los nombres de topic legibles cumplen una doble función: ayudan a las personas en un explorador de topics y dan contexto al modelo sin coste adicional. Un modelo que ve line1/cnc1/alarms no necesita que le digan qué son los datos.
Un recolector de turno mínimo en Python
El siguiente servicio se suscribe a toda una planta, guarda el último estado de cada máquina y cuenta las alarmas. Al final del turno entregaría este resumen estructurado al LLM que utilices. Usa el área pública de pruebas de broker.connectmq.com, así que mantén los datos sintéticos.
import json
import time
import uuid
from collections import defaultdict
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/genai-7f3a"
latest = {}
alarm_counts = defaultdict(int)
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe(f"{PREFIX}/factory1/production/+/+/#", qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
machine = "/".join(parts[-3:-1]) # p. ej. line1/cnc1
kind = parts[-1]
try:
payload = json.loads(msg.payload)
except json.JSONDecodeError:
return
if kind == "alarms":
alarm_counts[machine] += 1
else:
latest.setdefault(machine, {}).update(payload)
def build_summary():
return {
"machines": latest,
"alarmCounts": dict(alarm_counts),
"generatedAt": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"shift-collector-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
try:
while True:
time.sleep(60)
summary = build_summary()
print(json.dumps(summary, indent=2))
# Pasa `summary` a tu LLM con un prompt como:
# "Write a shift report using ONLY these facts. Do not invent numbers."
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Ten en cuenta que aquí el broker no realiza ningún trabajo de IA. ConnectMQ transporta los datos de forma fiable; el recolector y el modelo son tus propios servicios, que se conectan como clientes MQTT normales. Esa separación es sana: puedes cambiar de modelo sin tocar las máquinas.
Salvaguardas que mantienen útil la IA generativa
Una lista numerada que conviene aplicar a cada piloto de IA generativa en fabricación:
- Hechos dentro, prosa fuera. Calcula todas las cifras fuera del modelo e indícale que use solo los valores proporcionados.
- Cita la fuente. Pide al modelo que indique el topic, documento o incidencia de donde procede cada afirmación, y muéstraselo al usuario.
- Primero solo lectura. Ningún topic de comandos al alcance del modelo hasta que la versión de solo lectura se haya ganado la confianza.
- Aprobación humana de las acciones. Si el modelo redacta una orden de trabajo o un cambio de consigna, una persona lo aprueba. Consulta control seguro de dispositivos IoT con IA para ver los patrones del lado de los comandos.
- Registra prompts y respuestas. Los necesitarás para depurar respuestas erróneas y mejorar los prompts.
- Mantén privados los datos sensibles. Usa un broker privado con credenciales para los datos reales de planta, nunca un área pública de pruebas.
- Mide la utilidad. Pregunta a los operarios si el resumen les ha ahorrado tiempo; descarta los casos de uso que no lo hagan.
Elegir dónde se ejecuta el modelo
Las API de LLM alojadas son la forma más rápida de empezar y sirven para resumir datos no sensibles. Las plantas con políticas de datos estrictas suelen ejecutar modelos abiertos en local; un servidor en las instalaciones con un runtime de modelos local, suscrito al broker de la planta, puede hacerlo sin que ningún dato salga del emplazamiento. En ambos casos, el camino de los datos es el mismo: las máquinas publican en el broker, un suscriptor construye el contexto, el modelo redacta el texto y el resultado vuelve a un topic, a un sistema de incidencias o a un correo electrónico.
Si estás trazando la arquitectura general de modelos, dispositivos de borde y brokers, la guía de IA e IoT explica dónde encaja cada tipo de modelo.
Acertar con la infraestructura
El broker se convierte en una dependencia compartida en cuanto varios servicios leen los mismos datos de planta, así que no debería ser una máquina virtual olvidada debajo de la mesa de alguien. Un broker MQTT gestionado te da TLS, credenciales y monitorización sin tener que operar el servidor tú mismo. ConnectMQ también detecta topics ISA-95 y de Unified Namespace y puede republicar datos Sparkplug B en topics ISA-95 legibles, que es exactamente el tipo de estructura que facilita a personas y modelos el consumo de los datos de planta. Esos mismos topics pueden alimentar también un gemelo digital 3D de la planta.
Para prototipar, el servidor MQTT público gratuito en broker.connectmq.com te permite construir el recolector y los prompts con datos simulados antes de tocar nada en producción.
Pon en marcha tu canal de datos de planta en ConnectMQ
La IA generativa es tan buena como los datos que le das. Crea un broker privado en el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito, conecta un gateway o un simulador y observa cómo llegan los topics al explorador de topics en directo. Una vez que los datos fluyan, tu primer generador de informes de turno es cuestión de una tarde de trabajo.
Preguntas frecuentes
¿Cuál es el mejor primer proyecto de IA generativa en una fábrica?
Los resúmenes automáticos de turno o de paradas. Los datos ya existen, el resultado es fácil de verificar y una frase errónea cuesta poco porque una persona la lee antes de actuar.
¿Puede un modelo de lenguaje controlar máquinas directamente?
No debería, al menos no sin límites estrictos y aprobación humana. Empieza con asistentes de solo lectura y añade rutas de comandos solo con validación, listas de permitidos y pasos de confirmación.
¿ConnectMQ incluye funciones de IA?
No. ConnectMQ es el broker MQTT que transporta los datos de planta; tu aplicación de LLM se conecta a él como un cliente MQTT normal, lo que te deja libertad para elegir cualquier modelo.
¿Cómo evito que el modelo se invente cifras?
Calcula cada métrica en código, pasa los resultados como hechos estructurados e indica al modelo que use solo esos valores. Revisar las salidas frente a los datos de origen durante el piloto detecta los problemas restantes.
