Por qué el 75% de los proyectos de IA no da el ROI prometido (y cómo estar en el 25% que sí)

El año pasado estuve en una reunión de comité directivo donde el responsable de operaciones llevaba un slide muy bonito. Título: «Proyecto IA — resultados primer trimestre». Cuerpo: dos frases sobre lo que el sistema podía hacer, una captura de pantalla de la herramienta y ningún número de negocio. Cero. El consejero delegado preguntó «¿y cuánto hemos ahorrado?». Silencio.

Ese silencio es el ROI que no apareció. Y no es una anécdota aislada.

Por qué fracasan los proyectos de IA en la empresa: la mayoría no falla por tecnología ni por presupuesto, sino porque se elige el caso de uso equivocado, no se mide el punto de partida y nadie tiene la responsabilidad real del sistema.

—

El dato que te interesa leer antes de la próxima propuesta de IA

Según el estudio de IBM sobre retorno de la IA, solo alrededor del 25% de las iniciativas de IA entregan el retorno esperado. El 75% restante muere en piloto, se abandona silenciosamente o sigue funcionando sin que nadie sepa muy bien para qué.

Más revelador todavía: ese mismo análisis de IBM indica que solo un 16% de los proyectos consigue escalar a toda la empresa. La mayoría se queda en ese estado intermedio que tan bien conoces: «el piloto va bien, pero…»

Y si preguntas por qué fracasan los proyectos de IA cuando los datos son el cuello de botella, la respuesta la da el informe State of AI in the Enterprise 2026 de Deloitte: el 52% de las organizaciones señala la calidad de los datos como su mayor bloqueo. No la tecnología. No el coste. Los datos.

La mediana de tiempo hasta ver valor real es de 5 meses. No 2 semanas, como a veces se vende.

Estos números importan porque definen el campo de juego. Si vas a apostar por IA en tu empresa, no vas con ventaja por defecto. Vas con el viento en contra si repites los errores que comete la mayoría.

—

Por qué fracasan los proyectos de IA en la empresa: los cinco errores que los matan antes de empezar

1. Elegir el caso de uso equivocado

El error más común no es técnico. Es de selección. Se empieza por lo que parece impresionante («un chatbot para atención al cliente») en vez de por lo que duele de verdad en el negocio.

En mi experiencia implantando IA en empresas medianas, los proyectos que funcionan atacan problemas con dolor medible y frecuente: una tarea que alguien hace manualmente tres horas al día, un proceso que genera errores costosos de forma recurrente, un cuello de botella que retrasa entregas.

Los que fracasan atacan problemas difusos: «mejorar la experiencia», «ser más eficientes», «explorar el potencial de la IA».

La pregunta que hay que hacerse antes de arrancar cualquier proyecto: ¿cuánto cuesta este problema hoy, en euros o en horas, y podemos medirlo? Si no tienes respuesta, para.

2. No medir el baseline antes de implantar nada

Este fallo es especialmente frecuente porque parece burocrático. Mides después, cuando «ya funcione». Error.

Si no tienes el dato de partida —cuánto tiempo tarda el proceso actual, cuántos errores genera, qué coste tiene— no puedes demostrar que la IA ha mejorado nada. No porque no lo haya mejorado, sino porque no tienes con qué comparar.

Y sin esa comparación no tienes ROI. Tienes una historia bonita.

El baseline se mide antes. Dos o tres semanas recogiendo datos del proceso actual. No es glamuroso, pero es lo que separa a las empresas que pueden decir «hemos ahorrado 40.000€ anuales» de las que dicen «el sistema va muy bien».

3. Automatizar sin un dueño claro

¿A quién le preguntas cuando el sistema de IA da un resultado raro? ¿Quién decide si ese output es bueno o malo? ¿Quién lo mejora cuando el contexto de la empresa cambia?

Si no hay respuesta clara para estas preguntas, el proyecto tiene los días contados.

En mi experiencia, los proyectos que sobreviven tienen siempre una persona —no un equipo, una persona— que es dueña del sistema. No tiene que saber programar. Tiene que saber del negocio, tener autoridad para tomar decisiones sobre el proceso y dedicarle tiempo real.

Sin ese dueño, la IA funciona bien el primer mes y luego empieza a derivar. Nadie la ajusta. Nadie la actualiza. Y en seis meses está en el cajón.

4. Perseguir la tecnología en vez del problema

