Agentes de IA en producción: por qué la mayoría de pilotos no llega

El pitch para arrancar un piloto de agente de IA es fácil. Un vendor enseña una demo, se elige un caso de uso obvio, se aprueba un presupuesto pequeño, se promete una métrica. Tres meses después, la mayoría de los pilotos siguen siendo pilotos. No fallan de forma visible; entregan algo. Tampoco llegan a producción. Se quedan estancados en un limbo de demos internas, comités de revisión y "necesitamos un poco más de tiempo".

Los datos confirman el patrón. Gartner predice que más del 40% de los proyectos de IA agéntica se cancelarán antes de finales de 2027 por costes crecientes, valor de negocio difuso o controles de riesgo insuficientes. El premio por hacerlo bien es igual de concreto: McKinsey estima que la IA agéntica podría desbloquear entre 450.000 y 650.000 millones de dólares de valor anual adicional en industrias avanzadas para 2030. La distancia entre esas dos cifras no es una brecha tecnológica. Los proyectos se atascan por cosas que ningún case study de vendor menciona: integración con el modelo de permisos existente, audit trail compatible con compliance, disrupción del workflow del operador y la pregunta de quién es dueño del sistema después del go-live.

Este artículo es la versión de la historia que no es marketing: las tres razones por las que la transición de piloto a producción se rompe, un roadmap operativo de 90 días que evita las trampas más comunes y los KPIs ejecutivos que hay que medir antes de firmar el contrato. Porque poner agentes de IA en producción es un problema de gobernanza y de propiedad operativa mucho antes que un problema de modelo.

Si todavía estás antes de la fase de piloto y necesitas el encuadre técnico, empieza por IA agéntica para operaciones industriales. Si estás comparando vendors concretos, nuestra guía de compra de AI copilots para plataformas IoT cubre los criterios de evaluación en detalle.

Qué exigen de verdad los agentes de IA en producción

Los agentes de IA en operaciones industriales son sistemas de software que planifican y ejecutan tareas operativas multipaso, como investigar alertas, redactar órdenes de trabajo o despachar comandos, interpretando el lenguaje natural del operador en vez de exigirle consultas escritas. Operan dentro del modelo de permisos de la plataforma, registran cada acción para auditoría y combinan telemetría, alertas, tickets y documentación en respuestas con citas a sus fuentes.

El IEEE describe la IA agéntica como sistemas que persiguen objetivos complejos con supervisión humana limitada pero estratégica. En un piloto, esa supervisión es una diapositiva. En producción tiene que ser una arquitectura: permisos, puertas de aprobación y un audit trail que el equipo de seguridad pueda inspeccionar de verdad.

En 2026, los agentes de IA industriales adoptan una de tres formas comerciales: un AI copilot integrado en una plataforma IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil (el Cloud Studio IoT AI Copilot, Siemens Industrial Copilot o PTC ThingWorx con IA generativa), un agente a medida construido sobre el stack cloud del cliente (típicamente AWS Bedrock o Azure OpenAI con orquestación propia) o un módulo añadido a un SCADA existente, en general la opción menos madura de las tres.

La decisión de pasar de piloto a producción rara vez va de cuál de las tres formas es técnicamente superior. Va de cuál puede sostenerse operativamente cuando el champion interno cambia de equipo y el departamento de seguridad pide ver el audit trail. Si todavía estás construyendo el caso de negocio, la pieza complementaria sobre casos de uso de IA agéntica con ROI mapea dónde están los retornos reales.

Por qué la transición de piloto a producción se rompe: tres razones

Los pilotos fallan en tres sitios concretos. No en la tecnología; en la transición.

Razón 1: el piloto se evaluó en aislamiento y producción exige integración

El piloto se aprueba para un escenario concreto: un agente que investiga alertas de un tipo de dispositivo en una planta. Se mide el tiempo ahorrado, el comité de inversión ve los números y el go-live recibe luz verde.

