En resumen

  • Estudios independientes señalan que la mayor parte de los proyectos de IA no da el resultado esperado: RAND habla de más de un 80% de fracasos, BCG encontró que solo el 4% de las empresas genera un valor sustancial y Gartner previó el abandono de al menos el 30% de los proyectos de IA generativa tras la prueba de concepto.
  • La causa principal no es tecnológica. Según la regla 10-20-70 de BCG, el éxito depende en un 10% de los algoritmos, en un 20% de la tecnología y los datos y en un 70% de las personas y los procesos.
  • Las siete causas más frecuentes: un problema mal definido, datos que no sostienen la promesa, un piloto sin camino hacia la operación, una IA fuera del flujo real de trabajo, una adopción ignorada, expectativas de retorno poco realistas y falta de responsable y de gobernanza.
  • La IA se paga sola cuando se aplica a un proceso que ya se entiende, con datos fiables, una métrica de negocio definida de antemano y personas al mando de las decisiones que exigen criterio.
  • La hoja de ruta segura tiene cinco pasos: elegir el problema por su valor, comprobar los datos, diseñar el flujo con quien lo va a usar, pilotar ya con la métrica de negocio y solo entonces escalar.

Lo que dicen los estudios, sin alarmismo

Las cifras varían porque cada estudio mide una cosa, pero apuntan en la misma dirección.

EstudioQué encontróA qué atribuye la causa
RAND Corporation, 2024Estimaciones de que más del 80% de los proyectos de IA fracasan, el doble que los proyectos de TI sin IA. Base: entrevistas con 65 científicos de datos e ingenieros con experienciaProblema mal comprendido, datos insuficientes, foco en la tecnología en lugar del problema, infraestructura débil, problemas demasiado difíciles para la IA
BCG, octubre de 2024Solo el 22% de las empresas ha superado la prueba de concepto y genera algún valor. Apenas el 4% genera un valor sustancialRegla 10-20-70: 10% algoritmos, 20% tecnología y datos, 70% personas y procesos
Gartner, julio de 2024Previsión de que al menos el 30% de los proyectos de IA generativa se abandonaría tras la prueba de concepto antes de que acabara 2025Datos de baja calidad, controles de riesgo inadecuados, costes crecientes y un valor de negocio poco claro
MIT NANDA, 2025El 95% de las organizaciones sin retorno medible con la IA generativaHerramientas que no aprenden del contexto ni se integran en el flujo de trabajo

El paralelismo histórico ayuda. En 2020, antes de la ola de la IA generativa, BCG ya había mostrado que el 70% de las transformaciones digitales se quedan por debajo de sus objetivos, por los mismos motivos: estrategia difusa, liderazgo ausente, gobernanza frágil. La inteligencia artificial no creó este patrón. Lo ha hecho más caro y más visible.

Las siete causas que hunden un proyecto de IA

1. El problema estaba mal elegido

El proyecto nace de "tenemos que hacer algo con IA", y no de un problema de negocio con responsable y valor. RAND sitúa esta causa en primer lugar: los equipos técnicos y la dirección no comparten la misma idea del problema que hay que resolver. El resultado es un modelo técnicamente correcto que responde a una pregunta que nadie ha hecho.

La señal: nadie es capaz de decir, en una frase, qué cifra del negocio va a cambiar si el proyecto sale bien.

2. Los datos no sostienen la promesa

Registros duplicados, históricos incompletos, información repartida en hojas de cálculo personales, reglas distintas en cada departamento. La IA aprende de lo que hay. Con datos malos, produce respuestas erróneas con apariencia de precisión, lo que es peor que no tener respuesta.

La señal: la primera fase del proyecto es "recopilar los datos", y no termina nunca.

3. El piloto no tiene camino hacia la operación

Las pruebas de concepto se hacen para impresionar: datos preparados a mano, un entorno aislado, un equipo dedicado. Nada de eso existe en la operación real. Sin presupuesto, arquitectura y responsable definidos desde el principio para la fase siguiente, el piloto se queda en una presentación.

La señal: el proyecto tiene fecha para la demostración y no tiene fecha para entrar en uso.

4. La IA se quedó fuera del flujo real de trabajo

Una herramienta en otra pestaña, que obliga a copiar y pegar, pierde frente a la costumbre. Es lo que el informe del MIT NANDA describe como la principal barrera: soluciones que no se integran en el trabajo ni aprenden del contexto de la empresa. La inteligencia tiene que aparecer dentro del sistema que la persona ya usa, en el momento en que decide.

La señal: la gente lo probó, le gustó y, un mes después, ya nadie lo abre.

5. La adopción se trató como un detalle

