Por qué el 87% de los proyectos de IA no llegan a producción (y cómo ser del 13%)

TL;DR

El 87% de los proyectos de IA muere antes de llegar a producción, según el dato más citado de Harvard Business Review y replicado por Gartner. En PYME española el porcentaje es probablemente mayor, no menor.

• La causa no es la tecnología: es problema mal definido, datos sin preparar, falta de owner y métricas vanity.
• Gartner estima que el 40% de las apps enterprise tendrán agentes IA a finales de 2026, pero solo el 17% los han desplegado en producción real (2026).
• El patrón del 13% que sí escala es repetible: caso de negocio numérico, dataset acotado, owner único, plazo de 8-12 semanas y métrica vinculada a P&L.
• En PYME B2B la diferencia entre piloto y producción se decide en las primeras 3 semanas, no en el mes 6.

El problema no es la IA, es lo que rodea a la IA

Cualquier director o CEO de PYME española que haya estado en 2025 o 2026 en una conversación sobre inteligencia artificial conoce este patrón: el equipo entusiasmado, un piloto que arranca con buena pinta, una demo que impresiona al consejo, y luego silencio. Tres meses después nadie usa el sistema, los datos están a medio limpiar, el proveedor ha cobrado y el director vuelve a pegar correos en ChatGPT personal.

El dato que ancla esta sensación es conocido: el 87% de los proyectos de IA no llegan a producción. El número se popularizó con un artículo de Harvard Business Review (2024) y lo respalda Gartner en sus análisis de adopción enterprise. La última edición del Hype Cycle for Artificial Intelligence de Gartner (julio 2024, refrescado en 2026) sitúa a la IA generativa en el "valle de la desilusión" precisamente por esta razón: ya no es novedad, y las empresas empiezan a medir si el dinero invertido vuelve.

Para PYME española el ángulo es aún más crudo. Según Wolters Kluwer (informe 2026), el 76% de las PYMEs españolas usa IA semanalmente pero solo el 8% tiene soluciones implementadas de forma formal. Es decir: el equipo ya usa IA con o sin el director, pero casi nadie ha conseguido convertir ese uso en un sistema con propietario, métricas y presupuesto. Ese gap es exactamente donde mueren los pilotos.

¿Qué dice el dato realmente?

El 87% no significa que la IA no funcione: significa que la organización no estaba preparada para llevarla a producción.

Conviene desmontar el número porque se cita con poca precisión. El estudio original de HBR (basado en una encuesta a más de 600 ejecutivos de IT y operaciones, 2023-24) clasifica los proyectos en tres estados:

1. Producción real (13%): el sistema está en uso por personas que no son del equipo del piloto, hay métricas y hay presupuesto recurrente.
2. Pausados o en limbo (≈55%): hay código y modelo, pero nadie los usa. No se han apagado oficialmente, pero llevan más de 3 meses sin avanzar.
3. Cancelados (≈32%): se decidió formalmente parar.

Gartner llega a una conclusión parecida desde otro ángulo: en su Enterprise AI Survey 2024-26, el 92% de las empresas declara tener "iniciativas IA en marcha", pero solo entre el 10% y el 15% reporta impacto medible en P&L. La diferencia entre "tenemos un piloto" y "este sistema nos ahorra 8.000 € al mes" es enorme.

En PYME española, donde los recursos son más finitos y la tolerancia al "proyecto eterno" más baja, el porcentaje real de éxito probablemente esté incluso por debajo del 13%. No porque haya menos talento, sino porque hay menos margen para errores estructurales.

Las 5 causas reales por las que tu piloto IA muere

Después de analizar decenas de pilotos en empresas de 10 a 200 empleados en España (2024-26), los patrones de fracaso son sorprendentemente repetidos. No es la elección de modelo, no es el stack, no es la infraestructura. Es esto:

Causa 1: Problema mal definido (o "solución buscando problema")

El piloto arranca por curiosidad tecnológica, no por un dolor medible.

