Por qué fracasan los proyectos de IA en las pymes

Introducción

Hay una cifra que se ha repetido tanto en el último año que ha dejado de discutirse: el 95 % de los proyectos de inteligencia artificial fracasan. Aparece en presentaciones comerciales, en artículos de prensa y, con cierta ironía, tanto en boca de quien quiere vender un servicio de IA como de quien quiere convencer a alguien de que no lo contrate.

Merece la pena detenerse en ella, porque el dato es más frágil de lo que su popularidad sugiere y porque lo que sí sabemos sobre por qué fracasan estos proyectos es bastante más útil que el titular.

Este artículo hace dos cosas. Primero, mirar de dónde salen las cifras que circulan y qué miden exactamente. Y después, ir a lo que de verdad importa, que es qué hace que un proyecto concreto en una empresa concreta acabe en nada, y qué se puede hacer distinto.

De dónde sale el 95 %

La cifra procede de un informe publicado en 2025 por el proyecto NANDA del Instituto Tecnológico de Massachusetts, titulado The GenAI Divide: State of AI in Business 2025. Su conclusión más citada es que el 95 % de los pilotos empresariales de IA generativa no producen retorno medible.

Antes de usarlo como argumento conviene saber cinco cosas sobre él.

Se autodenomina preliminar. El propio documento se presenta como hallazgos preliminares, no como investigación revisada por pares ni respaldada institucionalmente. La atribución periodística al MIT, sin más matices, le ha dado un peso que sus autores no reclamaron.

La muestra es pequeña y no aleatoria. El trabajo combina una revisión de más de trescientas iniciativas divulgadas públicamente, cincuenta y dos entrevistas estructuradas y ciento cincuenta y tres respuestas de directivos recogidas en cuatro congresos sectoriales entre enero y junio de 2025. Preguntar en congresos a quien asiste a congresos no produce una muestra representativa del tejido empresarial.

Mide pilotos, no proyectos. No es lo mismo. Un piloto es, por definición, un experimento, y una parte de los experimentos tiene que salir mal para que el método sirva de algo. Contar pilotos fallidos y presentarlo como tasa de fracaso empresarial mezcla dos cosas distintas.

El listón de éxito es exigente y estrecho. Exige despliegue más allá del piloto, con indicadores medibles y retorno constatado a los seis meses. Con ese criterio quedan fuera cosas que cualquier empresa consideraría un éxito: reducciones de coste difusas, mejoras de calidad, tiempos de respuesta más cortos o simplemente aprender que un camino no llevaba a ninguna parte. Con umbrales menos estrictos, la cifra se acerca más al 75 % que al 95 %.

Quien lo publica no es neutral. El proyecto tiene interés comercial en el tipo de solución que el informe recomienda, lo que no invalida el trabajo pero sí obliga a leerlo con la misma cautela con la que se leería un estudio de mercado encargado por un fabricante.

Nada de esto significa que el dato sea inventado ni que los proyectos de IA salgan bien. Significa que el 95 % no mide lo que la mayoría de la gente cree que mide cuando lo cita.

El estudio que conviene leer

Existe un trabajo bastante más sólido y mucho menos citado, probablemente porque no cabe en un titular. Lo publicó la corporación RAND en 2024, y se basa en sesenta y cinco entrevistas semiestructuradas a ingenieros y científicos de datos con al menos cinco años de experiencia construyendo estos sistemas, realizadas entre agosto y diciembre de 2023 (Ryseff et al., 2024).

La diferencia de enfoque es lo interesante. En lugar de preguntar a directivos cuánto retorno han obtenido, pregunta a quienes construyen los sistemas por qué se cayeron los proyectos en los que participaron. Y encuentra cinco causas recurrentes:

Primera, que la organización no entiende o comunica mal qué problema hay que resolver, de modo que se acaba entregando un modelo optimizado para la métrica equivocada o que no encaja en el flujo de trabajo real.

Segunda, que no se dispone de los datos necesarios con calidad suficiente.

Tercera, que la organización persigue la tecnología más reciente en lugar de un problema concreto.

Cuarta, que falta infraestructura para gestionar los datos y desplegar lo construido.

Y quinta, que se aplica la IA a problemas que están fuera de su alcance actual.

