El piloto no fracasa al final. Fracasa en la primera reunión.

Serie «Entender la IA», nota 8 de 12. La nota 6 dio el orden de los pasos y la 7 puso precio a cada uno. Esta explica qué pasa cuando no se siguen, con lo que han medido quienes han estudiado cientos de proyectos fallidos.

Jueves, 17:30, un grupo hotelero con sede en Lucerna. El consejo revisa el proyecto de IA que aprobó hace catorce meses. Hubo un piloto en un hotel, con un asistente que respondía a los huéspedes por chat. El informe de entonces hablaba de un 92 % de satisfacción. Desde entonces se ha hecho un segundo piloto en otro hotel, se ha cambiado de proveedor una vez y se ha contratado a una persona para «coordinar la IA». No hay ningún hotel en el que el sistema funcione en producción. El director general propone un tercer piloto, «esta vez con agentes». El consejero que lleva las finanzas pregunta cuánto se ha gastado. Nadie tiene la cifra a mano.

La escena es imaginaria. El patrón, el piloto que se encadena con otro piloto, se repite en tantas empresas que tiene estudios dedicados. En esta nota le doy las cifras, las cinco causas que esos estudios encuentran una y otra vez, los síntomas que un consejo puede ver sin entender de tecnología y la salida. Si ha leído las notas anteriores, reconocerá cada causa: es el paso que se saltó.

Un piloto que no tiene fecha de producción no es un piloto. Es una demostración cara que se renueva cada año.

Las cifras.

En agosto de 2024, la corporación RAND publicó un informe basado en 65 entrevistas con científicos de datos e ingenieros con al menos cinco años de experiencia en proyectos de IA. Su punto de partida era una estimación que recoge con cautela: según algunas estimaciones, más del 80 % de los proyectos de IA fracasan, el doble que los proyectos de tecnología que no usan IA. Un año después, en agosto de 2025, el informe del proyecto NANDA del MIT que cité en la nota 6 lo midió desde otro ángulo: el 95 % de los pilotos de IA generativa no había producido un impacto medible en la cuenta de resultados. Y Gartner, en junio de 2025, previó que más del 40 % de los proyectos de agentes se cancelarían antes de finales de 2027.

Son tres medidas distintas de lo mismo, y conviene leerlas con cuidado: «fracasar» significa cosas diferentes en cada una, y ninguna es un experimento controlado. Pero la conclusión que comparten no deja lugar a dudas. Lo normal, en 2026, es que un proyecto de IA no llegue a producción. Si el suyo llega, no será por la tecnología. Será por haber evitado cinco cosas.

Causa 1. Nadie entendió el problema.

Es la primera que RAND encuentra y la que más veo. El proyecto empieza por la tecnología, «hagamos algo con IA», y busca después un problema al que aplicarla. O empieza por un problema mal entendido: la dirección quiere reducir las llamadas al soporte, el equipo técnico construye un asistente para responderlas más rápido, y nadie se dio cuenta de que las llamadas existían porque la factura era confusa. Un asistente que explica muy bien una factura confusa no reduce las llamadas. La arregla una factura clara, que es software de toda la vida, o papel.

El síntoma, desde la dirección: nadie sabe decir, en una frase, qué número tiene que cambiar y cuánto. Si la respuesta a «¿qué medimos?» es «la satisfacción» o «la eficiencia», el problema no está entendido. En la encuesta de IBM a 2000 consejeros delegados de mayo de 2025, el 64 % reconocía haber invertido en tecnología antes de entender bien su valor, por miedo a quedarse atrás. Esa es la causa 1 vista desde arriba.

Causa 2. No había datos, o eran malos.

La segunda causa de RAND es la falta de los datos necesarios para entrenar o alimentar el sistema. En la IA generativa de hoy casi nunca hay que entrenar nada, pero sí hay que darle al modelo los documentos correctos, y aquí vuelve el 3 % de la Harvard Business Review de la nota 6: la mayoría de las empresas no tiene sus datos en condiciones. El asistente del hotel de Lucerna respondía con la política de cancelación de 2022 porque era la que alguien subió. Cuando un huésped se quejó, el equipo culpó al modelo.

El síntoma: el proveedor pide los documentos y la empresa tarda semanas en reunirlos, o entrega siete versiones. El paso 2 de la nota 6 no se hizo, y ningún modelo lo hace por usted.

Causa 3. Se construyó la tecnología y no la infraestructura.

RAND lo describe como centrarse en la tecnología más reciente en vez de en lo que rodea al modelo: la conexión con los sistemas de la empresa, el registro, la gestión de versiones, el mantenimiento. Es la partida 6 de la nota 7, la que nadie presupuesta. El piloto funcionaba en el portátil del proveedor; producción exigía que hablara con el sistema de reservas, que guardara un rastro de cada respuesta y que alguien lo mantuviera. Eso era otro proyecto, y nadie lo había aprobado.

El síntoma: la demostración es impresionante y la pregunta «¿cómo se conecta con nuestro sistema de reservas?» recibe un «eso se ve en la siguiente fase». La siguiente fase es el proyecto de verdad. El piloto era la parte fácil.

Causa 4. El problema era demasiado difícil para la IA de hoy.