Síntoma típico: alguien del equipo directivo lee un artículo sobre RAG, asiste a un webinar, y vuelve al lunes diciendo "tenemos que montar un copiloto interno con nuestros datos". Tres semanas después, nadie sabe responder a la pregunta "¿qué problema resuelve esto exactamente y cuánto vale resolverlo?".

Los pilotos que escalan empiezan al revés: hay un proceso concreto que cuesta X horas al mes, una persona quemada haciéndolo, y un cálculo grosero de cuánto se ahorra si una máquina lo hace en su lugar. Antes de tocar tecnología, conviene pasar por un diagnóstico IA empresa que identifique los 3 o 4 procesos donde la IA tiene impacto real.

Si no puedes escribir el problema en una frase con un número al final ("reducir el tiempo de procesamiento de albaranes de 4h/día a menos de 30 min"), no estás listo para un piloto.

Causa 2: Datos no preparados (data readiness inexistente)

El 60% del esfuerzo real de un proyecto IA es preparar, limpiar y estructurar datos. Casi nadie lo presupuesta.

En PYME B2B española los datos suelen estar en tres sitios a la vez: un ERP antiguo, carpetas compartidas con permisos caóticos, y el correo personal de la persona que lleva más años en la empresa. El piloto asume que los datos están "ahí" y descubre en el mes 2 que la mitad están duplicados, otra parte tiene formato inconsistente, y los más críticos viven en PDFs escaneados que nadie ha indexado.

El patrón del 13% reconoce esto antes de empezar: hace un inventario de fuentes, decide qué dataset acotado va a usar en el piloto (no "todos los datos de la empresa"), y dedica las primeras 2-3 semanas a higiene de datos. Sin atajos.

Causa 3: Sin gobernanza ni owner único

Si el proyecto tiene "varios responsables", no tiene ninguno.

Un patrón letal en PYME: el director encarga el piloto a "marketing y operaciones juntos", o "el CTO con el responsable de calidad". Nadie tiene autoridad para tomar decisiones rápidas, nadie es despedido si el proyecto fracasa, y en el mes 3 cada parte echa la culpa a la otra.

Lo que funciona es lo contrario: una persona con nombre y apellido es la dueña del proyecto, tiene autoridad sobre presupuesto y plazos, y reporta directamente al director general. Da igual si es alguien interno o un consultor externo —el sesgo del proveedor está en cualquier propuesta— pero si vas a delegar fuera, conviene tener claros los errores al contratar consultor IA antes de firmar nada.

Causa 4: Métricas vanity en vez de impacto

"Hemos hecho 2.000 consultas al modelo este mes" no es una métrica. Es un contador.

Los pilotos que mueren están llenos de números que suenan bien pero no significan nada: número de usuarios, número de consultas, tasa de respuesta del modelo, satisfacción percibida en una encuesta de 5 personas. Nada de eso entra en una cuenta de resultados.

El 13% mide otra cosa desde el día 1: horas ahorradas por proceso y semana, errores evitados, coste por unidad procesada, tiempo de respuesta a cliente, ingresos atribuibles. Métricas que un CFO puede leer sin traducción.

Causa 5: Cero change management

El sistema técnico está listo y el equipo sigue trabajando como antes. Eso no es un éxito: es un cementerio.

La parte que más se subestima. Un piloto IA en una PYME de 30 personas afecta a procesos que esa misma gente lleva haciendo 10 años "a su manera". Si no hay un plan para que la gente cambie de hábito —formación corta, dueño de proceso que empuje, métricas de adopción visibles— el sistema vive 6 semanas y luego se abandona, no por mala calidad técnica, sino porque nadie se acuerda de usarlo.

El patrón del 13% trata change management como parte del proyecto, no como un "luego ya veremos". Mínimo: una sesión de formación por equipo afectado, un canal interno donde se publican casos de uso reales, y una métrica de adopción semanal en el dashboard del director.

Tabla: qué hace el 13% que escala vs el 87% que muere

Caso real anonimizado

Un grupo de despachos jurídicos de 22 personas (Madrid, marzo 2026) intentó implementar un copiloto interno con sus datos para acelerar redacción de escritos repetitivos.

