Por qué el 70% de proyectos de IA fallan — y cómo evitarlo en tu empresa.

Entre 2023 y 2025 se publicaron al menos una decena de estudios de McKinsey, BCG, MIT y Gartner sobre la tasa de fracaso de proyectos de IA generativa en empresas. Los números varían — 70%, 80%, hasta 95% en algunos estudios — pero el patrón es consistente: la mayoría de proyectos no generan ROI medible. Si tu empresa está considerando invertir en IA, necesitas entender por qué fallan los que fallan. No para asustarte. Para evitar las trampas.

Después de entregar más de 50 proyectos enterprise en LATAM — algunos de los cuales yo mismo heredé a medio camino cuando el proveedor anterior no pudo terminarlos — puedo decir que las razones del fracaso no son tecnológicas. Nunca. La tecnología funciona. Las razones son organizacionales, estratégicas y metodológicas. Las mismas cinco, una y otra vez.

Razón 01: Se empezó por la solución, no por el problema

Es el error más común, por mucho. Un directivo lee un artículo sobre IA generativa, asiste a una conferencia, o recibe la presentación de un proveedor, y regresa a su empresa con una pregunta: "¿cómo podemos usar IA?". En lugar de la pregunta correcta: "¿qué problemas concretos de nuestro negocio se beneficiarían si los resolviéramos mejor, y cuáles de esos se resuelven con IA?".

La diferencia parece sutil. No lo es. Cuando empiezas por la solución, acabas construyendo lo que Gartner llama "AI theater" — proyectos que demuestran capacidad tecnológica pero no mueven ninguna métrica que importe. Chatbots que nadie usa. Dashboards con predicciones que nadie lee. Automatizaciones que ahorran 2 horas a la semana en procesos que no eran el cuello de botella.

Cómo evitarlo

Antes de escribir una sola línea de código, responde tres preguntas por escrito: (1) ¿Qué KPI de negocio esperamos mover? (2) ¿Cuál es el valor monetario estimado de ese movimiento? (3) ¿Cómo vamos a medir que ocurrió? Si alguna de las tres es vaga, no arrancas el proyecto — no importa cuánto lo quiera el CEO.

Razón 02: Datos desordenados, insumos incompletos

Los modelos de IA son multiplicadores. Multiplican por alto número cuando los datos están bien; multiplican por cero cuando están mal. Muchas empresas descubren, en la semana 6 del proyecto, que los datos con los que iban a entrenar o alimentar el modelo están en 14 formatos distintos, con campos faltantes, con inconsistencias, o simplemente no existen.

No es un problema nuevo — es un problema que todos los proyectos de BI, data science, y analítica han enfrentado por 20 años. Pero con IA generativa se volvió más visible porque el output del modelo expone rápidamente la baja calidad del input.

Cómo evitarlo

Antes del kickoff, haz una auditoría de datos de 1 semana: revisa la calidad, completitud y consistencia de los datos que el proyecto va a necesitar. Si los datos no están en condiciones, el primer sprint del proyecto debe ser data cleanup — no intentes saltártelo.

Razón 03: Gobernanza cero o gobernanza excesiva

Hay dos fracasos típicos en gobernanza. El primero es no tenerla: "arrancamos rápido, vamos iterando". Lo que suena ágil termina siendo caótico — nadie reporta avances, nadie valida decisiones clave, y a los 4 meses el proyecto está técnicamente avanzado pero nadie en leadership sabe qué está pasando.

El segundo fracaso es el opuesto: gobernanza de Big Four. Steering committees semanales, 15 documentos de compliance, aprobaciones en 4 niveles. Funcional en proyectos de 10 millones de dólares. Asfixiante en proyectos de 10,000 dólares — el overhead mata al proyecto antes de que produzca valor.

Cómo evitarlo

Para proyectos en el rango 5,000 – 50,000 USD (el rango típico de empresas medianas), la gobernanza correcta es mínima pero consistente: un reporte escrito semanal de una página, un steering quincenal de 30 minutos con el sponsor ejecutivo, un documento de risks & decisions que se actualiza cada semana. Nada más. Nada menos.

Razón 04: No hay patrocinio ejecutivo real