Comprar licencias no es transformarse. Todo cambio provoca alguna pérdida percibida: de dominio, de autonomía, de relevancia. Si quien lo va a usar no participó en el diseño, no se preparó y no entiende qué gana, el proyecto se topa con una resistencia silenciosa y educada. Aquí es donde vive el 70% de la regla de BCG.

La señal: la formación fue un vídeo enviado por correo electrónico.

6. La expectativa de retorno es poco realista

"Queremos ver el retorno en 90 días" empuja a los equipos hacia casos vistosos y superficiales. Las ganancias de productividad son reales, pero difíciles de convertir directamente en resultado económico, como observa el propio Gartner. Sin una línea de base medida antes, ni siquiera el éxito se puede demostrar.

La señal: la métrica del proyecto es la precisión del modelo, y no un indicador de negocio.

7. Falta un responsable, y falta gobernanza

¿Quién responde cuando la IA se equivoca con un cliente? ¿Quién aprueba el uso de datos personales a la luz del RGPD y de la LOPDGDD? ¿Quién controla los costes de uso, que crecen con el volumen? Sin esas respuestas, el departamento jurídico frena el proyecto la víspera del lanzamiento o, peor aún, nadie lo frena.

La señal: las preguntas sobre riesgos aparecen por primera vez en la reunión de aprobación final.

Un compañero, concentrado, trabaja con el portátil en una mesa compartida, con otras personas al fondo.
La mayor parte del trabajo de un proyecto de IA ocurre antes del modelo: en el problema, en los datos y en el proceso.

Dónde se paga sola la IA

El patrón de los proyectos que salen bien es casi el inverso de la lista anterior. Aplican la IA a procesos que la organización ya entiende, con mucho volumen, datos disponibles y una métrica de negocio clara.

Valor alto · datos listosEmpieza por aquíAtención de preguntas frecuentes, resumen y registro de conversaciones, reparto de solicitudes, clasificación de documentos, previsión de demanda y de ingresos.
Valor alto · datos frágilesOrdena primero los datosSiguiente mejor acción para cada cliente, riesgo de baja, fijación de precios. El proyecto empieza por la calidad de las fuentes.
Valor bajo · datos listosAutomatiza sin IASi unas reglas sencillas lo resuelven, la automatización tradicional es más barata, previsible y fácil de auditar.
Valor bajo · datos frágilesNo lo hagasEs el terreno de los pilotos que impresionan en la demostración y desaparecen al trimestre siguiente.

Cómo priorizar casos de uso: el valor para el negocio por un lado, la madurez de los datos por el otro.

Hay tres rasgos que se repiten en los casos que se pagan solos:

  • La IA está dentro del flujo. La respuesta sugerida aparece en la pantalla de atención al cliente, el resumen de la conversación entra directamente en el CRM, la previsión está en el panel que la dirección abre cada lunes.
  • Hay personas al mando. Lo que puede funcionar solo, funciona solo, con reglas claras. Las decisiones que exigen conversación y criterio siguen en manos de las personas, y la IA trabaja para ellas.
  • La ganancia tiene un responsable. Alguien del negocio, y no de tecnología, responde del indicador que el proyecto prometió mover.

Una hoja de ruta para sacar la IA del piloto

  1. ProblemaUn problema de negocio con responsable, valor y métrica
  2. Datos¿Existen las fuentes del problema y son fiables?
  3. FlujoDiseñado con quien lo va a usar, dentro de los sistemas actuales
  4. PilotoCorto, en operación real, midiendo ya el indicador de negocio
  5. EscalaGobernanza, costes, preparación de los equipos y evolución continua

Primero las personas y el problema. Después el proceso y los datos. Luego, la tecnología.

1. Elige el problema por su valor, no por la tecnología

Haz una lista de los problemas que la dirección ya conoce. Para cada uno, estima el valor que está en juego e identifica quién responde del resultado. Si nadie quiere hacerse cargo del indicador, el problema no es prioritario, por muy interesante que sea la tecnología.

2. Comprueba los datos antes de prometer

Para el problema elegido, comprueba si los datos existen, dónde están, quién los mantiene y con qué calidad. Esa comprobación lleva días y ahorra meses. Si los datos no sostienen el caso, el proyecto correcto es ponerlos en orden, y eso ya es avanzar: la misma base servirá a las operaciones de ingresos, a los paneles y a las próximas automatizaciones.

3. Diseña el flujo con quien lo va a usar

Siéntate al lado de quien hace hoy el trabajo. Dónde entra la IA, qué sugiere, qué confirma la persona, qué pasa cuando el sistema se equivoca o no sabe. Decide también dónde vive la solución: adaptar una herramienta del mercado o construir un componente propio es una decisión estratégica, y la tratamos en la guía sobre software a medida o estándar.

