Por qué fracasan los proyectos de IA empresarial: 8 errores que hemos visto

TL;DR: Según el informe del MIT NANDA "The GenAI Divide: State of AI in Business 2025", el 95% de los pilotos de IA generativa en empresas no genera retorno medible. No es un problema del modelo. Es un problema de cómo se compran, se montan y se gobiernan los proyectos. Este artículo describe los 8 errores que vemos repetirse, con la advertencia incómoda: en al menos la mitad de las llamadas que recibimos, lo correcto es no empezar el proyecto que el cliente nos pide.

Hay una cosa que casi ningún proveedor de IA empresarial se atreve a decir en su web: una buena parte de los proyectos que nos llegan no deberían existir tal y como vienen formulados. No porque la idea sea mala, sino porque la pregunta de partida está rota.

Llevamos varios años montando agentes, asistentes internos, automatizaciones e integraciones de IA dentro de empresas medianas y grandes. Hemos visto proyectos transformar departamentos enteros y hemos visto otros encallar a las cinco semanas, después de haber consumido seis cifras de presupuesto. Y la diferencia, en la inmensa mayoría de casos, no está en el modelo elegido, en la nube, ni en el framework. Está en decisiones que se toman antes de escribir la primera línea de código.

Si vienes pensando "necesito un chatbot" o "quiero un agente de WhatsApp" o "tenemos que meter IA en el CRM", quédate. Es probable que necesites algo, pero quizá no sea exactamente eso. Y si después de leer este artículo decides parar, retrasar o reformular tu proyecto, también lo consideramos una victoria. Es, de hecho, parte de lo que hacemos cuando alguien nos pide un diagnóstico antes de firmar cualquier propuesta.

El contexto incómodo: cuántos proyectos de IA realmente fracasan

Antes de entrar en los errores conviene fijar la magnitud del problema, porque la conversación pública sobre IA empresarial está sesgada por los casos de éxito que se publican y silencia el ruido de fondo de los abandonos.

Los datos públicos disponibles en 2025 y 2026 dibujan un cuadro consistente:

• MIT NANDA, julio 2025. El estudio "The GenAI Divide" analizó más de 300 despliegues, 150 entrevistas a directivos y 350 respuestas de empleados. Conclusión: alrededor del 5% de los pilotos de IA generativa logran aceleración real de ingresos; el resto se queda atascado sin impacto medible en cuenta de resultados. Pese a un gasto agregado estimado de 30-40 mil millones de dólares en GenAI, la mayoría de organizaciones no documenta retorno alguno.
• Gartner. Predice que el 30% de proyectos GenAI serán abandonados tras la prueba de concepto a finales de 2025, y que el 60% de proyectos sin "AI-ready data" se abandonarán hasta 2026. En infraestructura y operaciones, solo el 28% de los casos de uso cumple expectativas de ROI; el 20% fracasa directamente.
• S&P Global Market Intelligence, 2025. El 42% de las empresas abandonó la mayoría de sus iniciativas de IA en 2025, frente al 17% en 2024. La empresa media descartó el 46% de sus pruebas de concepto antes de pasar a producción.
• RAND Corporation. Más del 80% de los proyectos de IA fracasan, aproximadamente el doble que los proyectos de TI sin IA.
• MIT, hallazgo cruzado. Comprar a un proveedor especializado y construir partnership tiene en torno al 67% de éxito; los desarrollos puramente internos, alrededor de un tercio de esa cifra.

Esto no significa que la IA no funcione. Significa que la IA empresarial es un problema mayoritariamente organizativo, no algorítmico. Y los errores que producen los fracasos son sorprendentemente repetitivos. Vamos a por ellos.

Error 1. Empezar comprando una solución antes de definir el problema

Esta es la madre de todos los errores y, paradójicamente, la que más se nos pide cometer. La conversación inicial suele ser una variante de:

"Necesitamos un chatbot con IA. La competencia ya tiene uno."
"Queremos un agente que conteste WhatsApp."
"Hay que meter IA en el CRM."

Lo que falta en esas frases es el problema. Un chatbot no es un problema, es una solución. Un agente de WhatsApp no es un problema, es un canal. La IA en el CRM no es un objetivo, es una arquitectura. Cuando se compra una arquitectura sin haber definido qué dolor concreto resuelve, qué proceso modifica, quién va a usarla y cómo se medirá el resultado, lo único que se garantiza es haber gastado dinero.

