Un proyecto de inteligencia artificial rara vez fracasa por la inteligencia artificial. Los modelos actuales funcionan bien. Lo que falla está alrededor, y casi siempre era visible en la primera reunión — si uno sabía qué mirar.
Causa 1: empezar por la tecnología
El patrón se repite: alguien de la dirección ve una demo impresionante, se aprueba un presupuesto para «hacer IA», y entonces se busca dónde aplicarla. Es el orden inverso al que funciona. Un proyecto que nace de una herramienta buscando problema produce demos exitosas y operaciones que no cambian.
Señal temprana: si el proyecto tiene presupuesto antes de tener un indicador operativo que mejorar, ya está en problemas. No importa qué tan bueno sea el equipo que lo ejecute.
Causa 2: los datos no estaban listos y nadie lo dijo
Es la causa más frecuente y la más evitable. La IA amplifica el estado de tus datos: si están desordenados, produce respuestas desordenadas con mucha seguridad, que es la peor combinación posible. Lo grave no es que los datos estén mal — es normal. Lo grave es que a menudo el proveedor lo sabe y no lo dice, porque decirlo pone en riesgo la venta.
Una propuesta seria de IA incluye una evaluación honesta del estado de los datos antes de prometer resultados. Si nadie te ha preguntado dónde vive tu información y en qué condiciones está, no te están vendiendo un proyecto: te están vendiendo un presupuesto.
Causa 3: el piloto que nunca iba a escalar
Los pilotos se diseñan para demostrar y no para operar. Se ejecutan con datos escogidos, sin las excepciones reales, sin la carga real y sin los usuarios reales. Después el piloto funciona, todo el mundo aplaude, y al llevarlo a producción aparecen los casos que nadie modeló: el cliente que escribe con faltas, el producto descatalogado, el proceso que en la práctica se hace distinto a como está documentado.
Señal temprana: pregunta quién va a usar esto el día 200. Si nadie ha pensado esa respuesta, estás financiando una demo, no un sistema.
Causa 4: nadie es dueño del sistema
El proyecto lo impulsa la gerencia, lo construye un proveedor, y cuando termina no queda claro de quién es. El área de TI no lo pidió y no lo entiende. El área de negocio no puede modificarlo. El proveedor ya facturó. Seis meses después nadie lo actualiza y muere sin que se tome ninguna decisión de matarlo.
Este es también el motivo por el que el recelo del área de TI hacia un proveedor externo suele estar justificado: han visto esta película y saben quién se queda con el muerto.
Causa 5: se midió el entusiasmo, no el resultado
«El equipo está muy contento con la herramienta» no es un indicador. «Pasamos de 40 a 6 horas mensuales en este proceso» sí lo es. Cuando un proyecto de IA no puede mostrar un número que cambió, normalmente es porque no cambió nada — y el entusiasmo tiene fecha de caducidad corta.
Las señales tempranas, en una lista
Si reconoces tres o más, revisa el proyecto
- ✓Hay presupuesto pero no hay un indicador operativo definido.
- ✓Nadie ha auditado el estado de los datos antes de la propuesta.
- ✓El área de TI no participó en la evaluación, o participó en silencio.
- ✓El éxito se va a medir con una demo ante la gerencia.
- ✓No está definido quién mantiene el sistema al año siguiente.
- ✓El proveedor no ha dicho «no» a nada de lo que le pediste.
Cómo se ve un proyecto que sí funciona
Empieza por un cuello de botella medible y acotado. Define el número que debe moverse antes de escribir código. Evalúa los datos con honestidad, aunque eso retrase el inicio. Nombra a un dueño interno que se quede con el sistema. Y contempla que la respuesta correcta pueda ser que la IA no era la herramienta — en cuyo caso te ahorraste el proyecto entero.
En Indicium esa evaluación es parte del discovery y no tiene costo. A veces termina con un proyecto, a veces con la recomendación de resolverlo con una automatización simple, y a veces con que primero hay que ordenar los datos. Las tres son respuestas útiles.
¿Listo para el siguiente paso?
Evaluemos tu caso — sin costo