«Hay que usar agentes.» «Hay que implementar RAG.» «Hay que integrar con el modelo más nuevo.»

Estas frases son señales de alarma. Cuando el punto de partida es la tecnología, acabas construyendo algo técnicamente interesante que no resuelve nada relevante para el negocio.

El orden correcto es siempre: problema → solución → tecnología. No al revés.

El proceso que tarda tres días en hacer un informe que podría hacerse en dos horas no necesita el modelo más avanzado. Necesita el modelo suficientemente bueno para automatizar ese informe concreto. La tecnología es un medio, no el objetivo.

5. Ignorar la calidad de los datos

El 52% de las organizaciones cita esto como su mayor bloqueo, y con razón. Una IA que trabaja con datos desordenados, incompletos o contradictorios no falla espectacularmente. Falla de forma silenciosa y gradual.

Genera outputs que parecen razonables pero están sesgados por datos históricos malos. Toma decisiones que nadie puede explicar porque nadie entiende de dónde vienen los datos de entrada.

Antes de implantar cualquier sistema de IA sobre un proceso, hay que hacer una auditoría honesta de los datos que lo alimentan. ¿Están estructurados? ¿Son completos? ¿Son consistentes? ¿Son actuales?

Esta conversación no es glamurosa. Pero es la que separa los proyectos que funcionan de los que mueren en silencio.

—

El marco que funciona: cinco pasos en orden

No hace falta reinventar nada. El patrón es el mismo en los proyectos que dan ROI.

Paso 1 — Problema con dolor medible. Identifica el proceso que duele. Cuantifica ese dolor: horas por semana, errores por mes, coste por incidente. Si no puedes ponerle número, no es el caso de uso adecuado todavía.

Paso 2 — Baseline antes de tocar nada. Mide el estado actual durante dos o tres semanas. Documéntalo. Ese número es el punto de partida contra el que lo compararás todo.

Paso 3 — Dueño del proceso. Nombra a una persona responsable del sistema de IA. No un comité. Una persona con nombre y apellidos. Su trabajo es asegurarse de que el sistema funciona, mejora y evoluciona con el negocio.

Paso 4 — Métrica de éxito clara. Antes de implantar, decide qué número significa que el proyecto ha tenido éxito. «Reducir el tiempo de elaboración de informes de 3 días a 4 horas» es una métrica. «Mejorar la eficiencia» no lo es.

Paso 5 — Piloto corto, medición, decisión. Corre el piloto. Mide contra el baseline. Compara contra la métrica de éxito. Decide: escalar, ajustar o parar. No dejes el piloto en modo eterno porque nadie se atreve a cerrarlo.

—

La diferencia real entre el 25% y el 75%

No es el presupuesto. No es el tamaño de la empresa. No es tener un equipo técnico propio.

La diferencia está en el orden de las preguntas. Si analizas por qué fracasan los proyectos de IA en la empresa, siempre aparece lo mismo: el 75% pregunta primero «¿qué podemos hacer con IA?» El 25% pregunta primero «¿qué problema queremos resolver y cuánto nos cuesta no resolverlo?»

Es una diferencia de orientación, no de recursos. Y se puede corregir antes de gastar un euro.

Leer también: Cómo calcular el ROI real de la IA y Los errores que matan un proyecto de IA.

—

Preguntas frecuentes

¿Cuánto tiempo tarda en verse el retorno de un proyecto de IA? Según datos de mercado de 2026, la mediana está en torno a cinco meses. Los proyectos bien estructurados —con baseline claro y caso de uso concreto— suelen mostrar resultados medibles antes. Los mal estructurados tardan indefinidamente porque nunca se definió qué significaba el éxito.

¿Por qué fracasan los proyectos de IA en la empresa cuando llegan a piloto? Porque el piloto se lanza sin criterio de salida. Si antes de empezar no se define cuándo el piloto «ha funcionado» y quién toma la decisión de escalar, el proyecto vive en un limbo cómodo donde nadie asume que ha fracasado pero tampoco avanza.

¿Necesito datos perfectos para empezar con IA? No perfectos, pero sí suficientemente buenos. El 52% de las organizaciones cita la calidad de los datos como su mayor bloqueo. No hace falta que estén impecables, pero sí hay que hacer una revisión honesta antes de implantar. Datos malos no generan fallos evidentes: generan resultados que parecen razonables y no lo son, lo cual es peor.