Pilot purgatory: por qué tus pilotos de IA nunca llegan a producción

El piloto funcionaba. La demo fue brillante. El equipo aplaudió.

Seis meses después, el proyecto duerme en una carpeta de Google Drive que nadie abre. La empresa sigue haciendo lo mismo que antes. Y alguien en dirección dice «lo de la IA no funcionó».

Esto tiene nombre: pilot purgatory. El purgatorio del piloto. Y es la respuesta más habitual a por qué un piloto de IA no llega a producción.

Un piloto de IA no llega a producción cuando se diseña para demostrar que funciona en condiciones ideales, no para sobrevivir en el entorno real de la empresa.

Según el estudio de IBM sobre retorno de la IA, solo alrededor del 16% de las iniciativas de IA alcanzan escala en toda la empresa. El resto muere en algún punto entre la demo y la operación real. No por falta de tecnología. Por falta de diseño.

Te cuento las cinco razones más comunes de por qué un piloto de IA no llega a producción, y qué hacer desde el día uno para que el tuyo no acabe en el mismo sitio.

—

1. El piloto usa datos de juguete

El primer error es el más frecuente y el más silencioso.

Montas la prueba con un Excel limpio que alguien preparó ad hoc, o con un dataset de ejemplo que venía con la herramienta. La IA funciona de maravilla. Todo va como la seda.

Llega el momento de conectar los datos reales: registros incompletos, campos con tres formatos distintos según quién los metió, nombres de clientes escritos de cuatro maneras diferentes. El modelo colapsa o devuelve resultados inútiles. El proyecto se para para «limpiar los datos» y nunca vuelve a arrancar.

En mi experiencia, los equipos que empiezan con datos reales —aunque estén sucios— descubren los problemas de calidad en la semana dos del piloto, no en el mes seis. Y pueden resolverlos antes de comprometer recursos serios.

Los datos son el suelo sobre el que construyes. Si el suelo del piloto no es el mismo que el de producción, estás construyendo sobre arena.

Lo que funciona: exige desde el día uno que el piloto use datos reales, aunque haya que anonimizarlos. El informe State of AI in the Enterprise 2026 de Deloitte sitúa la calidad de los datos como el mayor bloqueo en el 52% de las organizaciones. No eres el único. Pero los que escalan son los que lo afrontan pronto.

—

2. No hay nadie que sea el dueño

La IA es de todos y no es de nadie.

El proyecto lo lanza IT. El negocio lo pide. Operaciones debería operarlo. Legal tiene preguntas. Y el director general está «muy encima». Hay reuniones, hay entusiasmo, hay un canal de Slack.

Pero cuando llega la pregunta concreta —»¿quién decide si esto va a producción?»— hay silencio.

Sin un dueño con nombre y apellidos, con tiempo real en su agenda y con la autoridad para decir que sí o que no, el piloto avanza en círculos. Cada reunión termina con «hay que alinear más». Cada hito se retrasa. Nadie firma la decisión de escalar porque nadie tiene el mandato.

No necesitas un comité. Necesitas una persona. Alguien que defienda el proyecto en la junta, que desatranque los bloqueos con otras áreas y que tenga la agenda bloqueada para revisar métricas cada dos semanas.

Lo que funciona: antes de empezar el piloto, escribe en un documento de una página quién es el product owner interno. Nombre, responsabilidad, tiempo comprometido. Sin eso, no arranques.

—

3. El piloto vive en una isla

Funciona perfecto… mientras lo usas de forma manual, exportando un CSV, pegando el resultado en otro sitio, reenviando un correo.

El problema es que eso no es producción. Eso es un proceso manual más sofisticado.

Para que la IA genere valor real tiene que conectar con los sistemas donde vive el trabajo: el CRM, el ERP, el sistema de gestión documental, el correo, el chat del equipo. Sin esas integraciones, lo que tienes es una herramienta de consulta, no un proceso automatizado.

Y las integraciones cuestan. Cuestan tiempo de IT, cuestan licencias de conectores, cuestan semanas de desarrollo o configuración. Si no se planifican desde el inicio, aparecen como sorpresa al final, cuando ya no hay presupuesto ni energía.

En mi experiencia, los pilotos que arrancan haciendo el mapeo de integraciones necesarias en la semana uno tienen tres veces más probabilidades de llegar a producción. No porque sean más listos, sino porque saben desde el principio cuánto va a costar de verdad.

Lo que funciona: en el kick-off del piloto, haz la pregunta incómoda: ¿con qué sistemas tiene que hablar esto para que no haya intervención manual? Apúntalos. Coste, tiempo, responsable. Si no caben en el proyecto, mejor saberlo ahora.

—