El piloto arrancó en septiembre 2025 con un proveedor que prometió "RAG empresarial completo" en 4 meses por 45.000 €. En el mes 5 el sistema técnicamente funcionaba: subías un caso al chat interno y devolvía un borrador de escrito basado en sentencias previas. La demo al socio director fue impecable.

Lo que pasó después es el patrón de manual:

• Mes 6: solo 3 abogados de los 14 lo usaban con regularidad. El resto seguían con sus plantillas Word.
• Mes 7: nadie había definido qué métricas medir. La impresión subjetiva era "ahorra tiempo, supongo".
• Mes 8: descubrieron que el 30% de los borradores tenían errores de cita que un abogado junior no detectaría. Apagaron el sistema "temporalmente".

Coste hundido: 45.000 €. Tiempo perdido: 8 meses. Aprendizaje real: ninguno, porque tampoco se documentó qué falló.

Cuando reabrieron el proyecto en febrero 2026 con un enfoque distinto (problema acotado, owner único, métrica de horas ahorradas por escrito, 10 semanas de plazo, formación obligatoria), el coste fue €14.500 más €280/mes y el sistema entró en producción en abril 2026 con 11 de los 14 abogados usándolo a diario. El detalle de cómo se hizo este giro está en el análisis sobre piloto IA a producción que publicamos la semana pasada.

La moraleja honesta no es "el primer proveedor era malo". Es: el primer proyecto no estaba diseñado para escalar, daba igual quién lo ejecutara.

Errores comunes que matan el piloto antes del mes 3

Si tu piloto está en marcha y reconoces más de uno de estos cuatro, conviene parar a revisar:

1. No tienes una sola persona que responda al "¿cómo va?" sin mirar al resto de la sala. Esto es síntoma de owner difuso. Solución: nombrar a alguien antes del viernes, con autoridad real.

1. Llevas más de 4 semanas y no has visto el sistema en uso con un caso real, solo demos. Las demos engañan. Si en la semana 4 no hay un usuario final tocando una versión funcional —aunque sea fea— el proyecto está derivando hacia el "valle del PowerPoint".

1. Cuando preguntas por métricas, te enseñan dashboards de uso del modelo, no de impacto en negocio. Pide específicamente: horas ahorradas por persona y semana, errores evitados, coste por unidad procesada. Si el proveedor o el equipo no sabe responder, ahí está el problema.

1. Nadie ha hablado todavía de qué pasa cuando el sistema entre en producción. ¿Quién lo mantiene? ¿Quién forma a los nuevos? ¿Qué pasa si el modelo cambia (model drift)? Si esas preguntas se aplazan a "ya lo veremos", se aplazan a nunca.

Cómo blindar tu proyecto desde el día 1

Seis acciones concretas, ordenadas por momento del proyecto. Ninguna requiere conocimiento técnico profundo, todas son responsabilidad del director o CEO, no del proveedor:

1. Antes de contratar nada, escribe el problema en una sola frase con un número al final. Si no puedes, no estás listo. Ejemplo válido: "reducir el tiempo de respuesta a tickets de soporte de nivel 1 de 4 horas de media a menos de 15 minutos". Ejemplo inválido: "modernizar nuestra atención al cliente con IA".

1. Pide al proveedor (o a tu equipo interno) un caso de negocio numérico antes de empezar. Coste total estimado, ahorro o ingreso esperado, plazo de payback. Si no pueden producirlo en una página, no han hecho el trabajo.

1. Nombra un owner único con reporting semanal a dirección. Esa persona tiene autoridad para parar el proyecto si los hitos semanales fallan. Sin esa autoridad, el rol no sirve.

1. Limita el alcance del piloto a un proceso concreto y un dataset acotado. Nada de "todos los datos de la empresa" ni "varios departamentos a la vez". Un proceso, un equipo, un dataset. Si funciona, se replica.

1. Define tres métricas de impacto en P&L antes de la primera línea de código. No "satisfacción del usuario", sino "horas ahorradas por semana", "coste por documento procesado", "tiempo medio de respuesta a cliente". Una de ellas debe ser visible en el dashboard del director general.