McKinsey lo dejó claro en su encuesta de IA de 2025: las organizaciones que reportan retornos financieros significativos tienen aproximadamente el doble de probabilidad de haber rediseñado el workflow completo antes de elegir el modelo. El orden importa: problema → proceso → datos → modelo → interfaz. Cuando ese orden se invierte -se elige primero la "tecnología sexy" y luego se busca dónde encajarla- el proyecto suele acabar en el cementerio del POC.

Cómo se ve este error en la práctica:

• Briefings que empiezan con "queremos un asistente IA que…" sin haber medido cuánto tiempo cuesta hoy esa tarea, ni cuántas personas la hacen, ni con qué frecuencia.
• Comités directivos que aprueban presupuesto basándose en demos vistas en LinkedIn.
• Definiciones de éxito tipo "que funcione bien" o "que la gente lo use".

La pregunta correcta es siempre la misma: ¿qué proceso, en qué departamento, con qué métrica medible y con qué coste actual estamos intentando mejorar? Si esa frase no se puede escribir en una sola línea, el proyecto todavía no está listo para licitarse. Por eso, antes de cualquier propuesta, en Lienzzo abrimos un proceso de diagnóstico cuyo único objetivo es responder a esa pregunta.

Error 2. Pensar que tus datos están "más o menos listos"

El segundo gran predictor de fracaso es la calidad y disponibilidad de los datos. Y aquí hay una asimetría dolorosa: prácticamente todas las empresas creen tener mejores datos de los que realmente tienen.

Los números externos lo confirman. Gartner publicó en febrero de 2025 que el 63% de las organizaciones no tiene -o no sabe si tiene- las prácticas adecuadas de gestión de datos para IA. Informatica, en su CDO Insights 2025, encontró que solo el 12% de las organizaciones reporta datos con calidad y accesibilidad suficientes para aplicaciones de IA. Y la predicción de Gartner del 60% de proyectos abandonados por falta de "AI-ready data" no es ninguna casualidad.

Lo que vemos cuando entramos a auditar es siempre algún subconjunto de esto:

• Información de clientes repartida entre el CRM, dos hojas de Excel locales, una bandeja de Outlook compartida y un SharePoint que nadie actualiza.
• Documentación crítica en formatos que la IA no puede procesar bien (PDFs escaneados, presentaciones llenas de capturas de pantalla, manuales en Word con tablas hechas con espacios).
• Bases de conocimiento internas con tres versiones contradictorias de la misma política, ninguna marcada como vigente.
• ERPs con campos personalizados sin documentar y semánticas que solo entiende "Marisa, que se jubila el año que viene".

Si pretendes que un asistente interno de IA conteste con fiabilidad sobre tus procesos, tus productos o tus clientes, necesita acceder a una versión consolidada y limpia de esa información. Eso suele requerir un proyecto previo de inventario y normalización de fuentes, y a veces la implementación de un sistema RAG bien diseñado. Saltarse este paso es la receta más rápida para construir un agente que alucina, contradice las políticas oficiales o, peor, da información incorrecta a un cliente.

WorkOS lo formuló bien en su análisis de patrones de éxito: los programas que ganan asignan entre el 50% y el 70% del tiempo y del presupuesto a la preparación de datos -extracción, normalización, gobierno, calidad, retención-. Si tu propuesta de proyecto dedica el 80% al modelo y el 20% a "los datos", está invertida.

Error 3. Confundir una demo bonita con un sistema de producción

Esta es probablemente la trampa más cara de la era GenAI. Los modelos modernos hacen demos espectaculares en cuestión de horas. Y eso ha cambiado las expectativas de cualquier dirección que haya visto un POC funcionando: si en dos semanas hicimos esto, en dos meses tiene que estar en producción atendiendo a clientes reales, ¿no?

No.

Una demo y un sistema de producción son objetos completamente distintos. Una demo enseña que el modelo es capaz de generar la respuesta correcta en un caso bien escogido. Un sistema en producción tiene que:

