Pilotos perpetuos, la forma más cara de no adoptar IA

La mayoría de organizaciones no fracasa en la IA por elegir mal la herramienta. Fracasa por no decidir nunca. Lanzan un piloto, luego otro, y otro más. Ninguno escala, ninguno se cierra formalmente, y el presupuesto se agota en una «exploración» que se prolonga sin fin.

El piloto sin criterio de salida es una decisión aplazada que cuesta dinero cada trimestre. Y antes de arrancar uno, hay que saber qué tendría que pasar para escalarlo, qué para iterarlo y qué para cerrarlo.

El destino por defecto

Solo el 16 % de las organizaciones ha escalado la IA a nivel de empresa, y apenas una de cada cuatro iniciativas ha dado el retorno esperado. El piloto que no termina no es la excepción: es hacia donde tiende el sistema cuando nadie lo empuja en otra dirección.

El coste rara vez aparece en una línea del presupuesto. Cada piloto consume atención del comité, un gasto pequeño pero recurrente y, sobre todo, capacidad de la organización para prestar atención. Cinco pilotos abiertos a la vez no suman aprendizaje; suman fatiga. La sensación de movimiento sustituye al avance real.

Por qué no terminan

Un piloto no se cierra por las mismas razones por las que no se decide nada incómodo en una organización.

No se fijó un criterio de éxito antes de empezar, así que no hay forma de saber si ha funcionado. Cuando no hay umbral, el «éxito» se redefine cada trimestre para justificar que siga abierto. Y cerrar tiene un coste político que nadie quiere pagar: matar un proyecto en el que la dirección invirtió capital y entusiasmo se parece demasiado a admitir un error. Falta, casi siempre, una fecha en la que el piloto tenga que rendir cuentas.

El resultado es un limbo cómodo. El piloto sigue vivo, nadie se equivoca y nadie decide.

Las tres decisiones

La diferencia entre un piloto que decide y uno que se eterniza se establece antes de la primera línea de código, y se reduce a tres compromisos.

El primero es una métrica de éxito observable: algo medible, como el tiempo de procesamiento que baja de una cifra a otra o los errores de un tipo concreto que caen un porcentaje determinado, no un vago «el equipo está contento». El segundo es un umbral de decisión: escalar si supera cierto valor, iterar si queda en una franja intermedia, cerrar si no llega, definido antes de que nadie esté enamorado del resultado. Y el tercero es una fecha límite en el calendario: noventa días, seis meses, lo que corresponda al caso, pero una fecha real y no «cuando esté maduro».

Sin estos tres compromisos, el piloto deja de ser un experimento y se convierte en un gasto sin fecha de revisión.

Escalar, iterar o cerrar

Cumplida la fecha, solo hay tres salidas honestas, y cada una tiene una forma reconocible.

Escalar no es «seguir, pero con más gente». Implica un plan de despliegue a doce meses en lugar de a doce semanas, mover el presupuesto del bolsillo del piloto al de operaciones y pasar el proyecto del equipo experimental al productivo. Cambia incluso la métrica: ya no se mide si «funciona», sino qué parte de la plantilla lo usa y para qué.

Iterar es una segunda vuelta con hipótesis nueva, no un «vamos a seguir probando» disfrazado. Exige un diagnóstico explícito de qué falló y qué hay que cambiar, y un plazo y un criterio nuevos. Como regla, dos iteraciones como máximo antes de escalar o cerrar; a la tercera, el problema ya no es el piloto.

Cerrar bien deja aprendizaje detrás. Un análisis honesto de qué hipótesis era falsa, qué herramienta no encajaba o qué proceso había que rediseñar antes de automatizar nada. Los recursos liberados se reasignan, no se evaporan. Lejos de ser un fracaso, cerrar bien un piloto es la decisión que existía para tomar.

El piloto perpetuo como refugio

Hay un caso peor, y es cuando el piloto eterno funciona exactamente como se pretende. Cuando escalar exigiría cambios de proceso, inversión grande o decisiones sobre personas que la dirección no quiere asumir, el piloto perpetuo se convierte en refugio: permite decir que «se está trabajando en IA» sin cargar con el coste de adoptarla de verdad.

El síntoma es fácil de reconocer. Cada trimestre, el mismo panel de métricas, las mismas conclusiones y ninguna decisión. La salida es de gobernanza, no técnica: un comité con el mandato explícito de cerrar o escalar al menos un piloto por trimestre. Obligar a decidir es la única forma de romper el limbo.

Decidir es el trabajo

La promesa de la IA no está en el experimento, sino en lo que la organización hace con lo que aprende. Un piloto que nunca decide es más caro que uno que se cierra rápido, porque consume lo más escaso que tiene una organización: su atención y su credibilidad interna.

La pregunta útil antes de aprobar el próximo piloto no es «¿qué queremos probar?». Es «¿qué vamos a hacer con el resultado, y para cuándo?».

Referencias:

• IBM 2025 CEO Study — CEOs double down on AI