Por qué fracasan los proyectos de IA (y casi nunca es la tecnología)
La mayoría de los proyectos de IA no mueren por falta de un buen modelo. Mueren por tres fallas de gestión que aparecen mucho antes de la parte técnica.
Cuando un proyecto de IA fracasa, la conclusión fácil es culpar a la tecnología. El modelo no era bueno, la herramienta era limitada, faltó capacidad técnica. En la práctica que veo, la tecnología rara vez es la causa. Los modelos de hoy son suficientemente buenos para la mayoría de los problemas de negocio. Lo que falla viene antes, y es gestión.
Tres patrones aparecen en la enorme mayoría de los casos.
1. Un problema mal definido
El proyecto empieza con "queremos usar IA" en vez de "queremos mejorar esta decisión". Sin una decisión concreta en el centro, el equipo persigue un blanco que cambia cada semana. La demo impresiona, pero nadie sabe decir qué cambió en la operación. Seis meses después, el proyecto es un piloto eterno que nunca llega a producción, porque nunca tuvo un criterio claro de éxito.
El síntoma es fácil de detectar. Si preguntas "qué decisión mejora esto" y recibes una respuesta vaga, el problema aún no está definido. Y ningún modelo arregla la falta de definición.
2. Sin métrica y sin línea base
El segundo patrón es no medir. El equipo enciende el modelo, ve algunas salidas buenas en una demo controlada y declara el éxito. Cuando alguien pregunta cuánto mejoró de verdad, no hay respuesta, porque no había número antes.
Una métrica no es burocracia. Es lo que separa "parece que funcionó" de "funcionó". Define la métrica principal y registra la línea base antes de encender cualquier cosa. Sin eso, no puedes defender la inversión, repetir el acierto ni cortar lo que no funcionó.
3. Nadie es dueño del proceso
El tercer patrón es un proceso huérfano. La IA entra, cambia el flujo de trabajo y no queda claro quién es responsable del proceso en su nueva forma. ¿Quién revisa las excepciones? ¿Quién ajusta cuando el resultado se degrada? ¿Quién responde cuando el cliente reclama?
Sin dueño, la herramienta se vuelve tierra de nadie. Funciona unas semanas y luego se pudre, porque mantener vivo cualquier sistema exige a alguien a quien le importe su resultado. Tecnología sin dueño es deuda, no un activo.
El denominador común
Nota que ninguna de las tres fallas es técnica. Todas son decisiones de gestión que ocurren antes de la primera línea de código. Por eso cambiar de proveedor o de modelo casi nunca rescata a un proyecto que nació torcido. Cambias la pieza y mantienes la causa.
La buena noticia es que lo contrario también es cierto. Un problema bien definido, con métrica y dueño claro, sobrevive incluso a una tecnología mediocre. Acierta la gestión y la parte técnica resulta sorprendentemente simple.
Una prueba de 30 segundos
Antes del próximo proyecto, responde tres cosas:
- ¿Qué decisión específica mejora esto?
- ¿Cuál es la métrica y cuál es el número de hoy?
- ¿Quién es el dueño del proceso una vez que la IA entre?
Si las tres respuestas salen rápidas y específicas, vas por buen camino. Si se traban, el riesgo no está en el modelo. Está en la mesa.