Cuándo matar un piloto de IA en tu empresa (y por qué casi nadie lo hace)

Tu empresa tiene tres pilotos de IA en marcha. Uno lleva cuatro meses sin pasar de la fase de pruebas. Otro funciona pero nadie lo usa. El tercero da resultados, aunque cuesta tres veces lo previsto en mantenimiento. Y aun así, cuando alguien sugiere parar uno, la respuesta del comité es siempre la misma: “vamos a darle dos meses más a ver”.

Ese “dos meses más” es la trampa más cara que hay en proyectos de IA. Porque el coste real no es lo que llevas gastado, es lo que vas a seguir gastando. Y porque el equipo que sostiene un piloto agonizante no está disponible para arrancar el siguiente, que probablemente sí funcionaría.

Matar un piloto de IA a tiempo es la decisión más rentable que un directivo puede tomar este año. Y casi nadie la toma. Te voy a explicar por qué y cómo se hace bien.

Por qué los pilotos no se cierran nunca

La razón principal no es técnica, es emocional. Quien aprobó el piloto tiene su firma en el proyecto. Quien lo construyó ha invertido horas y orgullo. El proveedor externo lo presenta cada mes con datos seleccionados que muestran progreso. Y nadie quiere ser la persona que diga “esto no va a llegar”.

A esto se suma un sesgo cognitivo bien estudiado: el coste hundido. Cuanto más has gastado en algo, menos quieres aceptar que no funciona. Es exactamente al revés de cómo deberías pensar: lo que ya gastaste no vuelve, lo único que controlas es lo que vas a gastar a partir de hoy. Pero la gente, los comités y las empresas hacen lo contrario.

Y luego está el factor político. Cerrar un piloto significa reconocer en público que la decisión inicial no era la correcta, y eso tiene coste de carrera. Es más barato a nivel personal mantenerlo abierto en zombi que cerrarlo limpiamente. Ese cálculo personal es legítimo, pero le sale carísimo a la empresa.

Las cinco señales de que un piloto está muerto y nadie lo ha enterrado

No hace falta esperar al informe trimestral. Si ves dos o más de estas señales, tu piloto ya no va a llegar a ningún sitio.

1. La métrica de éxito ha cambiado tres veces. Empezasteis midiendo horas ahorradas. Luego pasasteis a satisfacción del usuario. Luego a “casos de uso explorados”. Cada cambio de métrica es una negociación a la baja con la realidad. Si el indicador se mueve, es porque el resultado no.

2. El equipo que lo construyó ya no lo defiende, solo lo justifica. Hay una diferencia clarísima entre alguien que cree en su proyecto y alguien que está cumpliendo. El primero te trae problemas y soluciones. El segundo te trae cifras y excusas. Si tu reunión mensual del piloto se ha vuelto una sesión de reporting defensivo, el piloto ya está muerto.

3. El usuario final no lo usa cuando no hay nadie mirando. Esta es la prueba definitiva. Quita la formación, los recordatorios, los emails del responsable de producto. Mira los logs reales de uso después de un mes. Si el uso voluntario es bajo, ningún rediseño lo va a salvar. Es síntoma de que la herramienta no resuelve un problema lo bastante doloroso como para cambiar el comportamiento del equipo.

4. El coste real triplica al estimado y nadie reproyecta. Llevas más de lo presupuestado, sí. Pero lo grave no es el desvío, es que nadie está actualizando la previsión a futuro con esa nueva realidad. Si el comité sigue manejando el plan original mientras la factura es otra, no estás gestionando un proyecto, lo estás dejando deslizar.

5. La conversación cada mes es la misma. Mismas dudas. Mismas excepciones. Mismos casos de uso por explorar “el siguiente trimestre”. Si un piloto no genera aprendizaje nuevo, no está aportando información a la empresa. Y un piloto sin aprendizaje es solo gasto.

Cómo se cierra bien

Cerrar un piloto no es enviar un email diciendo “se acabó”. Es un proceso corto pero tiene que estar bien hecho, porque la próxima vez que tu empresa apruebe un piloto, el equipo va a recordar cómo se cerró el anterior.

Primero: separa la decisión del proyecto del juicio sobre las personas. El piloto no funcionó. Eso no significa que el equipo lo hiciera mal. Casi siempre el problema fue de hipótesis, no de ejecución. Hacer esa distinción explícita en la comunicación es lo que permite que la gente vuelva a proponer pilotos en el futuro sin miedo.

Segundo: extrae el aprendizaje y compártelo. Qué hipótesis se confirmó, cuál cayó, qué descubristeis del proceso interno mientras intentabais automatizarlo. Ese aprendizaje vale más que el piloto en sí, porque informa los siguientes seis meses de decisiones de IA en la empresa. Si lo guardas en un cajón, has perdido el doble.

Tercero: redirige el presupuesto inmediatamente. La peor forma de cerrar un piloto es liberar el dinero al pool general y dejar que se diluya. La buena es asignarlo de forma visible al siguiente intento, con criterio actualizado. Eso le manda a la organización el mensaje correcto: cerramos lo que no funciona para invertir mejor, no para ahorrar.

La pregunta que nadie hace en el comité

Cuando estés revisando un piloto que lleva meses dando vueltas, hay una pregunta sencilla que cambia todo: “Si este proyecto no existiera hoy, ¿lo aprobaríamos como nuevo con los datos que tenemos?”.

Si la respuesta es no, ya lo has matado mentalmente. Lo único que falta es hacerlo formal.

Cierre

La cultura de IA de tu empresa no se mide por cuántos pilotos arrancáis, se mide por cuántos cerráis a tiempo. Una empresa que cierra rápido lo que no funciona aprende cinco veces más rápido que una que mantiene tres pilotos zombis “por si acaso”. Y aprende sin gastar el doble.

El piloto malo no es el que fracasa. El piloto malo es el que se mantiene abierto cuando todos saben que ya no va a llegar. Si tienes uno así en tu empresa hoy, sabes cuál es. Cierra ese antes que abras el siguiente.