El muro del 70%: por qué la mayoría del software hecho con IA nunca llega a producción

El 95% de los pilotos corporativos de IA generativa no genera ningún retorno medible. No es la opinión de un escéptico: es el hallazgo central de un estudio de MIT de 2025 que analizó 300 despliegues públicos de IA y entrevistó a 150 ejecutivos. En algún punto entre la demo que entusiasmó a todos y el sistema que debía operar el negocio, la gran mayoría de estos proyectos simplemente se detiene.

Cualquiera que haya intentado construir algo con IA en los últimos dos años conoce la otra mitad de esta historia: nunca fue tan fácil lograr que algo funcione. Un chatbot, un tablero, una herramienta que lee documentos y da una respuesta — una tarde con el prompt correcto hoy produce lo que antes le tomaba semanas a un equipo pequeño. Esa sensación es real. También está, según los datos, casi completamente desconectada de si eso llega a convertirse en software del que un negocio pueda depender.

El 95% de los pilotos corporativos de IA generativa no genera retorno de negocio medible. — MIT, The GenAI Divide: State of AI in Business 2025

Esta es la paradoja que vale la pena mirar de cerca: la distancia entre "tengo una idea" y "tengo una demo que funciona" se redujo casi a cero, mientras que la distancia entre "demo que funciona" y "sistema en producción" no se movió — y según algunas medidas, se hizo más grande. Cuatro estudios independientes, de MIT, Stanford, GitClear y METR, describen el mismo muro desde ángulos distintos. Ninguno se cita entre sí. Ninguno se escribió para hacer un punto sobre el hype de la IA. Leídos juntos, explican con precisión inusual por qué tantos proyectos prometedores mueren casi en el mismo punto exacto.

Lo que realmente encontró MIT

El informe de MIT no es un ataque a la inteligencia artificial. Sus autores son explícitos: la tasa de fracaso del 95% casi no tiene relación con qué modelo se usó ni con qué tan bueno era. GPT, Claude, Gemini — los pilotos que se estancaron y los pocos que escalaron muchas veces corrían sobre la misma tecnología de base.

Lo que los separó fue lo que pasó después de que la primera versión funcionara. Los pilotos que fracasaron se dieron por terminados en el momento en que produjeron una buena demo. Nadie se hizo cargo del trabajo poco glamoroso de observar cómo la gente real usaba la herramienta, corregir lo que fallaba en la primera semana de uso real, e incorporar ese aprendizaje al producto cada semana — no cada trimestre. Las herramientas que sí pasaron de piloto a producción quedaron integradas al trabajo diario de alguien, con un dueño real responsable de que siguiera funcionando, en vez de quedar corriendo sola como proyecto paralelo. MIT llama a esto la "brecha de aprendizaje": la mayoría de las herramientas de IA — y la mayoría de los equipos alrededor de ellas — simplemente no están armadas para retener el aprendizaje y mejorar con el tiempo.

En otras palabras, lo difícil nunca fue lograr que un modelo diera una buena respuesta una vez. Fue construir la maquinaria poco vistosa — responsabilidad, ciclos de retroalimentación, mantenimiento — que la sigue dando buena en el tercer mes, bajo condiciones que nadie diseñó el primer día. Esa maquinaria nunca aparece en una demo. Solo se hace visible cuando algo ya está corriendo de verdad.

Por qué el código mismo empieza a pudrirse

Parte de esa maquinaria es el código, y aquí el dato se vuelve más específico — y más incómodo para cualquiera que haya visto a un asistente de IA escribir en segundos lo que antes tomaba una hora.

GitClear, una empresa que analiza el historial de código de cientos de millones de líneas de commits, rastreó qué pasó realmente con las bases de código a medida que los asistentes de IA se volvieron comunes. El patrón es consistente, y no es sutil.

*porcentaje de código duplicado medido entre 2021 y 2024.

Nada de esto se nota el primer día. Una función construida con un asistente de IA puede verse — y funcionar — exactamente igual que una escrita a mano, por un tiempo. Lo que se acumula es deuda: más lógica duplicada, menos reestructuración, más código que hay que volver a tocar casi de inmediato. Es el equivalente en software a levantar un edificio rápido porque nadie revisa el cableado detrás de las paredes. Se mantiene en pie. Funciona, por un tiempo. Y después se vuelve caro cambiar cualquier cosa sin romper otra — justo en el momento en que la mayoría de los "pilotos de IA" deberían graduarse a sistemas de los que dependen clientes reales.

La confianza que no se ganó

El segundo dato incómodo es sobre seguridad, y viene de un estudio de Stanford que se sostiene bien desde que los investigadores Neil Perry, Megha Srivastava, Deepak Kumar y Dan Boneh lo presentaron en la conferencia ACM sobre Seguridad Informática y de Comunicaciones en 2023. Hicieron un estudio controlado pidiendo a desarrolladores escribir código para tareas sensibles en seguridad — del tipo que interviene en casi todo lo que toca datos de usuarios, pagos o inicios de sesión — con y sin un asistente de IA.