Las dos primeras las mencionaron espontáneamente más de la mitad de los entrevistados. Las otras tres, entre un cuarto y un tercio. Y un dato que resume bien el conjunto: el 84 % citó algún fallo atribuible a la dirección como causa principal de que un proyecto fracasara.

De las cinco causas, solo la última es propiamente técnica. Las otras cuatro son organizativas. Esa es, con diferencia, la conclusión más importante de toda la literatura sobre este asunto.

Una honestidad que conviene imitar

El informe de RAND hace algo que casi nunca se ve y que dice mucho de su calidad: advierte de su propio sesgo. Sus autores señalan que, al haber entrevistado mayoritariamente a ingenieros y no a directivos, los resultados podrían inclinarse desproporcionadamente hacia identificar fallos de liderazgo, precisamente porque reflejan la perspectiva de quienes no ocupan esos puestos.

Es decir, el estudio que concluye que el 84 % de los fracasos vienen de la dirección advierte de que preguntó sobre todo a gente que no forma parte de la dirección. Eso no anula el hallazgo, pero lo coloca en su sitio.

Hay otras dos limitaciones que conviene tener presentes antes de aplicar sus conclusiones a una empresa pequeña. El informe se financió a través del instituto de investigación de la defensa estadounidense y está orientado en parte a ese contexto. Y, sobre todo, excluye expresamente de su ámbito los proyectos que se limitan a usar modelos preentrenados, centrándose en aprendizaje automático construido a medida.

Eso último importa mucho aquí, porque justo esos proyectos excluidos son los que hoy hace la mayoría de las pymes. Conviene decirlo en lugar de disimularlo: los estudios disponibles miden sobre todo proyectos grandes, a medida y de otra generación tecnológica. Se pueden extraer lecciones, pero no trasladar porcentajes.

Qué falla realmente en una empresa pequeña

Con esa advertencia por delante, lo que sigue procede de observar proyectos en empresas de este tamaño. Las causas se parecen a las del informe de RAND en el fondo y cambian bastante en la forma.

Se automatiza un proceso que nadie había ordenado antes. Es el fracaso más común y el menos reconocido. Si el proceso manual consiste en que tres personas hacen lo mismo de tres maneras distintas y ninguna está escrita, automatizarlo no produce eficiencia: produce una cuarta manera, y ahora con la autoridad implícita de venir de un sistema. La automatización amplifica el proceso que encuentra, y si encuentra desorden, amplifica desorden. Lo desarrollamos en «Ya le metí IA a mi empresa, y no funcionó…».

El problema elegido es el que más se nota, no el que más pesa. Se escoge lo que resulta llamativo en una demostración en lugar de lo que consume horas de verdad. La tarea vistosa suele ser puntual y de bajo volumen; la que come el día a día es aburrida, repetitiva y no luce en una presentación.

Nadie tiene tiempo asignado. En una empresa de doce personas, el proyecto lo lleva alguien que ya tiene un trabajo completo. Cuando llega una semana intensa, el proyecto se detiene, y la mayoría de proyectos detenidos no se reanudan.

No hay con qué comprobar si funciona. Sin un conjunto de casos reales con la respuesta correcta anotada, la valoración se convierte en opinión: a uno le parece que va bien, a otro que se equivoca mucho, y la discusión se resuelve por jerarquía en vez de por datos.

Se espera un resultado que nadie definió. Cuando al inicio no se acordó qué significaría que el proyecto ha salido bien, siempre hay margen para que alguien decida a posteriori que no ha salido bien. Un proyecto sin criterio de éxito declarado no puede ganar.

Se abandona antes de la parte que da el rendimiento. Los primeros resultados suelen ser mediocres, y la mejora llega al ajustar con los casos reales que van apareciendo. Quien abandona en la semana tres se lleva el coste íntegro y ninguno de los beneficios.

El criterio del año

De todas las recomendaciones del informe de RAND, hay una que traduce especialmente bien a una empresa pequeña y que funciona como filtro antes de empezar nada.

Sus autores proponen que la dirección esté dispuesta a comprometer al equipo con un problema concreto durante al menos un año, y añaden una consecuencia que es la parte verdaderamente útil: si un proyecto de IA no merece un compromiso de esa duración, probablemente no merece ningún compromiso.