• Manejar entradas hostiles, ambiguas o adversariales.
• Integrarse con sistemas existentes (CRM, ERP, helpdesk, telefonía) con sus errores, latencias y caídas.
• Cumplir requisitos de seguridad, RGPD, trazabilidad y auditoría.
• Tener fallback humano cuando la IA no está segura.
• Tener observabilidad: logs, métricas de calidad, alertas cuando se degrada.
• Versionarse como un producto vivo, con releases controladas.
• Soportar picos de tráfico sin disparar la factura de tokens.

Las cifras lo confirman: Gartner ha publicado que solo el 48% de los proyectos de IA llegan a producción, y los que lo consiguen tardan una media de 8 meses desde el prototipo. Las organizaciones medianas son más rápidas que las grandes (en torno a 90 días frente a 9 meses o más), pero la cifra global es contundente: la mitad de los pilotos no cruza la línea.

El error de fondo es presupuestar el proyecto como si fuera la demo. Cuando llega la fase real -integración con CRM o ERP, seguridad, controles de calidad, formación, soporte 24/7- el presupuesto se queda corto, el plazo se duplica y el patrocinador empieza a perder paciencia. Resultado típico: el sistema sale a producción sin algunas piezas, falla, se desactiva "temporalmente" y entra en el limbo del que no vuelve.

Síntoma de alarma: que tu proveedor te enseñe la demo antes que la arquitectura. Si después de una hora de reunión solo has visto pantallas bonitas y ningún diagrama de integraciones, gobierno de datos, observabilidad y fallback, el proyecto está siendo vendido, no ingenierizado.

Error 4. Poner el presupuesto donde se ve, no donde rinde

Hay un sesgo casi universal en la asignación de presupuesto de IA: se va al departamento con más visibilidad externa. Marketing y ventas. El nuevo chatbot del sitio web. El generador de copys. La automatización del outbound.

El estudio del MIT lo dice de forma incómoda: más de la mitad de los presupuestos de IA generativa van a herramientas de ventas y marketing, mientras que el ROI más alto se está midiendo en automatización de back-office: eliminación de procesos externalizados, reducción de costes de agencias, simplificación de operaciones internas.

Esto tiene sentido si lo piensas. El back-office tiene tres características que enamoran a la IA: tareas repetitivas, datos estructurados y métricas claras de coste por operación. El front-office, especialmente marketing, está lleno de variables externas, definiciones de éxito difusas y dependencias humanas que la IA no controla. Por eso un asistente que automatice la conciliación de facturas, la clasificación de correos al departamento de atención o la generación de informes internos suele entregar ROI demostrable en pocos meses, mientras que el "agente que escribe nuestros emails de marketing" se queda en una mejora marginal de productividad individual.

No estamos diciendo que no haya casos de uso buenos en ventas y marketing. Los hay, y bien hechos. Pero si tu organización solo va a hacer un proyecto de IA este año, el lugar con mayor probabilidad de retorno suele ser un proceso interno aburrido, no la home del sitio web. En Lienzzo trabajamos los dos lados -tenemos casos de asistentes internos, análisis de datos con IA y automatización de procesos en back-office, y también agentes de WhatsApp y chatbots empresariales cara al cliente-, pero cuando alguien tiene que elegir uno, le aconsejamos casi siempre empezar por dentro.

Error 5. Esperar que la IA arregle un proceso roto

Si tu proceso actual está mal definido, mal documentado o lleno de excepciones que solo conocen tres personas, la IA no lo va a arreglar. Lo que va a hacer es automatizarlo más rápido y a mayor escala, lo cual significa multiplicar los problemas existentes en lugar de eliminarlos.

Hemos visto esto repetidamente:

• Un proceso de calificación de leads en el que cada comercial usa criterios distintos. Se automatiza con IA. Resultado: ahora hay tres veces más leads "calificados" pero la tasa de cierre cae porque la IA aprendió la inconsistencia, no la lógica correcta.
• Un proceso de atención al cliente sin árbol de decisión claro. Se monta un agente conversacional. Resultado: el agente da respuestas correctas en un tono incorrecto, derivaciones incorrectas en un tono correcto y todo el mundo culpa al "modelo".
• Un proceso de aprobación de gastos con cinco excepciones no documentadas. Se automatiza con un agente. Resultado: aprobaciones que rompen la política y excepciones legítimas que se bloquean.