La cuarta causa de RAND es la más incómoda: hay problemas que la IA actual no resuelve, y las organizaciones los eligen porque son los más atractivos. Recordará la frontera dentada de la nota 4 y el horizonte de una hora de la nota 5. Un asistente que responde preguntas frecuentes de un hotel está dentro de la frontera. Uno que negocia con un huésped una compensación por una habitación con ruido, aplicando criterio, política y tono, está fuera. El piloto de Lucerna medía la satisfacción en el primer tipo de conversación y fracasaba en silencio en el segundo, donde los huéspedes acababan llamando a recepción.

El síntoma: la tarea elegida es la que más ilusión hace, no la que más se repite. Y el 92 % de satisfacción no dice sobre qué conversaciones se midió.

Causa 5. La organización no cambió.

La quinta causa, que RAND enuncia como la falta de una infraestructura de personas y procesos, es la que explica la mayor parte de los pilotos que técnicamente funcionaban. El sistema está bien; nadie lo usa, o se usa sin confiar en él, o se usa y nadie revisa. Es la adopción del 50 % de la cuenta de la nota 7, la que convertía seis meses de recuperación en trece. El caso de Klarna que conté en la nota 4 es la versión más visible: la tecnología hacía su parte, y la empresa descubrió al año siguiente que había quitado a las personas de donde hacían falta.

El síntoma: el proyecto tiene un responsable técnico y no tiene un responsable de negocio con el número en su objetivo anual. Cuando el piloto termina, el responsable técnico pasa al siguiente piloto, y el proceso vuelve a hacerse como antes.

La trampa del piloto eterno.

Hay una sexta causa que RAND no lista porque no es una causa técnica, y que yo pongo la primera: el piloto no tenía fecha de producción. Un piloto es un experimento con una pregunta, un plazo y una decisión al final: pasa a producción, se cambia o se cierra. Un piloto sin esas tres cosas es un lugar cómodo donde una organización puede decir que «está en IA» sin arriesgar nada, y donde un proveedor puede facturar fases. Catorce meses y tres pilotos son el síntoma completo.

La salida es mecánica y está en la nota 6: un proceso con un número que hoy es malo, cincuenta casos de oro, modo sombra con fecha de fin, revisión por tramos y un responsable de negocio. El modo sombra es el piloto bien hecho: tiene pregunta («¿acierta en cuántos de cada cien?»), tiene plazo («cuatro semanas») y tiene decisión («si acierta más del 90 % en lo seguro y manda a personas lo dudoso, se enciende el 1 del mes»). No es más caro que un piloto. Es un piloto que termina.

• Un número antes que una tecnología. Si no se puede decir qué cifra cambia y cuánto, no se aprueba.
• Documentos antes que demostración. Hasta que el archivo esté limpio, cualquier demostración mide al proveedor, no a su empresa.
• Producción desde el primer día. La conexión con sus sistemas, el registro y el mantenimiento se presupuestan en la propuesta, no «en la siguiente fase».
• Dentro de la frontera. El proceso más repetido y aburrido, no el más vistoso. Lo vistoso llega después, con lo aprendido.
• Un responsable con el número en su objetivo. De negocio, no técnico. Con autoridad para cambiar cómo trabaja su equipo.
• Fecha y decisión. Todo piloto termina en una de tres palabras: encender, cambiar o cerrar. Y la fecha está escrita antes de empezar.

1. Hoy

   Pida la cifra que nadie tenía a mano

   Cuánto se ha gastado en IA en los últimos dos años, incluidos licencias, consultoría y las horas internas. Compárelo con lo que está en producción.

2. Esta semana

   Haga la prueba de la frase

   A cada proyecto en curso: qué número cambia, cuánto y para cuándo. Lo que no quepa en una frase, se detiene hasta que quepa.

3. Este mes

   Convierta cada piloto en un modo sombra con fecha

   Cuatro semanas, cincuenta casos, un umbral de acierto y una de tres decisiones al final.

4. Este mes

   Nombre a un responsable de negocio por proceso

   Con el número en su objetivo anual. El responsable técnico ayuda; no decide.

Cómo lo planteo yo.

No hago pilotos. Hago modos sombra de cuatro semanas, con el número escrito antes y la decisión fijada al final, y el proyecto incluye desde el primer día la conexión, el registro y el mantenimiento, porque sin ellos no hay producción, hay una demostración. Cuando una empresa me enseña su tercer piloto, lo primero que pido es la cifra del gasto. Casi siempre, con esa cifra, el primer proceso de producción ya estaría pagado dos veces.

Piense en el último piloto de su empresa, de IA o de cualquier otra cosa. ¿Alguien escribió antes de empezar qué número tenía que salir para seguir adelante? ¿Y alguien recuerda cuál era?

Si la respuesta es no, quizá el piloto no fracasó. Quizá nunca tuvo forma de acertar. Lo inquietante es que esa decisión se tomó en la primera reunión, y casi nadie recuerda haberla tomado.

Siguiente nota: la ley. Qué exige a su empresa el Reglamento europeo de IA, qué cambia en Suiza, qué dice la protección de datos sobre pegar un informe en un asistente y las fechas que de verdad le afectan, sin alarma y sin asesoría jurídica.