Es una prueba dura y muy eficaz. Obliga a distinguir entre los problemas que la empresa va a seguir teniendo dentro de un año (que son los que conviene atacar) y los que son coyunturales o simplemente interesantes. Y descarta de un plumazo la categoría más peligrosa de todas, que es el proyecto que se emprende porque toca hacer algo con inteligencia artificial.

Qué se puede hacer distinto

De todo lo anterior se deduce un modo de proceder que no es complicado, aunque sí exige resistir la tentación de empezar por lo llamativo.

Elegir el problema por su peso, no por su brillo. La pregunta correcta no es qué se puede automatizar, sino dónde se va el tiempo: qué tareas consumen más horas de personas caras en algo que no requiere criterio y, sobre todo, en qué procesos los casos pasan más tiempo esperando que siendo trabajados. Acelerar una tarea de diecisiete minutos no cambia un proceso que tarda veintidós días. Casi siempre es algo aburrido.

Escribir el proceso antes de automatizarlo. Si no se puede explicar en una página cómo se hace hoy, el proyecto todavía no ha empezado. Este paso, además, suele revelar mejoras que no necesitan tecnología ninguna.

Definir por escrito qué sería un éxito, antes de empezar. Un número y un plazo. Sin eso, el proyecto queda a merced de la impresión que tenga cada cual el día de la revisión.

Reunir los casos de prueba antes que la herramienta. Entre cincuenta y doscientos casos reales con su respuesta correcta, incluidos los raros. Es lo que convierte las discusiones de opinión en comprobaciones.

Asignar tiempo de verdad, aunque sea poco. Cuatro horas semanales protegidas rinden más que una dedicación teórica que se evapora en cuanto hay trabajo.

Empezar por un proceso acotado y con salida. Uno que se pueda evaluar en unas semanas y del que se pueda salir sin haber comprometido la operación.

Errores frecuentes

Usar la estadística de fracaso como argumento, en cualquier dirección. Ni justifica no hacer nada ni sirve para vender. Lo que un proyecto vaya a hacer depende de cómo se plantee, no de una media sectorial calculada sobre empresas que no se parecen a la propia.

Confundir un piloto fallido con dinero perdido. Un piloto que en cinco semanas demuestra que un camino no funciona ha cumplido exactamente su función y ha salido barato. El problema no es el piloto que falla, sino el que se alarga un año sin decidir nada.

Buscar en la tecnología la causa del fracaso anterior. Cuando algo no funcionó, la explicación cómoda es que el modelo no era lo bastante bueno. Casi siempre estaba mal elegido el problema, o faltaban los datos, o nadie tenía tiempo.

Encadenar pilotos sin poner nada en producción. Es la forma más habitual de gastar presupuesto sin obtener nada, y suele venir de no querer tomar la decisión de comprometerse con algo.

Conclusión

Los proyectos de inteligencia artificial fracasan a menudo. Eso es cierto, y ninguna de las objeciones metodológicas de este artículo lo desmiente.

Lo que no es cierto es que fracasen por los motivos que se suelen invocar. La evidencia disponible, leída con cuidado, apunta de forma bastante consistente a que las causas dominantes son organizativas: se elige mal el problema, no se dispone de los datos, no se asigna tiempo y no se define qué significaría acertar. Solo una de las cinco causas identificadas por el trabajo más serio sobre el asunto es genuinamente técnica.

Para una pyme, la buena noticia es que las cuatro causas organizativas están enteramente bajo su control y no requieren presupuesto, sino decisiones. La incómoda es que ninguna de ellas se resuelve contratando a un proveedor, por bueno que sea.

Y si hubiera que quedarse con una sola prueba antes de empezar, sería la del año: si el problema que se quiere resolver no va a seguir siendo un problema dentro de doce meses, probablemente no era el problema por el que había que empezar.

Referencias

NANDA, Instituto Tecnológico de Massachusetts. (2025). The GenAI divide: State of AI in business 2025 [Informe preliminar]. MIT Media Lab.

Ryseff, J., De Bruhl, B., & Newberry, S. J. (2024). The root causes of failure for artificial intelligence projects and how they can succeed: Avoiding the anti-patterns of AI (RR-A2680-1). RAND Corporation. https://www.rand.org/pubs/research_reports/RRA2680-1.html