¿Por qué fracasan los proyectos de IA?
La demo funcionó. La reunión salió bien. Seis meses después el sistema sigue en un ambiente de pruebas y nadie quiere ser quien diga que hay que apagarlo. Ese recorrido tiene causas repetidas y ninguna es el modelo.
En resumen
El MIT mide que el 95% de los pilotos de IA no da retorno medible, sobre 52 entrevistas a directivos, 153 encuestas y 300 despliegues públicos. El problema del sector no es adoptar IA: es sostenerla.
RAND desglosa el fracaso y ahí está el dato incómodo: el 34% se abandona antes de producción, pero otro 28% sí se termina de construir y aun así no entrega el valor esperado. Ese segundo grupo es el que tiene un sistema andando que decepciona.
La causa más frecuente no es técnica: es que nadie definió qué respuesta era la correcta antes de empezar. Sin ese criterio, «funciona» es una opinión y la discusión nunca cierra.
El segundo motivo es el costo por consulta descubierto tarde. Un piloto de cien consultas al día cuesta nada; el mismo sistema a cien mil cambia la conversación con el área financiera.
Los números no son de un proveedor
Son del mercado, cada uno con su estudio detrás, y explican por qué la mayoría de las implementaciones decepciona.
Siete formas de perder el proyecto
- Nadie definió qué es una respuesta correctaSin un conjunto de preguntas reales con su respuesta esperada, cada revisión es una discusión de gustos. El proyecto no muere: se estanca en una ronda infinita de ajustes.
- El costo por consulta apareció al finalEl piloto costaba centavos. En producción, con el contexto completo y diez veces el volumen, la factura mensual del modelo supera lo que se ahorró en personal.
- La recuperación era mala y se culpó al modeloSi el fragmento que servía nunca llegó al prompt, ningún modelo puede responder bien. Es el fallo más común y el más fácil de confundir con «el modelo alucina».
- El sistema nunca aprendió a decir que no sabeUn asistente que siempre responde con la misma seguridad hace que el primer error grave destruya la confianza acumulada durante meses.
- No había dueño después de la entregaEl proveedor entregó, el equipo interno tenía otras prioridades y el sistema envejeció solo. La base documental cambió y la recuperación se degradó sin que nadie lo notara.
- Se automatizó un proceso que nadie había ordenadoLa IA sobre un proceso caótico produce caos más rápido. Si las reglas no están claras para una persona, el modelo no las va a inferir.
- Se compró una demo, no un sistemaMontar la demo es un fin de semana. Sostenerla exige manejo de errores, límites de gasto, trazas, permisos y alguien de guardia. Eso es lo que casi nunca está en la cotización.
El modelo casi nunca es el problema
Cuando un sistema responde mal, la reacción habitual es cambiar de modelo. A veces ayuda; casi siempre tapa el síntoma. En la mayoría de los casos que llegan a un diagnóstico, el modelo estaba recibiendo información incompleta, contradictoria o directamente equivocada, y respondía con lo que tenía.
Separar las dos cosas es barato y se hace en una tarde. Se toman treinta preguntas reales, se revisa manualmente si el fragmento correcto apareció entre lo recuperado, y ahí queda claro dónde está el fallo. Si la recuperación falla, el trabajo está en la segmentación, el reordenamiento y la búsqueda híbrida. Si la recuperación acierta y la respuesta sigue mal, entonces sí es el prompt o el modelo.
El costo de saltarse ese paso es alto: equipos que cambiaron tres veces de proveedor de modelo persiguiendo un problema que estaba en cómo se partieron los documentos.
Seis preguntas que revelan si el proyecto va bien
- ¿Existe un conjunto de preguntas de prueba con su respuesta correcta? ¿Cuántas?
- ¿Cuál es el recall@k de la recuperación hoy, y cuál era hace tres meses?
- ¿Cuánto cuesta una consulta, y cuánto costaría a diez veces el volumen actual?
- ¿Qué hace el sistema cuando no encuentra la respuesta? ¿Lo dice o improvisa?
- ¿Quién revisa mensualmente lo que el asistente no supo responder?
- ¿Cuánto tarda en llegar a producción un cambio de prompt, y quién lo aprueba?
Un diagnóstico serio dura una semana y termina con hallazgos concretos, cada uno con su arreglo y su esfuerzo estimado. No con una presentación de cuarenta láminas.
Si el diagnóstico no llega a al menos tres hallazgos accionables, no lo cobramos.
Preguntas frecuentes
¿Qué porcentaje de proyectos de IA fracasa?
El MIT mide que el 95% de los pilotos de IA no produce retorno medible («The GenAI Divide», 2025), y RAND que los proyectos de IA fracasan al doble de la tasa de un proyecto de software normal (2024). El desglose de RAND es más útil que el titular: 34% se abandona antes de producción, 28% se termina de construir y no entrega el valor esperado, y 18% entrega algo pero no lo suficiente para justificar el costo. El cuello de botella está entre el piloto y la operación, no en la adopción inicial.
¿Cuál es la causa más común de que un chatbot responda mal?
La recuperación, no el modelo. Si el fragmento que contenía la respuesta nunca llegó al prompt, el modelo responde con lo que tiene y eso se ve como una alucinación. Antes de cambiar de modelo conviene revisar manualmente treinta preguntas reales y comprobar si el contenido correcto estaba entre lo recuperado.
¿Se puede rescatar un proyecto de IA que ya falló?
En la mayoría de los casos, sí, y sale más barato que empezar de cero. Lo que se rescata casi siempre es la integración, los permisos y el conocimiento del dominio, que es donde se fue el tiempo. Lo que se rehace suele ser la segmentación de documentos, la estrategia de recuperación y el manejo de errores. El diagnóstico previo es lo que separa un rescate de una reescritura disfrazada.
¿Cuánto tiempo toma llevar un piloto a producción?
Entre cuatro y ocho semanas cuando el piloto está bien hecho, y ese trabajo casi nunca es de modelo: es conjunto de evaluación, permisos por usuario, manejo de errores, control de costo, trazas y un plan de operación. Cuando el piloto se hizo sin ninguna de esas piezas, la ruta a producción se parece más a construirlo de nuevo con el aprendizaje del primero.
¿Cómo evito que pase de nuevo?
Definiendo el criterio de aceptación antes de empezar. Treinta a cincuenta preguntas reales con su respuesta correcta, escritas por quien conoce el negocio, y dos números objetivo: qué tan seguido el sistema encuentra la información que servía y qué tan seguido la respuesta se sostiene en esa información. Con eso, cualquier cambio se puede evaluar en horas en lugar de discutirse en reuniones.