Los desarrolladores que usaron el asistente escribieron código con notablemente más vulnerabilidades, sobre todo en inyección SQL y cifrado — dos de las formas más comunes en que los sistemas reales son vulnerados. Eso solo sería un costo aceptable si la gente supiera que debe revisar el resultado dos veces. No lo sabían: los mismos desarrolladores que escribieron código menos seguro estaban también más convencidos de que su código era seguro. El asistente no solo introdujo más riesgo; también apagó en silencio el instinto de ir a buscarlo.

Esto importa más que un hallazgo académico aislado porque coincide casi exactamente con el punto donde se atascan quienes no son técnicos. Autenticación, cifrado, pagos y control de acceso casi nunca son visibles en una demo — nadie pide ver tus defensas contra inyección SQL antes de decir "esto se ve muy bien". Se vuelven visibles en el momento en que hay dinero real, clientes reales o reguladores reales de por medio — justo el momento en que un proyecto intenta cruzar de piloto a producción.

La velocidad que no es real

El estudio más contraintuitivo es también el más reciente. En julio de 2025, el grupo de investigación sin fines de lucro METR hizo un ensayo controlado y aleatorizado con desarrolladores experimentados de código abierto — personas con un promedio de cinco años trabajando en los proyectos específicos que usaron — completando tareas reales sobre proyectos maduros y reales, la mitad del tiempo con herramientas de IA y la otra mitad sin ellas.

Los desarrolladores fueron, en promedio, 19% más lentos al usar herramientas de IA. No más rápidos: más lentos. Antes del estudio, esos mismos desarrolladores habían predicho que la IA los haría un 24% más rápidos. Después de terminar las tareas — después de vivir en carne propia la lentitud —, seguían creyendo que la IA los había hecho casi un 20% más rápidos. La distancia entre lo que realmente pasó y lo que la gente estaba segura que había pasado fue casi total.

Esto no significa que las herramientas de IA para programar sean inútiles — las mismas herramientas sí aceleran tareas cortas, nuevas y de poco contexto, que es exactamente lo que es la mayoría de las demos. El resultado de METR es específico de otra cosa: sistemas maduros, reales, que ya están corriendo — el tipo de sistema en el que todo piloto exitoso eventualmente se tiene que convertir. Lograr que un asistente de IA produzca una primera versión impresionante e integrar ese resultado en algo que tiene que seguir funcionando no son la misma habilidad. La segunda es invisible hasta que ya pasaste el punto en el que dar marcha atrás sale caro.

Cómo se ve esto si tú no eres quien escribe el código

Ninguno de los estudios anteriores requiere saber leer código para entender su consecuencia. Si eres la persona con la idea y el presupuesto, no quien está frente al teclado, así se suele sentir el muro desde afuera: la primera versión llega rápido y se ve casi terminada. Después, cada pedido pequeño — "solo agrega un login", "solo conéctalo a pagos", "solo hazlo aguantar más usuarios" — empieza a tomar más tiempo que el anterior, no menos. Algo que ayer funcionaba se rompe cuando sale una función nueva. Nadie logra explicar bien por qué un "cambio simple" tomó tres semanas.

Eso no es mala suerte, y casi nunca es un mal desarrollador tampoco. Es la deuda de la sección anterior venciendo, sobre un sistema que nadie vigilaba como el 5% exitoso de MIT vigila el suyo. Lo frustrante es que es invisible hasta el momento exacto en que deja de serlo — y por eso tanta gente capaz, con buen capital, concluye equivocadamente que el problema fue la idea.

Qué hace distinto el otro 5%

Nada de esto significa que el 5% que MIT encontró extrayendo valor real tuvo suerte, o simplemente contrató mejores ingenieros. En los casos exitosos aparece un patrón consistente: la herramienta se colocó dentro de un flujo de trabajo ya existente, con un dueño específico y responsable, en vez de soltarla como un asistente genérico que cada quien debía descubrir por su cuenta. Salió primero en una versión acotada y bien definida, no ambiciosa. Y siguió cambiando — cada semana, no cada trimestre — según lo que realmente pasaba cuando gente real la usaba, no según lo que aplaudía una audiencia de demo.

Eso describe una disciplina, no una elección de tecnología. Y no por casualidad, describe exactamente el trabajo poco vistoso de la segunda mitad que una demo nunca tiene que hacer: la responsabilidad, la iteración, el endurecimiento, las partes que no caben en un video de cinco minutos.

El muro no es la tecnología. Es todo lo que viene después de la demo.

Puestos uno al lado del otro, estos cuatro estudios dibujan una sola forma. La IA hizo el primer 70% de construir algo dramáticamente más fácil y rápido de lo que fue jamás. No hizo nada — podría decirse que complicó un poco las cosas — con el 30% restante: la parte donde el código tiene que seguir siendo mantenible, la seguridad tiene que aguantar el uso real, las ganancias de velocidad tienen que sobrevivir al contacto con un sistema real, y alguien tiene que hacerse cargo de lo que pasa después de que el aplauso por la demo se apaga.

Ese último 30% nunca fue la parte emocionante. Nunca iba a caber en un tuit de lanzamiento. Pero, según cada medida de estos datos, es toda la diferencia entre una demo que impresiona a una sala y un software del que un negocio realmente puede depender.