1. Planifica el change management desde la semana 1, no desde el go-live. Mínimo: una sesión formativa por equipo afectado en la semana 6, un canal interno donde se publican usos reales, y una métrica de adopción que se revisa cada lunes en comité.

Javier Santos, consultor IA especializado en PYME B2B (Javadex), lo resume así: "El piloto que escala no es el que tiene mejor tecnología. Es el que en la semana 3 ya tiene a una persona usándolo en su trabajo real, con una métrica que un CFO entendería. Todo lo demás es decoración."

Preguntas frecuentes

¿Cuánto dura un piloto IA realista en PYME?

Entre 8 y 12 semanas para un piloto acotado, con go-live en producción al final de ese plazo. Si el proveedor propone "6 meses para el piloto", está vendiéndote un consulting clásico disfrazado de IA. Un piloto real en PYME tiene que demostrar valor en menos de 3 meses o se cancela y se aprende.

¿Qué métricas pide un CFO para aprobar producción?

Tres mínimas: coste total del sistema (setup + recurrente mensual), ahorro o ingreso atribuible cuantificado (horas ahorradas × coste/hora, o ventas adicionales), y plazo de payback (cuántos meses tardan los ahorros en cubrir la inversión). Si el payback es mayor a 12 meses en PYME, normalmente no se aprueba.

¿Se puede salvar un piloto fallido o hay que empezar de cero?

Depende de si lo que falló fue diseño o ejecución. Si el problema era ejecución (proveedor lento, prompt mal calibrado, integración rota), suele salvarse con un reset técnico. Si el problema era diseño (problema mal definido, sin owner, sin métricas), conviene parar formalmente, documentar aprendizajes, y rediseñar el alcance desde cero. Reciclar un piloto mal diseñado suele costar más que volver a empezar.

¿Quién debe ser el owner del proyecto IA en una PYME?

Alguien con autoridad sobre el proceso afectado, no alguien con autoridad técnica. Si el piloto es sobre soporte al cliente, el owner es la persona responsable de soporte, no el CTO. El CTO acompaña. Esto choca con la intuición de muchas PYMEs ("es un proyecto tecnológico, lo lleva el de tecnología") y es el primer error de gobernanza.

¿Por qué la mayoría de pilotos no llegan a producción?

Porque se diseñan como experimentos sin compromiso de escalado. El piloto que escala se diseña asumiendo que va a ir a producción: dataset, métricas, owner y plan de adopción se definen desde el día 1. El piloto que muere se diseña como "a ver qué pasa", y "a ver qué pasa" termina, casi siempre, en nada.

---

Si estás en el mes 4 de un piloto que no avanza y necesitas una segunda opinión honesta antes de seguir invirtiendo, cuéntanos tu caso y te respondemos en 24h con un diagnóstico sin compromiso.

En Resumen

• El 87% de los proyectos IA no llega a producción según HBR, y en PYME española el porcentaje real es probablemente mayor.
• Las 5 causas que matan pilotos son no técnicas: problema mal definido, datos sin preparar, sin owner, métricas vanity y cero change management.
• El 13% que escala comparte un patrón repetible: problema con número, owner único, plazo de 8-12 semanas, métrica vinculada a P&L y adopción planificada desde la semana 1.
• En PYME el coste medio de un piloto fallido está entre 25.000 € y 80.000 €. El de un piloto bien diseñado, entre 8.000 € y 20.000 € con ROI demostrable en 3-4 meses.
• Las primeras 3 semanas del proyecto deciden el resultado más que el mes 6. Si en la semana 3 no hay owner, métricas y usuario real probando, el proyecto ya está en la cuenta del 87%.
• El error más caro no es elegir mal el modelo: es no definir bien el problema antes de tocar tecnología.
• Change management no es opcional. Sin plan de adopción desde la semana 1, el mejor sistema técnico termina sin uso real.

---

Publicado el 13 de mayo de 2026 · Equipo Editorial IA para Empresas B2B