4. Pilota en operación real, con la métrica de negocio

Un piloto corto, con usuarios reales, datos reales y un grupo de comparación cuando sea posible. Mide antes la línea de base. Incluye en la cuenta todos los costes: integración, uso, revisión humana, preparación de los equipos. El piloto termina con una decisión: escalar, ajustar o cerrar. Cerrar pronto un caso que no se paga también es un resultado.

5. Escala con gobernanza y acompaña la adopción

Define responsables, límites de uso, tratamiento de los datos personales y seguimiento de la calidad y del coste. Prepara a los equipos antes del cambio, y no después. Y no te alejes: la adopción se mide semanas después del lanzamiento, cuando la novedad ha pasado y la vieja costumbre intenta volver.

Antes de aprobar el próximo proyecto de IA: diez preguntas

  1. ¿Qué indicador de negocio va a cambiar, y cuánto?
  2. ¿Quién, fuera del área de tecnología, es responsable de ese indicador?
  3. ¿Cuál es la línea de base medida hoy?
  4. ¿Existen los datos necesarios, y alguien se fía de ellos?
  5. ¿En qué pantalla, de qué sistema, se encontrará la persona con la IA?
  6. ¿Qué pasa cuando la IA se equivoca, y quién se da cuenta?
  7. ¿Ha participado en el diseño quien lo va a usar?
  8. ¿Hay presupuesto y responsable para la fase posterior al piloto?
  9. ¿Se han evaluado ya los riesgos jurídicos y de privacidad?
  10. ¿Unas reglas sencillas de automatización resolverían el mismo problema por menos?

Si más de tres respuestas son "no lo sabemos", el proyecto aún no está listo para empezar. Y descubrirlo antes es el mejor retorno que puede dar una hora de reunión.

Preguntas frecuentes

¿Cuál es la tasa de fracaso de los proyectos de IA?

Depende del estudio y de lo que se entienda por fracaso. RAND Corporation (2024) cita estimaciones según las cuales más del 80% de los proyectos de IA fracasan, el doble que los proyectos de TI sin IA. BCG (2024) encontró que solo el 22% de las empresas supera la prueba de concepto y el 4% genera un valor sustancial. MIT NANDA (2025) señaló que el 95% de las organizaciones no obtiene un retorno medible con la IA generativa, una cifra cuya metodología se ha cuestionado. El consenso está en el diagnóstico: la mayoría no llega al resultado de negocio.

¿Por qué tantos proyectos de IA se quedan atascados en el piloto?

Porque el piloto se diseña para demostrar que la tecnología funciona, no que el negocio mejora. Funciona con datos preparados a mano, fuera de los sistemas reales y sin las personas que usarían la solución en el día a día. Cuando llega el momento de integrar, formar a los equipos y asumir los costes de operación, no hay presupuesto, responsable ni métrica que justifique seguir adelante.

¿Cómo se mide el retorno (ROI) de un proyecto de IA?

Definiendo antes del proyecto una métrica de negocio, no de tecnología: tiempo de respuesta al cliente, horas liberadas en una tarea, tasa de error, conversión, ingresos retenidos. Se mide la línea de base, se ejecuta el piloto con un grupo de comparación cuando es posible y se contabilizan todos los costes, incluidos la integración, la operación, la revisión humana y la formación. La precisión del modelo es un indicador técnico, no un retorno.

¿Por dónde empezar a usar la IA en una empresa?

Por un proceso que la organización ya entiende bien, con mucho volumen, reglas razonablemente claras, datos disponibles y un coste de error bajo o fácil de contener con revisión humana. Ejemplos habituales: filtrar y responder preguntas frecuentes, resumir y registrar conversaciones, clasificar documentos, prever la demanda. Los procesos confusos hay que ordenarlos antes de meterles IA.

¿La IA generativa y la automatización son lo mismo?

No. La automatización ejecuta reglas definidas: si pasa esto, haz aquello. Es previsible y barata de auditar. La IA generativa interpreta el lenguaje, produce texto y resuelve casos que las reglas no previeron, a costa de cierta imprevisibilidad. Los mejores resultados salen de combinarlas: automatización para el flujo, IA para los puntos que exigen interpretación y personas en las decisiones de mayor riesgo.

¿Tengo que tener todos los datos ordenados antes de empezar con la IA?

Todos, no. Los datos del problema elegido, sí. Un proyecto bien acotado solo exige calidad en las fuentes que utiliza, y eso hace viable ponerlas en orden. Esperar a tener la base perfecta paraliza a la empresa, e ignorar la calidad de los datos produce respuestas erróneas con apariencia de precisión.