Cada pocos meses sale un estudio diciendo que la mayoría de proyectos de IA en empresas nunca pasan de la fase piloto, o se abandonan en silencio antes de cumplir un año. El titular siempre es el mismo: la IA no cumple. Pero si miras de verdad qué falló en esos proyectos, casi nunca es el modelo. La tecnología disponible hoy es más que capaz de hacer lo que la mayoría de empresas necesitan. Lo que falla es todo lo que rodea a la tecnología: las decisiones tomadas antes de escribir una sola línea de código, y las que nunca se toman después del lanzamiento.
¿Se está eligiendo el caso de uso equivocado desde el principio?
Aquí empiezan la mayoría de fracasos, mucho antes de que nadie abra un ordenador. Alguien en la empresa ve una demo vistosa —un chatbot que escribe poesía, un agente que "hace de todo"— y decide que eso es lo que necesita la empresa. Queda muy bien en una reunión. Casi nunca tiene relación con lo que de verdad cuesta tiempo o dinero al negocio.
Un proyecto tiene opciones reales de funcionar cuando apunta a algo concreto y medible: una rutina de exportar-y-enviar-correo que se come tres horas cada lunes, un buzón de soporte donde el 40% de los tickets son las mismas cinco preguntas, una conciliación de facturas que ocupa un día entero al mes a dos personas. No son casos glamurosos. No dan capturas de pantalla espectaculares. Pero tienen un antes y un después claro, y eso es lo que marca la diferencia entre un proyecto que se sigue financiando el año siguiente y uno que desaparece en silencio.
La regla es sencilla: si no puedes decir en una frase cuántas horas o cuánto dinero va a ahorrar esto, y a quién, probablemente estás resolviendo el problema equivocado.
¿Alguien ha mapeado de verdad cómo funciona el proceso real?
Este es el paso que más se salta, y suele ser el que mata el proyecto. Los equipos pasan directamente de "queremos que la IA se encargue de X" a construir, sin sentarse nunca a documentar cómo es X en la práctica —no el proceso descrito en una diapositiva, sino el que ocurre sobre el terreno, con sus excepciones, sus parches manuales, y esa persona que "sabe arreglarlo cuando se rompe".
Vale la pena decirlo claramente: el problema que un cliente describe en el primer mensaje muchas veces no es el problema real. Alguien pedirá "una IA que responda correos de clientes" cuando el problema de fondo es que tres sistemas distintos no se hablan entre sí y hace dos años que alguien copia datos a mano de uno a otro. Construir la IA encima de esa fontanería rota solo acelera un proceso malo; no arregla nada.
Mapear el proceso real antes de construir no es un trámite burocrático para retrasar las cosas. Es la diferencia entre un sistema que encaja con cómo trabaja realmente la gente y otro que funciona técnicamente pero que nadie acaba usando.
¿Qué implica de verdad mapear bien un proceso?
No hace falta que sea un ejercicio de consultoría de seis semanas. Normalmente significa sentarse con las personas que hacen el trabajo hoy, observar lo que hacen de verdad (no lo que dice el documento del proceso), y anotar cada excepción, caso límite y parche manual. Muchas veces este paso, por sí solo, revela que el arreglo real no es la IA, sino resolver un traspaso roto entre dos herramientas. Ese también es un buen resultado. Un proyecto diseñado alrededor del problema real, aunque sea poco vistoso, gana siempre a una solución llamativa para el problema equivocado.
¿Por qué dejan los equipos de usar herramientas que técnicamente funcionan?
Un sistema puede ser técnicamente perfecto y aun así fracasar si las personas que deberían usarlo no lo hacen. Pasa más de lo que la mayoría de empresas admite, y casi nunca es porque la herramienta sea mala, sino por cómo se introdujo.
Si una herramienta nueva cambia la forma de trabajar de alguien y nadie explicó por qué, ni lo formó bien, ni pidió su opinión antes, la reacción natural es resistencia, y a menudo abandono silencioso. La gente vuelve a la hoja de cálculo que conoce. La adopción no es un detalle que se resuelve después del lanzamiento: tiene que formar parte del plan desde el principio: a quién afecta, qué cambia en su día a día, y quién resuelve dudas las primeras semanas mientras todo resulta poco familiar.
Las herramientas construidas con la opinión de quienes las van a usar suelen sobrevivir. Las impuestas desde arriba, por muy buenas que sean, suelen acabar esquivadas en silencio.
¿Qué pasa después del lanzamiento —o mejor dicho, qué suele no pasar?
Este es el tipo de fracaso más fácil de pasar por alto porque al principio no parece un fracaso. El proyecto se lanza, funciona, todo el mundo pasa a la siguiente prioridad. Seis meses después, nadie está comprobando si sigue siendo preciso, si sigue ahorrando el tiempo que debía ahorrar, o si ha empezado a dar respuestas incorrectas en un tipo de caso que nadie previó.
Los sistemas de IA no son "instalar y olvidar" como buena parte del software tradicional. Los datos cambian, aparecen casos límite, el propio negocio cambia. Sin alguien responsable de revisar coste, precisión y si la gente sigue usándolo de verdad, un sistema que funcionaba bien al lanzarlo se degrada poco a poco y nadie se entera hasta que ya está causando problemas.
Un periodo de seguimiento corto y de bajo coste después del lanzamiento detecta la mayor parte de esto a tiempo. Es una fracción del esfuerzo de la construcción original, y suele ser la diferencia entre un proyecto que sigue dando resultado y uno que se da por perdido en silencio un año después.
¿Los proveedores venden capacidad real o venden humo?
Hay una parte de este problema que las empresas no controlan directamente: buena parte de lo que se vende como "transformación con IA" se parece más al teatro que a la ingeniería. Demos impresionantes, promesas vagas, y muy poca conversación sobre qué pasa de verdad con el proceso por debajo. Cuando el proyecto no da resultado, se culpa a la tecnología, cuando el problema real fue que nadie fue honesto sobre lo que esa herramienta podía y no podía hacer para ese negocio concreto.
La versión honesta de este trabajo implica decir que no a veces: decirle a un cliente que lo que pide no va a resolver el problema que realmente tiene, o que un caso de uso no merece construirse porque el retorno no lo justifica. Es una propuesta de venta menos emocionante. También es la única que deja proyectos que siguen funcionando y siendo útiles un año después.
El patrón, resumido
Ninguna de las razones por las que fracasan los proyectos de IA es exótica. Caso de uso equivocado, proceso sin mapear, adopción saltada, sin seguimiento, proveedores que prometen de más. Nada de esto requiere mejores modelos: requiere tratar un proyecto de IA como se trataría cualquier cambio serio en cómo opera un negocio: entender primero el problema real, diseñar la solución alrededor de él, y seguir presente después de lanzarlo. No es un problema de tecnología. Es un problema de disciplina de proyecto, y tiene solución.