Todo el mundo conoce a alguien con un proyecto de IA que empezó con fuegos artificiales y acabó en un cajón. No es mala suerte ni falta de talento: es un patrón. Y el patrón no es técnico. Los modelos de hoy son más que suficientes para casi cualquier automatización de operaciones; lo que falla está antes y alrededor. Aquí van los cinco fallos que hunden la mayoría de proyectos, cada uno con nombre, para que los reconozcas en tu proyecto antes de que te cueste un año.
El fracaso casi nunca es técnico: los datos que lo prueban
Las cifras son incómodas y coinciden entre fuentes. RAND estima que el 80,3% de los proyectos de IA no entregan valor de negocio medible. MIT observó que el 95% de los pilotos de IA generativa nunca escalan a producción. Y Gartner atribuye el 85% de los fracasos a datos de mala calidad o insuficientes, no al algoritmo. Es decir: la máquina hace su trabajo; el problema es lo que le damos de comer y cómo la operamos.
Eso es una buena noticia, porque los fallos organizativos se pueden evitar sabiéndolos. Un fallo técnico exige investigación; estos cinco solo exigen honestidad. Vamos uno a uno.
Fallo 1 — Dato sucio: basura dentro, basura con aplomo
El primero y el que más mata. Un proceso parece un candidato perfecto hasta que abres el dato que lo alimenta y descubres que vive en la cabeza de alguien, en un hilo de WhatsApp o en un PDF escaneado del revés. La IA no arregla eso: lo amplifica. Le das un input a medias, contradictorio entre sistemas o directamente inexistente, y te devuelve una respuesta con la misma confianza que si fuera oro. Basura dentro, basura con aplomo.
La señal de alarma: nadie en la sala puede decirte dónde vive el dato ni quién lo mantiene. Si el input no está accesible en un formato que la máquina pueda leer, no tienes un proyecto de automatización — tienes un proyecto de digitalización previo que nadie presupuestó. Esto conecta directamente con qué procesos automatizar con IA: el criterio de "dato disponible" es el que más candidatos descarta.
Fallo 2 — Sin dueño: el proyecto de nadie muere en seis meses
Un proyecto de IA sin una persona responsable con nombre no es un proyecto: es un experimento a la espera de que alguien deje de mirarlo. Y alguien siempre deja de mirarlo. Los datos lo confirman: en el 56% de los casos fallidos, el patrocinador ejecutivo pierde interés antes de los seis meses. Sin dueño, no hay quien defienda el presupuesto, itere sobre los casos raros ni decida qué se cambia cuando el modelo se actualiza.
"El equipo de datos lo lleva" no es un dueño. Un dueño es una persona con nombre, con tiempo asignado y con un incentivo ligado a que el sistema funcione. Si nadie tiene la automatización en su descripción de puesto, la automatización no tiene a nadie.
Fallo 3 — Sin medición: no puedes defender lo que no cuentas
El tercer fallo es silencioso porque el sistema puede estar funcionando y aun así morir. Si no mediste el "antes" —cuántas horas costaba el proceso, cuántos errores tenía, cuánto tardaba—, no puedes demostrar el "después". Y lo que no se puede demostrar, no se puede defender cuando llega el recorte de presupuesto. El tiempo medio hasta que un proyecto se abandona ronda los 13,7 meses: justo el tiempo que tarda la novedad en apagarse si no hay un número que suba cada semana.
La regla es simple: antes de automatizar nada, define la métrica que va a subir o bajar y captura su línea base. Sin línea base, tu proyecto vive de la fe. Y la fe no sobrevive a un comité de dirección.
Fallo 4 — Automatizar un proceso roto: escalas el caos, más rápido
Automatizar un proceso malo no te da un proceso bueno más rápido: te da un desastre a escala. Si el flujo tenía pasos redundantes, excepciones sin documentar y decisiones que dependían de "preguntarle a Marta", la IA hereda todo eso y lo ejecuta mil veces al día sin que Marta pueda intervenir. El resultado es peor que el manual, porque ahora el error es sistemático.
Antes de automatizar, arregla. A veces la mejor automatización es primero eliminar el 30% del proceso que no aportaba nada. Por eso importa quién lo monta: un buen equipo no automatiza lo que le pides, rediseña primero y automatiza después lo que queda. Esto también es lo que separa el "cuándo NO automatizar" (una decisión previa) de este fallo, que es de ejecución.
Fallo 5 — Big-bang en vez de por fases: el estreno que no llega a temporada
El último fallo es de ambición mal colocada. El impulso natural es empezar por el proceso más grande y vistoso —"automaticemos todo el departamento"— y salir con todo a la vez. Es la vía rápida al fracaso: máxima superficie de error, cero aprendizaje acumulado y ningún resultado que enseñar hasta el final, que nunca llega. La demo es el estreno; producción es la temporada, y la temporada se gana capítulo a capítulo.
La alternativa que funciona: empieza por el proceso que cruce alto retorno y bajo esfuerzo, déjalo en producción con su dueño y su métrica, y usa esa primera victoria para financiar y desbloquear la siguiente. Fase a fase, cada una autosuficiente. El proyecto que llega a producción no es el más ambicioso: es el que encadenó tres victorias pequeñas antes de intentar la grande.
| El fallo | Cómo se ve | El antídoto |
|---|---|---|
| Dato sucio | Nadie sabe dónde vive el input | Auditar y limpiar el dato antes de automatizar |
| Sin dueño | Interés que se apaga a los 6 meses | Una persona con nombre, tiempo e incentivo |
| Sin medición | Funciona pero no se puede defender | Línea base antes de tocar nada |
| Proceso roto | Se escala el caos, más rápido | Rediseñar primero, automatizar después |
| Big-bang | Todo a la vez, resultado al final | Por fases: una victoria financia la siguiente |
Cómo se ve un proyecto que sí llega a producción
Un proyecto que sobrevive tiene un aspecto aburrido y reconocible: dato limpio y accesible, un dueño con nombre, una métrica con línea base, un proceso ya rediseñado y un despliegue por fases donde el primero ya rinde antes de montar el segundo. Nada de esto es glamuroso. Todo esto es lo que separa el 20% que funciona del 80% que acaba en el cajón.
Si prefieres no aprender estos cinco fallos por las malas, en la automatización de operaciones con IA hacemos exactamente esto: auditamos el dato, ponemos dueño y métrica, rediseñamos el proceso antes de tocarlo y desplegamos por fases. No entregamos un informe con recomendaciones — dejamos el primer proceso funcionando, con su número subiendo cada semana.