La regla de oro es desagradable pero firme: si tu proceso no se puede ejecutar de forma consistente por una persona nueva con el manual en la mano, no estás listo para automatizarlo con IA. La IA amplifica lo que ya tienes. Si lo que tienes es desorden, te dará desorden a escala.

El paso previo es muchas veces poco glamuroso: mapear el proceso real (no el proceso escrito), identificar las decisiones implícitas, normalizarlas y documentarlas. Solo entonces tiene sentido automatizar. Esto a veces significa que el primer entregable de un proyecto de IA es un documento de proceso, no un agente. Cuando un cliente acepta esto, el proyecto suele tener éxito. Cuando insiste en que "ya lo tenemos claro internamente, vamos al desarrollo", suele fracasar.

Error 6. No involucrar a quien va a usar el sistema cada día

Este error es responsabilidad compartida entre cliente y proveedor. La compra de IA en empresas medianas y grandes la suele liderar dirección general, IT o transformación digital. Las personas que van a convivir con el asistente, el agente o el software a medida durante ocho horas al día rara vez están en esas reuniones.

Resultado típico: se entrega un sistema técnicamente correcto que nadie usa. O peor: que se usa mal, con esquemas de bypass, copia-pega a otras herramientas y plantillas en Excel paralelas porque "es más rápido".

El estudio del MIT identifica un fenómeno que merece nombre propio: la shadow AI economy. Empleados que usan ChatGPT, Claude o Copilot personales para hacer su trabajo, fuera de los sistemas oficiales, porque la IA "oficial" no se adapta a su flujo. Más del 80% de las organizaciones han probado herramientas generales tipo ChatGPT o Copilot, pero la productividad real medida sigue siendo individual y no impacta la cuenta de resultados.

Para evitar este error, los proyectos que vemos triunfar siguen un patrón:

1. Co-diseño con los usuarios finales desde la fase de definición. No "validación", co-diseño. Que escriban con nosotros qué tarea quieren delegar y cuál no.
2. Pilotos pequeños y reales, con un equipo concreto, durante un tiempo concreto, midiendo cosas concretas. No "lanzamiento corporativo".
3. Formación específica, no genérica. No basta con un curso de "cómo usar IA". Hay que enseñar a usar este asistente para esta tarea.
4. Iteración rápida sobre los puntos de fricción reales que aparecen en las primeras semanas.
5. Patrocinio explícito del responsable del equipo, no solo del CIO.

Cuando la IA se diseña con quien la va a usar, el sistema entrega valor en pocas semanas. Cuando se diseña en una sala donde nadie la va a usar, se queda en el inventario de licencias.

Error 7. Lanzarse sin definir antes los KPIs

Si no puedes responder a la pregunta "¿cómo sabremos si esto ha funcionado?" antes de empezar el proyecto, no estás listo para empezarlo. Y, sin embargo, una proporción asombrosa de proyectos arranca con métricas como "mejorar la productividad", "agilizar el proceso" o "estar a la altura del mercado". Ninguna de las tres se puede medir.

Las métricas útiles son específicas, cuantificables y vinculadas al negocio. Algunos ejemplos reales:

• Coste por incidencia resuelta en atención al cliente, antes y después.
• Tiempo medio de respuesta a consultas internas de personal.
• Porcentaje de leads correctamente cualificados (verificable contra tasa de cierre real seis meses después).
• Horas/persona/mes dedicadas a tareas administrativas concretas.
• Tasa de error en procesos de back-office.
• Tasa de adopción: porcentaje de empleados objetivo que usa el sistema más de N veces por semana.
• NPS interno del usuario del asistente.

Estas métricas tienen una propiedad fundamental: permiten fallar rápido. Si a los 90 días el coste por incidencia no ha bajado, el problema no es "esperar más". El problema es que el diseño no está funcionando, y hay que cambiarlo o parar. Las organizaciones que no definen KPIs antes son las que se ven atrapadas en el "ya casi está" durante 18 meses, porque no tienen un criterio objetivo para parar.

Una versión adulta de un proyecto de IA empresarial incluye, antes de la primera línea de código, un cuadro con: línea base, objetivo, fecha de revisión y criterio de aborto. Si tu propuesta no lo tiene, falta una pieza esencial.

Error 8. Subcontratar todo y no internalizar nada