Hay una diferencia entre patrocinio ejecutivo nominal y patrocinio ejecutivo real. El primero es cuando el CEO aparece en la reunión de kickoff, habla 10 minutos sobre la importancia estratégica, y no vuelve a aparecer hasta el cierre. El segundo es cuando el sponsor está disponible 1 hora cada dos semanas, toma decisiones cuando hacen falta, desbloquea acceso a otras áreas cuando el proyecto se topa con silos, y defiende el proyecto cuando los críticos aparecen.

La IA toca procesos que cruzan múltiples áreas. Siempre. No hay automatización interesante que no requiera colaboración entre finanzas y TI, o entre operaciones y ventas. Sin sponsor ejecutivo que pueda cruzar esos silos, el proyecto se atora en las fronteras organizacionales. Y se atora silenciosamente — nadie reporta "no nos pasan los datos"; simplemente el sprint se entrega a medias y todos culpan al consultor.

Si el ejecutivo más senior que puede tomar decisiones sobre el proyecto no está disponible al menos 2 horas al mes, el proyecto no va a funcionar. No importa qué tan bueno sea el consultor, qué tan claros los entregables, ni qué tan bonito el roadmap.

Razón 05: Change management tratado como pensamiento tardío

Esta es la razón más subestimada. Un proyecto puede entregarse técnicamente perfecto, con precisión del 94% y ROI validado — y fracasar porque las personas a las que impacta no lo adoptan, lo sabotean pasivamente, o encuentran formas creativas de no usarlo.

El problema no es resistencia al cambio como concepto abstracto. El problema es muy concreto: cuando automatizas el proceso que alguien hace manualmente, esa persona empieza a preocuparse por su trabajo. Si no manejas esa preocupación explícitamente — con conversaciones directas, con redefinición de roles, con capacitación en el nuevo trabajo que va a hacer — va a manifestarse como "la herramienta no funciona bien", "los datos están mal", "mis clientes no confían en el bot".

Cómo evitarlo

El change management se planea desde el día 1, no desde el día de despliegue. Tres prácticas básicas:

1. Involucrar a los usuarios finales en el diseño. Las personas cuyo trabajo va a cambiar deben participar en las decisiones sobre cómo va a cambiar.
2. Comunicar explícitamente qué pasa con el rol, no solo con el proceso. "Vas a dejar de capturar facturas — ahora tu trabajo es revisar las excepciones y mejorar el proceso" es una conversación muy distinta a "vamos a automatizar tu trabajo".
3. Capacitar en las nuevas habilidades antes del go-live. Si alguien va a pasar de capturista a analista, necesita tiempo para aprender a ser analista — no esperes que lo haga de un día para otro.

El framework de 5 preguntas antes de arrancar

Cada vez que evaluamos si un proyecto está listo para arrancar, hacemos estas 5 preguntas. Si alguna tiene respuesta insatisfactoria, no arrancamos — pausamos hasta resolver. La disciplina de decir "no todavía" es lo que separa los proyectos que funcionan de los que aparecen en la estadística del 70%:

1. ¿Cuál es el KPI de negocio específico que esperamos mover, y cómo lo mediremos?
2. ¿Están los datos que el proyecto necesita en condiciones de ser usados, o hay que limpiarlos primero?
3. ¿Hay un sponsor ejecutivo disponible al menos 2 horas al mes para desbloquear decisiones?
4. ¿Tenemos un plan de change management con los usuarios finales identificados y involucrados?
5. ¿Está acordada y documentada la gobernanza del proyecto — cadencia, reporting, toma de decisiones?

La pregunta incómoda

Si después de leer estas 5 razones te das cuenta de que tu último proyecto de IA (o el que tienes contratado ahora) presenta al menos 3 de ellas, tienes dos opciones. La primera es seguir adelante y cruzar los dedos — estadísticamente, tienes 30% de probabilidad de que funcione. La segunda es pausar, corregir el gap más crítico, y entonces continuar.

El costo emocional y político de pausar un proyecto en marcha es alto. Siempre. Pero el costo real de un proyecto fallido es mayor: 6 meses de tiempo ejecutivo, 10,000 a 50,000 USD de inversión, y — más importante — la pérdida de credibilidad interna para el próximo proyecto de IA, que va a ser mucho más difícil de aprobar después de uno que no funcionó.

Los proyectos exitosos no son necesariamente los más ambiciosos. Son los que se arrancaron con los cinco elementos alineados.