4. No hay métrica de éxito definida

«Queremos que la IA nos ayude a ser más eficientes.»

Bien. ¿Cómo sabrás en tres meses si lo ha conseguido?

Sin un número concreto al que apuntar, el piloto no puede fracasar. Pero tampoco puede tener éxito. Y cuando hay que tomar la decisión de escalar o no, no hay evidencia. Solo opiniones.

El resultado más habitual: el piloto se alarga indefinidamente porque «todavía hay cosas que ajustar». O se cancela sin saber bien por qué, porque nadie puede demostrar que funcionó.

La métrica no tiene que ser complicada. Puede ser: reducir el tiempo de respuesta a clientes de 48h a 8h. O pasar de revisar 50 contratos al mes a 200 con el mismo equipo. O que el 80% de las altas de clientes nuevos se completen sin intervención manual.

Concreta, medible, con un valor de línea de base y un umbral de éxito.

Lo que funciona: antes de empezar el piloto, escribe en el mismo documento del product owner: «Este piloto habrá tenido éxito si en [fecha] conseguimos [número concreto]. El valor actual es [X].» Si no puedes rellenar esos huecos, la iniciativa no está lista para arrancar.

—

5. Nadie ha pensado en el coste de operarlo

El piloto sale gratis porque lo paga el presupuesto de innovación o un contrato de consultoría con precio cerrado.

Producción no sale gratis. Hay costes de API, de infraestructura, de mantenimiento, de revisión humana cuando el modelo falla, de actualización cuando cambia el proveedor. Y hay tiempo de alguien en la empresa para supervisar que todo funciona.

Si ese coste no está en el presupuesto del año siguiente, el proyecto no tiene futuro aunque técnicamente funcione. He visto pilotos excelentes cancelados no porque la IA fallara, sino porque nadie había presupuestado el coste de operación y en noviembre no había dinero.

El informe State of AI Agent Security 2026 de Gravitee revela que solo el 22% de las organizaciones tratan a los agentes de IA como entidades con identidad propia en su modelo de seguridad y gobierno. El resto improvisa, y la improvisación sale cara cuando ya estás en producción.

Lo que funciona: calcula el coste mensual de operación en el momento del piloto, no al final. Incluye API, infraestructura, tiempo de supervisión. Ponlo en la propuesta de escalado. Si los números no salen, mejor reformular el alcance ahora que descubrirlo después.

—

Por qué un piloto de IA no llega a producción: resumen y solución

El purgatorio del piloto no es mala suerte. Es diseño deficiente.

Un piloto bien diseñado responde a estas preguntas antes de empezar la primera semana:

• ¿Qué datos reales vamos a usar? (no preparados ad hoc, sino los datos tal como existen)
• ¿Quién es el product owner? (nombre, tiempo comprometido, autoridad para decidir)
• ¿Con qué sistemas hay que integrarse? (y cuánto cuesta cada integración)
• ¿Cuál es la métrica de éxito? (número concreto, valor de base, fecha de evaluación)
• ¿Cuánto cuesta operarlo en producción? (mensualmente, con recursos reales)

Si puedes contestar a las cinco antes de arrancar, tienes un piloto con posibilidades reales. Si no puedes, tienes una demo en busca de justificación.

La diferencia entre las empresas que escalan IA y las que acumulan pilotos no es el presupuesto ni el acceso a la tecnología. Es que las primeras tratan el piloto como la primera iteración de un producto, no como un experimento aislado.

Leer también: Preguntas clave antes de arrancar un proyecto de IA y Cómo montar el primer departamento de IA.

—

Preguntas frecuentes

¿Cuánto debería durar un piloto de IA bien diseñado? Entre 6 y 12 semanas para iniciativas de proceso. Suficiente para validar con datos reales y medir el impacto, pero no tanto como para perder el impulso o que cambie el contexto del negocio. Si a las 12 semanas no tienes evidencia suficiente para decidir, algo falla en el diseño original.

¿Hace falta tener los datos perfectamente limpios antes de empezar? No. De hecho, exigir datos perfectos antes de arrancar es otra forma de no arrancar nunca. Lo que sí hace falta es trabajar con los datos reales desde el día uno, aunque estén sucios. El piloto también sirve para descubrir qué problemas de calidad de datos hay que resolver para llegar a producción.

¿Quién debería ser el product owner de una iniciativa de IA? Alguien del negocio, no de IT. Idealmente, el responsable del proceso o área que se va a mejorar. IT da soporte técnico, pero la decisión de si el piloto aporta valor al negocio la tiene que tomar quien conoce ese negocio. Un responsable técnico como único dueño es una señal de alerta: significa que el negocio no se ha comprometido de verdad.