Este es el último error y es delicado escribirlo desde una empresa que vive de implementar IA para terceros. Pero es real.

La IA empresarial no es una infraestructura que se instala una vez y se olvida. Es un sistema vivo: los modelos cambian, los datos cambian, las regulaciones cambian, los casos de uso evolucionan. Si todo el conocimiento de cómo funciona el sistema vive en la cabeza del proveedor, la empresa cliente queda en una posición incómoda: depende de un tercero para cualquier cambio mínimo, no puede iterar a la velocidad del mercado y, si la relación con el proveedor se rompe, puede perder operativa crítica.

El patrón sano es exactamente el contrario:

• El proveedor implementa, pero transfiere conocimiento desde el primer día.
• Existe documentación viva (no entregables muertos en PDF) que los equipos internos pueden leer y modificar.
• Hay al menos un perfil interno -puede ser un product owner técnico- con visión completa del sistema.
• La arquitectura está montada para que cambios menores los pueda hacer el equipo del cliente sin volver a contratar al proveedor.
• El contrato incluye fases explícitas de transición y, eventualmente, autonomía.

El estudio del MIT contiene un dato matizado al respecto: comprar a vendors especializados tiene mayor tasa de éxito que construir todo internamente. Esto es cierto. Pero entre "construir todo internamente desde cero" y "depender absolutamente de un proveedor" hay un espacio enorme. Ese espacio se llama partnership con transferencia, y es donde funcionan los proyectos.

Cuando un proveedor propone un modelo de "implementación + soporte continuo perpetuo + cualquier cambio se cobra como nuevo proyecto", está vendiendo dependencia, no IA. Es una señal a la que prestar atención.

La advertencia incómoda: a veces lo correcto es no hacer el proyecto

Hasta aquí los ocho errores. Pero hay una conclusión que pesa más que todos ellos juntos y queremos dejar por escrito, aunque sea contra nuestros propios intereses comerciales:

Si tu organización está en una situación donde varios de estos errores se acumulan -problema mal definido, datos desordenados, proceso roto, sin patrocinio interno, sin KPIs- el mejor consejo no es "contratar IA". El mejor consejo es "todavía no".

Lanzar un proyecto de IA en esas condiciones tiene una probabilidad altísima de:

• Quemar entre 50.000 y 500.000 euros de presupuesto sin retorno.
• Generar resistencia interna que dificultará el siguiente intento durante años.
• Dañar la credibilidad de quien lo patrocinó dentro de la organización.
• Producir un caso interno de "la IA no funciona" que se repetirá en cada reunión durante los próximos cinco años.

El coste de un proyecto fallido no es solo el dinero. Es la herida cultural que deja, y esa herida no aparece en ninguna factura. Por eso, en bastantes de los diagnósticos que hacemos en Lienzzo, la recomendación es ordenar primero datos, procesos o gobierno; y dejar la IA para una segunda fase, cuando el terreno esté preparado. Hemos rechazado proyectos. Hemos recomendado pausas. Hemos sugerido a clientes empezar con análisis de datos o desarrollo de software a medida sin IA en lugar del agente que pedían, porque era el paso correcto antes.

Esto no es modestia. Es matemática: un proyecto que fracasa nos perjudica a todos -al cliente que pierde dinero, y al proveedor que pierde reputación-. Un proyecto bien temporizado, aunque arranque seis meses más tarde, beneficia a los dos.

Qué hacer en su lugar: el orden correcto

Si te reconoces en alguno de los errores anteriores, la secuencia sensata es esta:

1. Define el problema antes de la solución. Una sola frase: qué proceso, qué métrica, qué coste.
2. Audita tus datos con honestidad. Si no están listos, prepara primero la base.
3. Diseña con quien va a usar el sistema, no para quien va a aprobar el presupuesto.
4. Pon el dinero donde rinde, no donde se ve.
5. Empieza con un piloto pequeño y medible, con KPIs definidos y fecha de revisión.
6. Construye el proyecto como un producto vivo, no como un entregable.
7. Internaliza el conocimiento desde el día uno.

En Lienzzo ofrecemos un proceso de diagnóstico previo precisamente para evitar que las empresas se metan en proyectos mal planteados. El diagnóstico no compromete a contratar nada. Su único objetivo es responder, con datos sobre tu organización, dos preguntas: qué problema tiene sentido atacar primero, y si es el momento correcto para hacerlo con IA.

