(1/3) El 95% de los pilotos de GenAI no da retorno. Y los modelos no eran el problema.

La cifra de IA más citada del último año es una tasa de fracaso: el 95% de los pilotos de GenAI en empresas no genera retorno medible. Esa estadística la he visto en todas partes — en presentaciones para el consejo, en hilos apocalípticos de LinkedIn, en memorandos de congelación de presupuesto — y casi nadie de los que la citan ha leído qué mide. Porque bien leída, la cifra absuelve a la tecnología. Los pilotos no mueren en el modelo. Mueren en el despliegue, dentro de entornos que la demo nunca conoció.

Llevo dos décadas en el lado de operaciones del software — CI/CD en empresas grandes, respuesta a incidentes, el trabajo de fontanería que nadie ve pero que decide si algo llega a producción o se queda pudriéndose en staging. He estado en más de una reunión en la que se entierra un piloto, y la causa de la muerte nunca es «el modelo no era lo bastante bueno». Es una revisión de accesos que tardó once semanas. Es el responsable de un proceso al que nadie llegó a pedirle que cambiara ese proceso. Este artículo va de lo que el 95% dice en realidad, y de por qué la respuesta del mercado ha sido un patrón de contratación, no un modelo mejor.

Qué midió el MIT — y qué recortó el titular

La cifra sale de The GenAI Divide: State of AI in Business 2025, publicado por el Project NANDA del MIT en julio de 2025: una revisión de más de 300 iniciativas de IA divulgadas públicamente, 52 entrevistas estructuradas y 153 encuestas a directivos, contra un gasto empresarial en GenAI estimado en 30.000–40.000 millones de dólares. El hallazgo: el 95% de los pilotos estudiados no produjo ningún impacto medible en la cuenta de resultados dentro de la ventana del estudio. El otro 5% estaba extrayendo millones.

El titular omite dos cosas. La primera: «sin impacto medible en el P&L todavía» no es «la tecnología ha fracasado» — más de una categoría honesta de IT corporativo sacaría números feos en un examen de P&L a seis meses. La segunda, y más grave para el uso que se le da a la cifra: el diagnóstico del propio informe no es la capacidad del modelo. Los autores apuntan a la ausencia de aprendizaje, integración y adaptación al contexto — herramientas que nunca absorbieron el contexto de la organización, procesos que nunca absorbieron la herramienta. El informe no dice que la IA fracasó. Dice que fracasó el despliegue. Quien cita el 95% para argumentar que los modelos no están listos está citando un estudio que argumenta lo contrario.

El piloto muere al cruzar a tu entorno

La brecha entre demo y producción no es una metáfora; es una lista que se puede detallar. El piloto corrió sobre un dataset escogido a dedo, con un token de administrador y un usuario que quería que funcionara. Producción significa:

• Identidad y accesos. SSO, cuentas de servicio de mínimo privilegio, una revisión de IAM con cola de espera. El agente que «solo necesita acceso de lectura» lo necesita a cuatro sistemas con tres dueños distintos.
• Los datos tal y como son, no como los pinta la demo. Nada de exports limpios: el CRM con una década de deriva de esquema, el warehouse donde la tabla de referencia es fiable todos los días excepto los lunes.
• APIs que nunca se diseñaron para que las maneje software. Sin idempotencia, sin rate limits sensatos, con mensajes de error escritos para un humano que puede encogerse de hombros.
• Un modo de fallo que alguien tiene que asumir. El equipo de guardia tiene que absorber una clase nueva de incidente antes de que ocurra el primero, no después.
• Un proceso con un humano dentro que a partir de ahora tiene que trabajar distinto — y que se enteró del piloto en el mismo correo que anunciaba que ya estaba en producción.

Ninguno de esos puntos es capacidad del modelo. Todos son trabajo de ingeniería y de organización, y todos son invisibles en la demo. El 5% que cruzó la brecha del MIT no tenía modelos mejores; los casos de éxito del informe comparten integración profunda y procesos adaptados: se trabajaron esa lista entera.

Esta película ya la vimos: DevOps también fue una compra de herramientas

Hacia 2015 vi a empresas «adoptar DevOps» comprando la cadena de herramientas. Licencias de Jenkins, un repositorio de artefactos, un dashboard que gustaba al CFO. Dieciocho meses después la cadencia de releases no se había movido, y la retrospectiva culpaba a las herramientas. Las compañías que consiguieron el resultado habían hecho algo estructuralmente distinto: pusieron ingenieros dentro del flujo de entrega con mandato para cambiar el proceso, no solo para instalar software al lado.