Producción exige integración con el resto del stack operativo. El SSO corporativo. El CMMS existente. Las puertas de aprobación de compliance. El proceso de mantenimiento de runbooks. La rotación de turnos. Cuando el piloto se construyó como demo aislada, cada una de esas integraciones cuesta semanas que el presupuesto no contempló.

Síntoma: "El piloto funcionó, pero ahora nos dicen que integrarlo con SAP lleva cuatro meses más."

Cómo evitarlo: durante el piloto, lista las ocho integraciones que producción exigirá y pide al vendor que las demuestre, aunque sea con datos sintéticos: SSO, CMMS, exportación del audit trail, identity provider, scoping multi-tenant, opción on-premise, rate limiting de API y backup y restauración. Si el vendor no puede demostrar ocho de ocho, el plan de piloto a producción ya tiene agujeros.

Razón 2: el modelo de permisos del piloto no encaja con el compliance corporativo

El piloto corrió con permisos amplios. Tres usuarios elegidos a dedo probaron el agente; podían leerlo todo y escribir sin puertas de confirmación. El piloto se sintió fluido y las métricas salieron buenas.

Producción exige el modelo de permisos corporativo: roles granulares, separación de funciones, puertas de confirmación obligatorias y audit trail conectado al SIEM. Cuando el vendor no puede demostrar cómo el agente respeta esos permisos, o los respeta de forma tan agresiva que el agente queda inutilizable, el proyecto se atasca indefinidamente en la revisión de compliance.

Síntoma: "El equipo de seguridad lleva seis semanas revisando el modelo de permisos y pide cambios que el vendor dice que no se pueden hacer."

Cómo evitarlo: involucra a compliance y seguridad desde la semana uno del piloto. No les pidas una opinión; pídeles que escriban el documento de requisitos, y que el vendor responda a ese documento por escrito antes de continuar. Marcos como el NIST AI Risk Management Framework dan a las dos partes un vocabulario común para esa conversación. Si el modelo de permisos del agente exige acceso de administrador o no tiene allow-list por tipo de dispositivo, la auditoría parará el go-live.

Razón 3: nadie es dueño del agente después del go-live

El piloto tuvo un champion: un responsable de operaciones o un líder técnico que lo empujó internamente. El go-live también lo tendrá. Pero seis meses después de producción, ¿quién mantiene los runbooks que el agente referencia? ¿Quién actualiza la allow-list cuando se añade un nuevo tipo de dispositivo? ¿Quién revisa los logs cuando el agente genera respuestas raras? ¿Quién paga la factura de inferencia del LLM?

Cuando nadie tiene esa propiedad asignada de forma explícita, el agente degrada en silencio. Los operadores notan respuestas peores, las reportan menos cada mes y, a los nueve meses, el agente está oficialmente en producción y oficialmente sin uso.

Síntoma: "El agente sigue corriendo, pero no veo a nadie del equipo usarlo desde hace tres semanas."

Cómo evitarlo: antes del go-live, asigna la propiedad operativa a una persona, no a un equipo. Esa persona dedica un porcentaje fijo de su tiempo, típicamente entre el 10% y el 20%, al mantenimiento del agente: revisión semanal de logs, actualización de runbooks, ajuste de la allow-list y seguimiento del coste de inferencia. Sin esa persona, el go-live es el día en que el proyecto empieza a morir.

El roadmap de 90 días que evita las tres trampas

El roadmap se distribuye en tres bloques de 30 días. Cada bloque termina con una puerta de continuar o parar. Si una puerta falla, no se avanza al siguiente bloque; se para y se ajusta.

Días 1 a 30: diseño y acuerdo

Semana 1: definir el caso de uso específico. No "agentes de IA en planta", sino "investigación de alertas críticas en la flota de refrigeración de la planta de Madrid". La especificidad reduce la ambigüedad.

Semana 2: involucrar a seguridad y compliance. Ellos escriben el documento de requisitos; el vendor responde por escrito. Si el vendor no puede o no quiere, ése es el final del proyecto, y es mucho más barato descubrirlo en la semana 2 que en el mes 9.

