Por qué el 95% de los pilotos de IA fracasan antes de producir un solo resultado
Hay una escena que se repite en casi todas las empresas medianas que conozco. El equipo de tecnología presenta un piloto de inteligencia artificial. Los números iniciales son prometedores. El directorio aprueba la inversión. Y seis meses después, el piloto sigue siendo un piloto. Nadie lo mata oficialmente. Tampoco escala. Simplemente... ocupa espacio en el roadmap y en las reuniones de seguimiento.
Dennis Woodside, presidente y CEO de Freshworks, publicó hace unos días un análisis en Fortune que pone nombre a ese fenómeno. Y aunque el artículo sirve también como posicionamiento comercial para su empresa, el diagnóstico que ofrece merece ser tomado en serio por una razón sencilla: los datos externos que cita son incómodos para cualquier C-Level que lleve más de un año prometiendo resultados de IA a su junta.
El MIT encontró que el 95% de los pilotos de IA generativa fracasan antes de llegar a producción. Boston Consulting Group publicó en septiembre de 2025 que el 60% de las empresas no genera ningún valor material con IA, y ese porcentaje empeoró respecto al año anterior, a pesar de que los modelos mejoraron y la experiencia acumulada aumentó. Freshworks añade su propio dato: una cuarta parte del presupuesto de IA en las empresas medianas se consume en integración, limpieza de datos y el esfuerzo de hacer hablar a sistemas que nunca fueron diseñados para comunicarse entre sí.
Lo que esos tres números tienen en común no es el modelo de IA elegido. Es el estado del entorno operativo donde se intenta implementar.
La decisión que separa a los que avanzan de los que se estancan
Woodside describe el caso de Seagate Technology con una precisión que resulta útil precisamente porque no tiene glamour. El equipo de IT tenía tres meses para migrar a 30.000 empleados a una nueva plataforma de gestión de servicios, forzado por el vencimiento de un contrato. La decisión obvia, la que casi cualquier organización tomaría bajo esa presión, era mover las configuraciones existentes tal como estaban y resolver los problemas después. Es el camino más seguro en el corto plazo. También es el que garantiza que cualquier capa de IA que se construya encima operará sobre fundamentos defectuosos.
El equipo de Seagate eligió lo contrario. Reconstruyó desde cero: reestructuró el catálogo de servicios, estableció niveles de servicio consistentes entre regiones, reescribió las jerarquías de categorías para que los tickets pudieran enrutarse solos sin que un agente tuviera que adivinar. Lo hizo en el mismo plazo de tres meses. Un año después, el agente de IA desplegado sobre esa base deflecta aproximadamente un tercio de los tickets entrantes y la resolución en el primer contacto está 27% por encima del estándar de la industria.
Esa decisión, reconstruir en lugar de replicar, es el eje del argumento de Woodside. Y tiene una lectura organizacional que va más allá de la tecnología.
Lo que Seagate hizo requirió que alguien, en algún punto del proceso, tuviera una conversación que nadie quería tener: la que reconoce que los procesos heredados no son simplemente ineficientes, sino que son un obstáculo activo para cualquier mejora futura. Esa conversación tiene un costo político. Decir que los procesos actuales no se van a trasladar significa decir que el trabajo de años de configuración, personalización y ajuste no va a viajar al nuevo entorno. Significa invalidar, al menos parcialmente, decisiones pasadas. Pocas organizaciones tienen apetito para eso bajo presión de tiempo.
Lo que distingue a Seagate no es haber tenido más recursos ni más tiempo. Es haber tenido la lucidez, o el coraje directivo, de no arrastrar el pasado hacia adelante cuando el contrato expiró. Esa es la variable que no aparece en ningún manual de implementación de IA.
El impuesto invisible que paga quien no mira sus procesos
Woodside introduce el concepto de "impuesto de complejidad" para describir lo que sucede cuando una empresa intenta implementar IA sobre una arquitectura fragmentada. No es una metáfora decorativa. Es una mecánica financiera concreta.
Si el 25% del presupuesto de IA se pierde en integración y limpieza de datos antes de que el modelo produzca un solo output útil, una empresa que asigna un millón de dólares a IA está comprando, en la práctica, 750.000 dólares de capacidad. El 25% restante lo absorbe la deuda técnica acumulada. Para una empresa grande con presupuestos de transformación de cientos de millones, esa fracción puede tolerarse. Para una empresa de entre 500 y 20.000 empleados, con equipos de IT reducidos y márgenes de maniobra menores, esa pérdida puede ser la diferencia entre una iniciativa que prospera y una que se cancela silenciosamente en el siguiente ciclo presupuestario.
El argumento de Woodside sobre las "empresas ágiles", su término para ese rango de organizaciones medianas, tiene una lógica que los grandes medios suelen ignorar porque el segmento no es tan fotogénico como las historias de transformación digital de las Fortune 500. Pero es precisamente donde se va a ganar o perder la batalla de productividad que la IA promete. Las empresas medianas representan la mayoría del tejido empresarial global. Si la IA no funciona ahí, la promesa de productividad agregada no se materializa, independientemente de lo que hagan Google, Microsoft o Amazon con sus modelos propios.
Lo que hace más interesante el análisis es que el problema no está en la selección del modelo. Está en una capa anterior y más difícil de resolver: la calidad del entorno operativo. Datos dispersos en sistemas que no se hablan. Flujos de trabajo definidos por la historia de la empresa más que por su lógica. Taxonomías de tickets, categorías de servicios o jerarquías de productos que nadie revisó porque siempre habían "funcionado suficientemente bien". Cuando se le pide a un agente de IA que opere sobre esa infraestructura, no falla porque el modelo sea malo. Falla porque el entorno le entrega información ambigua, incompleta o contradictoria, y ningún modelo puede compensar eso.
Robert Lyons, director de tecnología de Katz Media Group, una unidad de negocio de 800 personas dentro de una empresa de 10.000 empleados, ofrece en el análisis de Woodside lo que es quizás el consejo más práctico del artículo completo: antes de desplegar cualquier herramienta de IA, su equipo limpió y etiquetó los datos, y realizó un seminario de introducción a IA para todos los empleados de la empresa, entregado no por el equipo de IT sino por una firma de investigación independiente. La distinción importa. Cuando IT presenta la IA, lo hace con el sesgo implícito de quien tiene interés en el resultado. Cuando lo hace un tercero neutral, el mensaje llega de manera diferente y la resistencia organizacional baja.
Lyons también describe una matriz de valor/esfuerzo para priorizar proyectos de IA: facilidad de implementación en un eje, valor para el negocio en el otro. Empieza en el cuadrante de alto valor y bajo esfuerzo. Su advertencia, "no empieces con el peor problema primero, no vas a generar valor", es una crítica directa a un patrón que veo con frecuencia en organizaciones que tratan la IA como una oportunidad para resolver los problemas que ninguna otra iniciativa pudo resolver. Esa lógica es comprensible pero contraproducente. Los proyectos de IA más visibles y ambiciosos son también los más frágiles, porque operan sobre los entornos de datos más desordenados y los flujos de trabajo menos estructurados.
Lo que Nucor y New Balance tienen en común con una empresa de acero
Woodside cita dos comparaciones que merecen atención separada. La primera es entre Nike y New Balance. Nike opera con 80.000 empleados; New Balance con 9.000. Woodside sostiene que New Balance está ganando terreno competitivo consolidando su infraestructura de IT en una plataforma única con una fuente de verdad centralizada, liberando a los equipos del trabajo de mantenimiento y reconfigurando cómo opera el negocio. La segunda comparación son Nucor y Steel Dynamics, dos de los cuatro mayores fabricantes de acero de Estados Unidos, que según Woodside llevan décadas de disciplina operativa que producen entornos que la IA puede optimizar directamente.
El patrón que conecta estos casos es el mismo que aparece en Seagate: la IA funciona donde el entorno operativo estaba listo para recibirla. No perfecto. Listo. Datos consolidados, flujos de trabajo definidos, sistemas capaces de intercambiar información sin intervención manual, y un resultado medible que el agente de IA tiene que mejorar.
Esto tiene una implicación directiva que pocos están nombrando con claridad. Las empresas que más dificultades tienen para implementar IA no son las que eligieron el modelo equivocado o las que contrataron a los consultores equivocados. Son las que durante años tomaron decisiones de tecnología priorizando la continuidad operativa sobre la coherencia arquitectónica. Cada vez que alguien dijo "añadamos este sistema porque resuelve este problema ahora" sin preguntarse cómo ese sistema iba a integrarse con el resto, estaba acumulando un pasivo que hoy se cobra en forma de presupuesto de IA consumido en integración.
Ese pasivo no es un fallo técnico. Es el resultado acumulado de conversaciones de arquitectura que no se tuvieron, de evaluaciones de deuda técnica que se pospusieron porque el trimestre pedía velocidad, de configuraciones heredadas que nadie quiso revisar porque el costo político de cuestionarlas era alto.
Lo que los casos exitosos que describe Woodside tienen en común es que alguien, en algún momento, tomó la decisión de pagar ese pasivo. Seagate lo hizo bajo presión de un contrato que expiraba. New Balance lo hizo como parte de una apuesta estratégica de velocidad. Nucor y Steel Dynamics lo hicieron durante décadas sin saber que estaban construyendo la base para una ventaja competitiva en IA.
Quien lidera tiene que pagar el costo de mirar lo que la organización evita nombrar
Hay un elemento del argumento de Woodside que el artículo toca tangencialmente pero que merece ser nombrado de frente: la mayoría de las organizaciones que están estancadas en pilotos de IA lo saben. No es ignorancia técnica. Es que la conversación sobre el estado del entorno operativo tiene un costo político que nadie quiere pagar.
Admitir que el 25% del presupuesto de IA se pierde en integración y limpieza de datos es admitir que las decisiones arquitectónicas del pasado fueron costosas. Admitir que los procesos heredados no se pueden trasladar al nuevo entorno es admitir que años de configuración no sobreviven al cambio. Admitir que los datos están en mal estado es admitir que las iniciativas de calidad de datos de los últimos años no entregaron lo que prometían.
Esas admisiones requieren algo que la dinámica de muchas juntas directivas desincentiva: la capacidad de nombrar un problema estructural sin que la persona que lo nombra quede asociada al fracaso que describe.
El trabajo de quien lidera en este contexto no es técnico. Es crear las condiciones para que esas conversaciones ocurran sin que el mensajero sea el costo. Las organizaciones que están generando resultados con IA, los casos que Woodside describe, no tienen entornos perfectos. Tienen líderes que decidieron pagar el costo de la claridad antes de pagar el costo de la implementación fallida.
Esa secuencia no es intuitiva bajo presión. Pero es la única que produce resultados que no desaparecen en el siguiente ciclo de revisión presupuestaria.