Cambia los sustantivos y es la historia de este año. Un piloto de GenAI comprado como herramienta e instalado junto al proceso produce una demo. La misma capacidad, desplegada por alguien incrustado en el proceso con permiso para recablearlo, produce una línea en el P&L. La tecnología no era lo que separaba ambos casos hace una década, y tampoco lo es ahora.

El mercado ya lo ha descontado: la contratación de FDE creció un 1.165% en un año

Mientras el 95% circulaba como prueba del fracaso de la IA, las compañías que venden IA lo estaban leyendo bien y contratando en consecuencia. Los puestos de forward deployed engineer crecieron un 1.165% interanual de cara a 2026, según los datos de colocaciones de Live Data Technologies — el análisis de 1.000 ofertas de FDE de Perspective AI apunta a la misma tendencia, con las ofertas subiendo en torno a un 800% en un tramo de nueve meses de 2025. Palantir acuñó el rol; OpenAI y Anthropic lo convirtieron en su motor de ingresos enterprise; y el 59% de las compañías que hoy contratan FDEs va de Seed a Series A — la ola no es un lujo de los grandes laboratorios, es la capa de aplicación copiando lo que funcionó.

Antes de apoyarme en esta cifra, una declaración de intereses: desplegar ingenieros así es mi negocio, así que rebaja mi entusiasmo todo lo que haga falta — y después mira los datos de contratación, que no son míos. Un FDE es la lista de despliegue de dos secciones más arriba convertida en puesto de trabajo: un ingeniero destacado dentro del entorno del cliente, respaldado por una organización, con una misión acotada y un final definido. Ya he escrito sobre por qué la doctrina importa más que el título — forward, respaldado, con misión acotada. El punto relevante aquí es más simple: cuando el cuello de botella pasó de construir modelos a desplegarlos, los laboratorios no respondieron con un whitepaper. Respondieron contratando, a ritmos de crecimiento de cuatro cifras. Los patrones de contratación son la señal más honesta que produce un mercado, porque cuestan dinero.

Lo que el 95% no te autoriza a concluir

Ser honesto obliga a mirar en las dos direcciones, así que van dos concesiones. Si tu caso de uso está acotado — datos limpios, un solo sistema, un proceso que controlas de punta a punta — lo correcto es que tu propio equipo integre una API, y contratar especialistas en despliegue sería teatro. Y el propio 95% merece escepticismo en la otra dirección: una ventana de seis meses para exigir impacto medible en el P&L es un listón que muchas tecnologías maduras tampoco superarían. Una parte de esos pilotos «fracasados» seguirá madurando en silencio hasta convertirse en los éxitos del año que viene. La estadística es la foto de una brecha, no el veredicto sobre una tecnología — ni en un sentido ni en el otro.

Lo que sí te autoriza: si tu piloto lleva dos trimestres «a dos semanas de producción», el ingrediente que falta casi seguro no es un modelo mejor, y esperar a la próxima versión no arregla una cola de IAM.

Qué haría yo este trimestre con el presupuesto de un piloto

1. Elige un proceso con línea propia en el P&L. Ni una plataforma, ni una «capa de habilitación de IA» — un proceso cuyo éxito aparece en un número que alguien ya reporta.
2. Pon un ingeniero dentro del proceso, tuyo o incrustado desde fuera, con mandato explícito para cambiar el proceso — no solo para cablear la API.
3. Dale al piloto restricciones de producción desde la primera semana. IAM real, datos reales, un responsable con nombre en la guardia. Un piloto que corre con token de administrador no es un piloto; es el ensayo de una obra que nunca se estrenará.
4. Escribe la salida en el documento de arranque. La métrica de adopción que significa «escálalo» y la fecha en que la leerás. Un despliegue sin final definido es la manera en que un piloto acaba cogiendo polvo en un rincón.
5. Mátalo por la métrica, no por las sensaciones. El 95% está lleno de pilotos que nunca se midieron, lo que significa que nunca se desplegaron de verdad.

El resto de la serie baja a lo concreto: qué contiene de verdad la semana de un forward deployed engineer, y la economía del modelo frente al staff augmentation clásico.

El 95% no es un veredicto sobre la IA. Es la factura por tratar el despliegue como una nota al pie — y el mercado ya la está pagando: cada nueva contratación de un FDE es un plazo más de esa factura. Si el proceso que necesitas llevar a producción está esperando a ese tipo de ingeniero, ese es el rol que desplegamos.