Si la respuesta es que sí, pasamos a propuesta. Si la respuesta es que no, lo decimos y el cliente se ahorra un proyecto fallido. Las dos respuestas nos parecen igualmente útiles.

Si quieres ver cómo se ven los proyectos cuando esos pasos sí se siguen, tenemos una recopilación de casos reales de implementaciones que cruzaron de POC a producción y se quedaron allí. Son los proyectos que pasaron antes por un buen diagnóstico.

Preguntas frecuentes

¿Cuál es el principal motivo por el que fracasan los proyectos de IA en empresas?

Según los estudios de MIT NANDA (2025), Gartner (2024-2025) y RAND Corporation, el motivo dominante no es técnico sino organizativo. Combinación de problemas mal definidos, datos no preparados para IA, procesos rotos que se intentan automatizar, falta de KPIs claros y ausencia de involucración del usuario final. El modelo, el proveedor de IA o la nube elegidos rara vez son la causa raíz.

¿Cuántos proyectos de IA empresarial llegan realmente a producción?

Gartner publicó que solo el 48% de los proyectos de IA llega a producción, y los que lo hacen tardan una media de 8 meses desde el prototipo. El estudio del MIT NANDA encontró que solo el 5% de los pilotos de IA generativa logra impacto medible en cuenta de resultados. S&P Global Market Intelligence reportó que el 42% de las empresas abandonó la mayoría de sus iniciativas de IA en 2025.

¿Vale la pena hacer un POC antes del proyecto completo?

Sí, pero con una condición: que el POC esté diseñado pensando en producción desde el día uno, con criterios objetivos para decidir si se sigue o se para. Los POCs que se diseñan solo para "ver si funciona" suelen funcionar (los modelos modernos hacen demos brillantes) y luego no escalan. Un buen POC define escenarios reales, KPIs medibles y arquitectura de integración antes de empezar.

¿Es mejor desarrollar la IA internamente o contratarla a un proveedor?

Los datos del MIT (2025) indican que la compra a proveedores especializados con partnership tiene aproximadamente el doble de tasa de éxito que el desarrollo puramente interno. La razón principal es la curva de aprendizaje y el coste de mantener equipos especializados internos en una tecnología que cambia cada pocos meses. Sin embargo, lo importante no es solo "comprar fuera": es comprar con un modelo de partnership que incluya transferencia de conocimiento, para no quedar atrapado en dependencia perpetua del proveedor.

¿Cuánto presupuesto debería destinar a la preparación de datos en un proyecto de IA?

Los análisis de proyectos exitosos sugieren entre el 50% y el 70% del tiempo y presupuesto dedicado a la preparación de datos: extracción, normalización, gobierno, calidad y observabilidad. Si tu propuesta dedica el 80% al modelo y el 20% a los datos, está invertida y entra en el patrón estadístico de fracaso.

¿Cómo sé si mi empresa está lista para un proyecto de IA?

Una organización está razonablemente preparada cuando puede responder con claridad a estas preguntas: ¿qué problema concreto quiero resolver?, ¿con qué métrica voy a medir el éxito?, ¿quién va a usar el sistema y está implicado en el diseño?, ¿están mis datos accesibles y limpios?, ¿tengo patrocinio interno claro?, ¿puedo permitirme parar el proyecto si los KPIs no se cumplen? Si alguna de estas respuestas no es clara, conviene hacer un diagnóstico previo antes de comprometer presupuesto.

Fuentes y referencias

• MIT NANDA Initiative. The GenAI Divide: State of AI in Business 2025. Julio 2025.
• Gartner. Lack of AI-Ready Data Puts AI Projects at Risk. Febrero 2025.
• Gartner. Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025. Julio 2024.
• Gartner. AI Projects in I&O Stall Ahead of Meaningful ROI Returns. Abril 2026.
• S&P Global Market Intelligence. Survey of 1,000+ enterprises on AI initiative abandonment rates. 2025.
• RAND Corporation. The Root Causes of Failure for Artificial Intelligence Projects. 2024.
• Informatica. CDO Insights 2025. 2025.
• McKinsey & Company. The State of AI Survey. 2025.