Tres años llevo viendo el mismo pitch deck en distintas versiones: «desplegaremos un asistente de IA para operarios, ahorrarán un 30 % de tiempo, ROI en 8 meses». La realidad tras 12 meses en 10 despliegues: cuatro casos de uso que se recuperaron (muchas veces por triplicado) y seis que se comieron el presupuesto mientras el equipo pasaba del entusiasmo a la frustración y al silencio. Aquí van los casos de uso concretos con cifras, y unos cuantos que recomendamos rechazar al cliente sin importar cuánto dinero tenga disponible.
Cuatro casos de uso que pagan
1. Búsqueda de SOP y resumen de cambio de turno
**Caso de uso:** el operario necesita encontrar rápido un procedimiento («cómo resetear la alarma 14-021 en la línea L4») o entra al turno y quiere un brief de 90 segundos sobre lo que pasó en los dos turnos anteriores.
**Stack:** RAG sobre documentos SOP + shift logs + tickets de mantenimiento. Tableta en la línea (Zebra ET40, Panasonic Toughbook) o asistente por voz con auricular Bluetooth (Plantronics Voyager 5200 UC) para entornos ruidosos.
**Cifras reales del despliegue (proveedor Tier-2 automoción alemán, piloto de 3 meses):** - 14 horas / semana de tiempo ahorrado en cambio de turno y búsqueda de SOP entre 8 operarios - A una tarifa horaria de 28 EUR / h fully-loaded → **1 568 EUR / mes de ahorro** - Despliegue e integración: 38 000 EUR (pipeline RAG + 6 semanas de field tuning) - **ROI: 24 meses** en una sola línea. Al escalar a 4 líneas → 8 meses.
Clave: no jugamos al «súbelo todo». Un ingeniero de dominio junto con el operario recorrió 200 preguntas frecuentes del shift log y con esos chunks se afinó el retrieval. Las preguntas que no se hacen no se optimizaron — el ROI no las necesita.
2. Asistente de troubleshooting para PLC / SCADA / robótica
**Caso de uso:** el operario topa con una alarma que no identifica de inmediato. Abre el copilot, escribe «Allen-Bradley CompactLogix 5380, alarm code 16#0001, RPI exceeded», y recibe: - descripción del error en lenguaje humano - top-3 de causas más probables según tickets históricos - diagnóstico paso a paso - enlace al manual Rockwell con página exacta
**Stack:** RAG sobre: manuales PLC (Rockwell Knowledgebase, Siemens TIA Portal docs, Beckhoff TwinCAT docs) + tracker interno de incidencias (Jira, ServiceNow, sistema propio) + foros de comunidad (Plctalk.net, Reddit /r/PLC scrapeados). Modelo de embedding: BGE-M3 o Cohere multilingual. Reranker: BGE-Reranker-v2-m3.
**Cifras reales del despliegue (fabricante EMS esloveno, despliegue completo de 9 meses):** - MTTR (Mean Time To Repair) cayó un 18 % en 6 meses - Sustituyó la interacción informal «pregunto a Peter, que lleva 10 años con esas líneas» — Peter pudo dedicarse a cosas de más valor - Con 200 incidentes / mes × 45 min de MTTR medio × 18 % de reducción × 65 EUR / h de técnico → **8 775 EUR / mes** - Despliegue: 52 000 EUR - **ROI: 6 meses.**
Clave: Peter no se fue. Peter ayudó a entrenar el sistema — sus 10 años de experiencia se integraron en prompt templates y en el feedback loop. Sin Peter el sistema habría sido genérico y se habría devuelto en 24+ meses.
3. Reporte de desviación de calidad / borrador de 8D
**Caso de uso:** la línea fabricó un batch con desviación (calibración incorrecta, defecto de material, fallo del operario). Operario + ingeniero de calidad deben redactar reporte 8D, análisis de causa raíz, plan de acción correctora. Suele llevar 4–8 horas.
**Stack:** LLM (Claude Sonnet 4.6, Llama 3.3 70B local o Qwen2.5-32B-Instruct) con acceso a: plantilla 5 Why, formato Ishikawa, reportes 8D históricos de la empresa, ISO 9001 / IATF 16949 guidelines. El ingeniero de calidad describe el defecto en 3–5 frases, el sistema genera el **borrador** del 8D — la revisión humana y la cumplimentación se mantienen.
**Cifras reales del despliegue (Tier-1 metal forming austriaco):** - Tiempo de borrador 8D: de 6 h a 1,5 h de media - 14 reportes / mes × 4,5 h de ahorro × 55 EUR / h ingeniero → **3 465 EUR / mes** - Despliegue: 18 000 EUR (stack más sencillo, por formato más estricto) - **ROI: 5 meses.**
Clave: la IA nunca cerró ningún 8D — esa es la puerta human-in-the-loop. Genera borrador + propuestas de acciones preventivas según precedentes. Sin revisión el ROI se transformaría en compliance risk.
4. Instrucciones multilingües para operarios
**Caso de uso:** la línea tiene operarios de 5 países (SK, UA, RO, PL, HU). Los SOP están en original inglés. Los operarios necesitan instrucciones paso a paso en su lengua materna.
**Stack:** GPT-5 o Claude Sonnet 4.6 (cloud, business-tier subscription con GDPR EU region) con tool-call para TTS nativo (Azure Speech, ElevenLabs). El operario escanea el código QR del SOP, recibe la explicación en su idioma y puede hacer preguntas complementarias.
**Cifras reales (montaje electrónico polaco):** - Onboarding de un operario nuevo: de 12 días a 7 días (40 % de reducción) - Con 6 operarios nuevos / trimestre × 5 días × 8 h × 22 EUR / h fully-loaded → **5 280 EUR / trimestre = 21 120 EUR anuales** - Despliegue: 24 000 EUR - **ROI: 14 meses.**
Clave: los SOP eran de calidad en el original. Para fábricas con SOP malos y obsoletos el sistema traduce instrucciones malas — no es un traductor de errores, solo de la barrera lingüística.
Seis casos de uso donde no paga
1. Control de proceso en tiempo real
«Añadimos IA que optimiza parámetros de la línea en tiempo real». Nunca.
La latencia de una llamada LLM es 800–3 000 ms. El process control loop trabaja en ciclos de 10–100 ms. Aparte de eso: los requisitos regulatorios (IEC 61508, ISO 13849) exigen comportamiento determinista — un LLM por definición es no determinista.
**Qué hacer en su lugar:** PLC clásico + control clásico (PID, MPC). El LLM tiene valor en el **análisis offline de logs y propuesta de tuning** de parámetros — no en inferencia en tiempo real.
2. QA visual rutinario
«Un LLM con módulo de visión mira la foto de la pieza y dice si tiene defecto».
Los LLM multimodales (GPT-4o, Claude Sonnet 4.6 vision) tienen 3–5 s de latencia, 70–85 % de accuracy en una tarea de visión no experta, $0,005–0,015 por imagen. Un sistema de visión purpose-built (Cognex VisionPro Deep Learning, Keyence CV-X) tiene 30–80 ms de latencia, 98–99,7 % de accuracy, coste cero por imagen tras la compra del HW.
**Cuándo tiene sentido un LLM:** **análisis post-incidente** (a posteriori, el experto quiere un dictamen rápido), categorización de edge cases (defecto que el clasificador no conocía), generación de reportes de defectos a partir de 50 fotos. QA en tiempo real en la línea — nunca.
3. Planificación de mantenimiento
«Un LLM decide cuándo planificar mantenimiento preventivo según patrones de uso».
Para eso existe el CMMS (Computerized Maintenance Management System) — IBM Maximo, SAP PM, Limble, MaintainX. Estos sistemas tienen reglas deterministas, integración con el ERP (qué hay que pedir) y logs auditables. El LLM no añade valor a la optimización que el scheduler determinista hace mejor.
**Cuándo ayuda el LLM:** **explicar** por qué el CMMS propuso cierto calendario, summary report para dirección («esta semana el mantenimiento se llevó el 47 % de la capacidad del equipo, el 60 % en la línea L3 y las tres averías más frecuentes fueron…»). Decision-making — no.
4. Interacción safety-critical
«El copilot de IA le dice al operario si es seguro entrar en una zona».
El LSI (Life Safety Interlock) debe ser analizado mediante FMEA, certificado (SIL 2/3), determinista. El LLM no tiene sitio aquí — ni como canal secundario, ni como informativo. El lenguaje del LSI es: cortina de luz, relé de seguridad, arranque de dos canales, reset manual, ningún software por encima del cual pueda situarse un LLM.
**Cuándo ayuda el LLM:** **simulación de formación** de escenarios safety para operarios fuera de la zona viva. Live decision — en absoluto.
5. Decisiones de inventario / pedidos / supply chain
«La IA decide cuántas materias primas pedir según tendencias».
Esa es tarea del sistema ERP-MRP (SAP S/4HANA, Oracle, NetSuite) con los módulos forecast correctos. El LLM aporta aquí un 5–10 % marginal de accuracy sobre un MRP bien configurado, y un 30–50 % sobre uno malo. Pero arreglar un MRP malo sale más barato y es más sostenible que añadir una capa LLM encima.
6. «Chatbot universal para toda la fábrica»
«El operario puede preguntar cualquier cosa — SOP, RR. HH., nómina, datos de operaciones, OEE, calidad, planificación».
Un chatbot único que lo sabe todo, lo sabe todo mal. Las authority boundaries (datos de RR. HH. vs. operacionales vs. financieros) se difuminan, el role-based access control es imposible de implementar de forma robusta en un LLM (prompt injection breaks RBAC) y el operario pierde la confianza con la primera respuesta mala.
**Mejor enfoque:** 3–5 copilots especializados con dominio acotado. Cada uno con su propio RAG, su propio system prompt y su propio audit log. UI unificada, backend especializado.
Decisiones de stack en 2026
LLM local vs. cloud
**Local (servidor GPU propio):** adecuado para despliegues mayores (50+ operarios al día), sectores regulados (automotive aerospace con ITAR-compliance), fábricas sin internet estable.
Modelos concretos en 2026: - **Qwen2.5-32B-Instruct AWQ** — 24 GB VRAM, excelente capacidad multilingüe, buena para lenguas UE - **Llama 3.3 70B AWQ** — 48 GB VRAM, reasoning más potente, mejor para troubleshooting - **Mistral Small 3 (22B)** — 16 GB VRAM, buena opción para setups cost-sensitive
Hardware: 1× RTX A6000 (48 GB) o 2× RTX 4090 (48 GB cumulativos) para Llama 3.3 70B. Precio 12–18 k EUR. Throughput con vLLM serving: 40–80 RPS con la mezcla típica de queries de planta.
**LLM cloud:** adecuado para despliegues más pequeños, fases piloto, proyectos donde no se necesita data residency. Default en 2026: **Claude Sonnet 4.6 (Anthropic EU region)** o **GPT-5 (Azure OpenAI EU)**. Coste per-query típico 0,002–0,012 EUR con RAG de 4 k input tokens + 300 output tokens. Coste mensual con 200 consultas / día × 22 días × 8 operarios = **75–250 EUR / mes**.
UI: tableta vs. voz
**Tableta:** Zebra ET40 (3 800 EUR), Panasonic Toughbook G2 (4 200 EUR), Microsoft Surface Pro 11 en carcasa IP65 (2 800 EUR). Adecuada para troubleshooting detallado, adjuntar foto, dibujar esquemas. El ruido de línea no molesta.
**Voz (auricular Bluetooth):** Plantronics Voyager 5200 UC (260 EUR), Jabra Engage 65 (310 EUR), Apple AirPods Pro 2 en setup industrial (310 EUR + dock custom). Adecuado para operación hands-free, entorno ruidoso hasta 95 dB con active noise cancellation. La latencia STT (Speech-to-Text) es crítica — Whisper v3 large en GPU local 200–400 ms, cloud Azure Speech 250–500 ms.
En pilotos comprobamos que la **combinación** funciona mejor: tableta para interacción detallada, voz para query rápido («cómo resetear la alarma 14-021» mientras se camina hacia la máquina).
Pilot framework que no quema dinero
1. **Elija 1 (máximo 2) casos de uso** entre los 4 recomendados. Nunca «desplegamos todo a la vez». 2. **Defina un KPI medible** *antes* del arranque: horas ahorradas, reducción MTTR, tiempo de borrador, tiempo de onboarding. Sin medición baseline el informe de ROI será wishful thinking. 3. **Fase PoC de 8 semanas:** 4 semanas de integración + 4 semanas de field testing con 6–10 operarios. Sin escalado antes de completar la PoC. 4. **Puerta stop-go tras la PoC:** si los KPI no han alcanzado al menos el 50 % del objetivo, no escalar. Revise el stack o cancele el proyecto. 5. **Rollout de 6 meses** a todos los operarios + integración con sistemas existentes (MES, CMMS, ERP read-only access).
Ejemplo concreto del proveedor alemán citado: 80 horas de desperdicio en la integración salieron de que el equipo intentó conectar el copilot de IA con **9 sistemas internos** en fase PoC. En realidad 6 de los 9 resultaron innecesarios y 3 bastaron. Pero la prioridad «integrate everything first» perdió los primeros 3 meses del proyecto.
---
*Implementamos soluciones de copilot de IA en planta con PoC de 8 semanas + rollout de 6 meses. Si está considerando este tipo de despliegue, el primer workshop (3 horas) recorre los 4 casos de uso recomendados sobre su proceso concreto y descarta los que no se devolverán en un horizonte razonable.*