La sala de demos está llena. Producción, vacía.
Hay un lugar al que van los proyectos de IA cuando nadie se atreve a decir que no funcionan. No es el basurero: los pilotos se ven bien, los indicadores son prometedores, las demos impresionan. Ese lugar se llama pilot purgatory, y más organizaciones de las que reconocen públicamente tienen proyectos atrapados ahí.
No es un fallo de la tecnología. Los modelos funcionan. Los datos, con algo de trabajo, están. El problema es anterior: no está claro quién va a operar esto en producción, qué pasa cuando falla, cuánto cuesta realmente escalar, ni cómo encaja en los procesos existentes.
Este artículo no trata de convencerte de que la IA no sirve. Trata de identificar por qué los proyectos de IA se quedan a medio camino y qué decisiones concretas marcan la diferencia entre un piloto que demuestra algo y un sistema que opera de verdad.
Qué es el pilot purgatory
El término pilot purgatory describe el estado en el que un proyecto de IA ha superado la fase de exploración pero no llega a convertirse en un sistema productivo. El piloto existe, tiene resultados, incluso tiene defensores internos. Y aun así permanece atrapado entre la promesa y la operación real.
No es un fenómeno nuevo. El ciclo hype-decepción-meseta de productividad que describe Gartner para las tecnologías emergentes tiene una versión específica en IA: muchos proyectos llegan al pico de expectativas como pilotos, se quedan en el valle de la desilusión sin que nadie decida si escalarlos o cancelarlos, y nunca alcanzan la rampa de consolidación.
La diferencia respecto a otras tecnologías es que en IA el piloto puede parecer muy convincente aunque el sistema no esté listo para producción. Un modelo que funciona bien en condiciones controladas puede fallar de formas inesperadas cuando enfrenta datos reales, volumen real y usuarios reales.
Las cinco razones por las que el piloto no pasa a producción
1. Los datos del piloto no representan los datos reales
La causa más frecuente y la menos visible. Durante el piloto se trabaja con un subconjunto de datos cuidadosamente seleccionado, limpiado y etiquetado. En producción, los datos llegan incompletos, en formatos distintos, con errores, fuera de plazo y sin las garantías de calidad que se asumían.
El resultado es un modelo que degrada rápidamente su rendimiento en cuanto sale del entorno controlado. La solución no es esperar a tener datos perfectos: es diseñar desde el principio con los datos reales como referencia, incluyendo sus defectos, y construir los pipelines de datos con la misma solidez de ingeniería que el propio modelo.
2. No hay propietario operativo
Esta es la razón que más proyectos mata sin que nadie la nombre. El piloto tiene patrocinador: alguien que lo impulsó, lo financió o lo defendió. Pero eso no es lo mismo que tener un propietario operativo, es decir, alguien que se responsabiliza de que el sistema funcione en producción, que monitoriza su rendimiento, que decide cuándo reentrenar el modelo y que responde cuando algo sale mal.
Cuando no hay propietario operativo, el mantenimiento no está presupuestado, los problemas no tienen dueño y la decisión de escalar se aplaza indefinidamente. El piloto sobrevive porque nadie lo cancela, no porque alguien lo haga avanzar.
Antes de terminar un piloto conviene tener respondida una pregunta: ¿quién va a operar esto el 15 de agosto a las 3 de la tarde cuando algo falle? Si la respuesta no existe, el sistema no está listo para producción.
3. El coste real de producción no estaba en el presupuesto
El coste de un piloto de IA es engañosamente bajo. Los modelos preentrenados están disponibles, la infraestructura de experimentación es barata, y el equipo técnico que hace el piloto absorbe los costes de setup como parte de la exploración.
El coste de producción es otra cosa. Incluye infraestructura de inferencia, monitorización del rendimiento del modelo, pipelines de reentrenamiento, integración con los sistemas existentes, gestión de versiones, auditoría y cumplimiento. En muchos casos, el coste total de operación de un sistema de IA en producción es entre tres y diez veces superior al coste del piloto.
Cuando ese número aparece en el presupuesto del año siguiente, muchos proyectos se frenan. La alternativa es incorporar esa estimación desde el diseño del piloto, antes de que la decisión de escalar tenga que competir con otros proyectos ya presupuestados.
4. La integración con los sistemas existentes es más compleja de lo previsto
Los pilotos de IA suelen desarrollarse en entornos relativamente aislados: una API propia, una base de datos de prueba, un flujo de datos simplificado. La integración con los sistemas productivos, los ERPs, los CRMs, los sistemas legacy o los procesos manuales que existen en la organización es donde aparece la complejidad real.
Esa complejidad no es un problema técnico en sí misma. Es un problema de alcance que no se planificó. La integración requiere tiempo de equipos que no estaban en el piloto, decisiones sobre datos que no se tomaron al principio, y a veces cambios en procesos que tienen dueños distintos al equipo de IA.
5. El gobierno del modelo no existe
Un modelo de IA en producción no es un software estático. Degrada con el tiempo a medida que los datos reales se alejan de los datos con los que fue entrenado. Necesita ser monitorizados, evaluado periódicamente y reentrenado cuando su rendimiento cae por debajo de un umbral.
El gobierno del modelo incluye definir quién decide cuándo reentrenar, con qué datos, con qué criterios de calidad y bajo qué procedimiento de aprobación. También incluye la trazabilidad: saber qué versión del modelo está en producción, qué cambió respecto a la anterior y por qué se tomó esa decisión.
Sin este gobierno, el sistema se convierte en una caja negra que nadie sabe cómo mantener y que acumula deuda técnica silenciosamente.
De la demo al sistema: qué cambia en el diseño
La diferencia entre un piloto y un sistema productivo no está en la sofisticación del modelo. Está en las decisiones de diseño que se toman desde el principio.
Un sistema productivo necesita:
- Pipelines de datos robustos que manejen la variabilidad real de los datos de producción.
- Monitorización del rendimiento del modelo con alertas y umbrales definidos.
- Procedimientos de reentrenamiento y gestión de versiones.
- Integración testada con los sistemas existentes, no simulada.
- Documentación operativa: quién hace qué, cuándo y cómo.
- Un propietario operativo con presupuesto y autoridad para tomar decisiones.
Estos elementos no son extras que se añaden al final. Son parte del diseño del sistema desde el primer día. Un piloto que no los contempla no es un prototipo de algo que va a producción: es una demostración que se queda en el laboratorio.
Cuándo tiene sentido escalar y cuándo no
No todos los proyectos de IA deberían llegar a producción. Parte del valor de un piloto bien diseñado es determinar si el problema justifica la inversión de convertir la solución en un sistema operativo.
Tiene sentido escalar cuando el problema tiene impacto real y medible, cuando los datos reales son suficientemente buenos, cuando hay un propietario operativo identificado, cuando la integración con los sistemas existentes es viable y cuando el coste total de operación está justificado por el retorno esperado.
No tiene sentido escalar cuando el problema se puede resolver con automatización más simple, cuando el volumen de datos reales no es suficiente para sostener el rendimiento del modelo, o cuando la organización no está preparada para operar un sistema de IA con los controles que requiere.
Saber cuándo no escalar es una decisión de ingeniería tan válida como saber cuándo sí. Un piloto que concluye con la recomendación de no producir ha aportado valor si esa conclusión está bien fundamentada.
Por dónde empezar si tienes un piloto atrapado
Si tienes un proyecto de IA que lleva más de seis meses en piloto sin una decisión clara de producción o cancelación, estas son las preguntas que conviene responder antes de la próxima reunión de revisión:
- ¿Quién es el propietario operativo del sistema si llega a producción?
- ¿Cuál es el coste total estimado de operación en los próximos doce meses?
- ¿Se ha validado el rendimiento del modelo con datos reales de producción?
- ¿Está mapeada la integración con los sistemas existentes y los equipos que requiere?
- ¿Existe un procedimiento definido para monitorizar y reentrenar el modelo?
Si la respuesta a más de dos de estas preguntas es negativa o no existe, el piloto no está listo para producción. No porque el modelo sea malo, sino porque el sistema que lo rodea no está construido.
Nuestras conclusiones
El pilot purgatory no es un fallo de ambición tecnológica. Es el resultado de separar la fase de experimentación de las decisiones de operación, como si construir el modelo fuera suficiente para que el sistema funcione.
Sacar un proyecto de IA del purgatorio requiere las mismas decisiones de ingeniería que cualquier sistema productivo: datos reales, propietario operativo, coste presupuestado, integración real y gobierno del modelo. La tecnología ya está madura. La parte difícil es la misma de siempre: operar sistemas complejos con fiabilidad en el mundo real.
En Irontec trabajamos con organizaciones que quieren pasar de la demo al sistema operativo. Si tienes un piloto atrapado y quieres evaluar qué falta para que llegue a producción, podemos ayudarte.