Semana 3: identificar a la persona con propiedad operativa post-go-live. Confirmar con su manager que el 10-20% de su tiempo está aprobado. Esta persona se involucra en el piloto desde el día uno, no después del go-live.

Semana 4, puerta 1: ¿tenemos caso de uso específico, documento de requisitos de seguridad respondido por escrito por el vendor y propiedad operativa asignada? Si sí, avanzar. Si no, ajustar y volver.

Días 31 a 60: piloto técnico

Semanas 5 y 6: integrar el SSO, leer la telemetría de la flota y verificar la herencia de permisos. Probar con tres a cinco operadores elegidos a dedo. Reportar tiempo ahorrado por consulta, satisfacción del operador y errores observados.

Semanas 7 y 8: añadir acciones de escritura detrás de un permiso de ejecución explícito. Puerta de confirmación obligatoria y audit trail enviado al SIEM corporativo. Validar la integración del audit trail con compliance antes de seguir.

Semana 8, puerta 2: ¿el agente respeta el modelo de permisos corporativo? ¿El audit trail llega al SIEM en un formato consumible? ¿Los operadores del piloto siguen usando el agente al final de la semana 8? Si sí, avanzar. Si no, ajustar.

Días 61 a 90: expansión y go-live

Semanas 9 y 10: expandir a entre 10 y 15 operadores de la planta piloto. Documentar los patrones de uso que emergen. Identificar los casos que el agente gestiona mal y crear runbooks de respaldo para ellos.

Semanas 11 y 12: cerrar las integraciones restantes (CMMS, identity provider, on-premise si aplica). Confirmar el SLA del vendor para incidentes post-go-live por contrato, no de palabra.

Semana 12, puerta 3: ¿el agente entrega valor medible (tiempo ahorrado, calidad de tickets, satisfacción del operador) sobre 10 o más operadores? ¿Está integrado con los ocho sistemas críticos? ¿La propiedad operativa post-go-live está activa? Si sí, go-live a producción. Si no, extender 30 días antes de declarar nada.

La puerta más importante es la 1, en la semana 4. Si llegas a ella sin documento de seguridad respondido y sin persona con propiedad operativa asignada, el proyecto fallará hacia el mes 6 independientemente de la tecnología del vendor.

KPIs ejecutivos que hay que medir (no las métricas de la demo)

El vendor te enseñará la latencia p95 del prompt, los tokens por mes y el porcentaje de prompts gestionados correctamente. Son KPIs técnicos: entradas necesarias, pero no suficientes. El informe State of AI in the Enterprise de Deloitte señala que solo una de cada cinco organizaciones declara tener un modelo maduro de gobernanza de agentes autónomos, y la disciplina de KPIs es buena parte de esa brecha de madurez.

Los KPIs ejecutivos de los agentes de IA en producción son cinco:

El operador no mide la latencia p95; mide si el agente le ahorró tiempo. El CFO no mide tokens por mes; mide el coste por usuario activo. Los KPIs técnicos son entradas del sistema. Los KPIs ejecutivos son salidas del negocio. Mide los segundos.

Las bolsas de valor justifican la disciplina. La investigación de McKinsey sobre IA agéntica y generativa en operaciones documenta reducciones de paradas no planificadas de hasta el 50% y de costes de mantenimiento de entre el 10% y el 40% en los casos de mantenimiento que sí llegan al final. Para cinco despliegues con resultados medidos, consulta agentes de IA en fabricación.

Cuándo parar el proyecto antes del go-live

Tres señales indican que llevar el agente a producción será peor que pararlo:

1. El champion interno cambia de equipo o de empresa antes de la puerta 2. Sin alguien dueño del proyecto, las decisiones se atascan. Si esto pasa, repensar antes de continuar.
2. El vendor no puede demostrar al menos seis de las ocho integraciones críticas al final del piloto técnico. Cuanto más se acerque el go-live con integraciones pendientes, mayores serán los costes sorpresa después.
3. Compliance llega a la puerta 2 con cambios de requisitos que el vendor no acepta. Es la muerte por mil compromisos: cada uno parece negociable por separado, pero la acumulación rompe el proyecto.

Parar un piloto de IA agéntica en la semana 8 cuesta una fracción de pararlo en el mes 9. La buena gestión no consiste en llevar todos los proyectos a producción. Consiste en saber cuáles parar.

Preguntas frecuentes

¿Qué porcentaje de pilotos de IA agéntica llega a producción?

Gartner predice que más del 40% de los proyectos de IA agéntica se cancelarán antes de finales de 2027 por costes crecientes, valor de negocio difuso o controles de riesgo insuficientes. Los proyectos que fallan rara vez fallan por la tecnología. Fallan por la integración con el modelo de permisos existente, el audit trail compatible con compliance, la disrupción del workflow del operador y la falta de propiedad operativa tras el go-live.

¿Cuánto cuesta un piloto de agente de IA industrial?

Como rango orientativo de mercado, los pilotos con un vendor de copilot integrado (Cloud Studio IoT, Siemens, PTC) suelen costar entre 25.000 y 80.000 euros para 90 días, incluyendo licencia, integración y soporte. Los desarrollos a medida sobre AWS Bedrock o Azure OpenAI cuestan más por el esfuerzo de ingeniería interna, con frecuencia entre 150.000 y 300.000 euros, aunque el uso del LLM en sí sea barato.

¿Qué debería medir durante un piloto de agente de IA?

Cinco KPIs ejecutivos: tasa de adopción real (porcentaje de operadores con acceso que usan el agente cada semana), coste de inferencia por usuario activo y mes, tasa de rechazo de outputs, tiempo de alerta a resolución con y sin agente en una comparación controlada, y coste de mantenimiento operativo mensual. Las métricas técnicas del vendor (latencia, tokens) son entradas; estos cinco son salidas de negocio.

¿Quién debería ser el dueño del agente de IA después del go-live?

Una persona, no un equipo. Típicamente un líder técnico o de operaciones con un 10-20% de su tiempo dedicado al mantenimiento del agente: revisión semanal de logs, actualización de runbooks, ajuste de la allow-list y seguimiento del coste de inferencia. Sin esta persona asignada de forma explícita antes del go-live, el agente degrada en silencio y acaba nominalmente en producción pero sin uso.

Del piloto a producción con el Cloud Studio IoT AI Copilot

Tres ideas que merece la pena conservar:

• Los pilotos se atascan por integración, permisos y propiedad operativa, no por la calidad del modelo.
• Un roadmap de 90 días con tres puertas de continuar o parar saca a la luz los problemas fatales en la semana 4, no en el mes 9.
• Los KPIs ejecutivos (adopción, coste por usuario, tasa de rechazo, tiempo de resolución, coste de mantenimiento) deben decidir el go-live, no las métricas de la demo.

Por eso construimos la capa agéntica dentro de la plataforma y no al lado. El Cloud Studio IoT AI Copilot es un copiloto conversacional integrado en la plataforma de Cloud Studio IoT: hablas con tus dispositivos en lenguaje natural, cada acción pasa por tool calling con permisos explícitos, cada paso queda en un audit trail y las acciones de alto impacto esperan detrás de una puerta de aprobación humana. Los requisitos de producción que matan a la mayoría de los pilotos (permisos, auditabilidad, supervisión humana) son la arquitectura nativa del Copilot, sobre una base de más de 25 años de experiencia en datos IoT de campo y más de 250.000 dispositivos conectados. Cómo esa base de datos alimenta la inteligencia es el tema de nuestro pillar sobre por qué la IA necesita el IoT.

Si quieres ver el roadmap de 90 días aplicado a tus propios datos operativos, solicita una demo del Cloud Studio IoT AI Copilot en [cloudstudioiot.com/ai](https://cloudstudioiot.com/ai).