Proyecto de IA fallido: cómo saber si se puede rescatar (y cuándo cancelar)

Usted invirtió en inteligencia artificial (IA) y hoy tiene un sistema que casi nadie usa, una factura mensual que no baja, y una duda que no lo deja tranquilo: ¿el problema es la tecnología, o es el proveedor que se la vendió?

Es la pregunta correcta, y casi nadie se la responde de frente. El proveedor que se lo entregó tiene un incentivo obvio para decirle que “es cuestión de seguir iterando”: más horas, más presupuesto. Y usted, que ya puso entre USD 10,000 y USD 80,000, no sabe si está a un ajuste de que funcione o tirando plata buena sobre plata mala.

Este artículo le da criterio técnico —no comercial— sobre tres cosas: por qué fracasan de verdad los proyectos de IA, cómo saber si el suyo se rescata, y cuándo lo honesto es cancelar. No todo se salva, pero mucho de lo que parece muerto solo está mal armado.

El 95% no es un problema de tecnología

Si su proyecto de IA no dio resultados, usted es la norma, no la excepción.

Según estudios de MIT y RAND (2024-2025) —el más citado es el del proyecto NANDA del MIT—, alrededor del 95% de los pilotos de IA empresarial no llegan a producción o no generan retorno medible. La mayoría fracasa por las mismas causas técnicas, repetidas y perfectamente diagnosticables.

“La tecnología no está madura” casi nunca es la razón. Los modelos de 2026 son más que capaces. Lo que falla está antes y alrededor del modelo. Esto es lo que encontramos una y otra vez al abrir el capó de un proyecto fallido:

Se eligió el caso de uso equivocado. El error más caro y el más común. Alguien decidió “hagamos algo con IA” y buscó dónde meterla, en vez de partir de un problema costoso y preguntarse si la IA era la herramienta. Un chatbot para un proceso que se consultaba dos veces por semana. La IA funciona, pero resuelve algo que no valía la pena.

Los datos estaban sucios. Un modelo no inventa la verdad a partir de datos malos. Si su base tiene duplicados, campos vacíos y “CDMX” y “D.F.” como ciudades distintas, la IA hereda ese desorden y lo sirve con cara de certeza. Si entra basura, sale basura, ahora más rápido.

El chatbot alucina porque no tiene RAG, o lo tiene mal. Cuando un asistente “inventa” respuestas —precios que no existen, políticas que nadie escribió— casi siempre es porque responde de memoria en vez de consultar sus documentos primero. Lo arregla la generación aumentada por recuperación (RAG, por las siglas en inglés de Retrieval-Augmented Generation): antes de responder, el sistema busca el fragmento correcto en la documentación de la empresa y obliga al modelo a responder solo sobre eso, citando la fuente. Muchos proyectos fallidos no tienen RAG, o lo hicieron mal: troceado pésimo de los documentos, sin filtros, sin obligar la cita. Lo detallo en RAG para empresas.

Los prompts estaban mal diseñados. El “prompt” es la instrucción que se le da al modelo. Suena trivial; no lo es. Una instrucción vaga, sin ejemplos ni reglas de qué hacer cuando el modelo no sabe, produce un sistema que responde cualquier cosa. Mucho de lo que se vende como “el modelo no sirve” se arregla reescribiendo el prompt con criterio.

Nadie midió nada. La falla más silenciosa. El proyecto arrancó sin línea base: cuánto costaba el proceso antes, cuánto tarda ahora, qué porcentaje de respuestas son correctas. Sin métricas nadie puede afirmar si funciona, y “sensación de que no sirve” no es “no sirve”. A veces el sistema anda bien y lo que faltó fue medir el retorno de la inversión (ROI) para demostrarlo.

Los costos de tokens se dispararon. Los modelos cobran por “token”, fragmentos de palabra que son la unidad con la que se factura cada consulta. Un sistema mal diseñado manda demasiado texto en cada llamada, o usa el modelo más caro para lo que uno barato resolvía igual. “Funciona”, pero cuesta tres veces lo que debería y nadie entiende por qué la factura sube sola.

El agente nunca manejó errores ni llegó a producción. Un agente de IA —que además de responder ejecuta acciones: consultar, agendar, cotizar— se ve espectacular en una demo controlada. En producción, un caso raro o una respuesta inesperada de una interfaz de programación (API) lo tumban, porque nadie programó el manejo de errores. Queda en “demo eterna”: impresiona en la reunión, jamás se suelta con clientes reales.

Fíjese en el patrón: ninguna es “la IA no funciona”; todas son de diseño, de datos o de ingeniería. Por eso muchos proyectos son rescatables.

Cómo saber si el suyo se puede salvar

La diferencia entre rescatable y no rescatable rara vez está en el modelo de IA: está en lo que lo rodea.

Señales de que probablemente sí se puede rescatar

El caso de uso era correcto, la ejecución no. El problema que se quiso resolver sí duele y sí valía la pena; falló el cómo. Es lo más rescatable que existe: la idea era buena, hay que rehacer la ingeniería.
Los datos existen y son recuperables. Están sucios, dispersos o mal estructurados, pero están. Limpiarlos es trabajo conocido y acotado. La ausencia total de datos es otra historia.
El sistema acierta al menos a veces. Si acierta el 60% de las veces, el problema es de calibración, no de concepto; un sistema inconsistente casi siempre se estabiliza.
El costo es el problema, no la función. Si hace lo que debe pero cuesta un absurdo, es de lo más fácil de arreglar: cambiar de modelo, optimizar las llamadas, reducir el texto que se manda. Aquí son comunes reducciones del 40% al 70%.

Señales de que no vale la pena (o hay que reconstruir)

El caso de uso estaba mal desde el día uno. Si la IA se aplicó a un problema que no genera valor —o que se resolvía con una hoja de cálculo bien hecha—, ningún arreglo técnico lo salva. No se refactoriza un error de estrategia.
No hay datos, y conseguirlos cuesta más que el proyecto. Si capturarlos implica meses de trabajo manual, el rescate se vuelve otro proyecto, más caro que el original.
La arquitectura es una caja negra sin documentación. El proveedor se fue, el código es indescifrable y nadie sabe cómo está armado. A veces reconstruir desde cero sale más barato y más seguro que descifrar el desastre ajeno.
El proceso de negocio ya cambió. Si lo que el sistema automatizaba ya no se hace así, no hay nada que rescatar.

Estas señales orientan, no sentencian: la única forma seria de saberlo es auditar el proyecto. Pero si reconoció el suyo en la primera lista, hay buenas probabilidades de salvarlo.

Los tres caminos: parche, refactor o reconstrucción

Cuando un proyecto es rescatable, hay tres formas de arreglarlo, y elegir mal el camino es cómo se gasta el segundo presupuesto igual que el primero.

Parche: cirugía puntual

Se cambia lo mínimo indispensable: se reescriben los prompts, se ajusta la configuración, se arregla el manejo de errores del agente, se optimiza qué modelo se llama y con cuánto texto.

Cuándo: el sistema está bien concebido y bien construido, pero tiene defectos localizados. El caso clásico es el chatbot que alucina por un RAG sin afinar, o el agente que se cae por un error no controlado. Semanas, no meses.

El riesgo: parchar lo que en realidad necesita refactor. Si el problema es estructural, el parche lo tapa un mes y vuelve.

Refactor: rehacer las partes podridas

Se conserva lo que sirve —la idea, los datos, parte de la infraestructura— y se reconstruyen los componentes malos: se rediseña la recuperación, se reestructuran los datos, se reemplaza lo que no aguanta producción, pero no se empieza de cero.

Cuándo: el concepto es correcto y algo de lo construido es aprovechable, pero hay piezas que no se arreglan con un parche. Es el camino más común en un rescate real: la mayoría de los proyectos fallidos mezclan piezas salvables con piezas para tirar.

El riesgo: subestimar cuánto hay que rehacer. Un refactor mal delimitado se vuelve reconstrucción encubierta: paga el costo de reconstruir sin sus beneficios.

Reconstrucción: empezar de nuevo con lo aprendido

Se descarta el sistema y se rehace desde los cimientos. No es un fracaso: es reconocer que la base no aguanta y remendarla cuesta más que rehacerla. La ventaja frente al original es enorme: ya sabe qué salió mal, tiene los datos y sabe qué necesita.

Cuándo: la arquitectura es indescifrable o insostenible, no hay documentación, o lo construido no escala a lo que la empresa necesita. Si mantenerlo cuesta más que rehacerlo, reconstruir es lo racional.

El riesgo: reconstruir por orgullo de ingeniería cuando bastaba un refactor. Rehacer desde cero solo se justifica cuando los números lo respaldan.

La pregunta que ordena los tres caminos es una: ¿cuánto de lo que ya existe sirve? Ponerle número a esa respuesta es, literalmente, el trabajo de la auditoría.

Cuándo la respuesta honesta es cancelar

Aquí nos separamos de casi cualquier proveedor que le cotice un rescate: a veces la mejor recomendación técnica es no seguir con IA.

Cancelar con criterio es una decisión de negocio válida, y a veces la única sensata:

El caso de uso no genera retorno, sin importar la ejecución. Si aun funcionando perfecto ahorraría menos de lo que cuesta operarlo, no hay ingeniería que lo salve.
El problema se resuelve mejor sin IA. Muchas cosas vendidas como “IA” eran, en el fondo, una automatización simple o un buen reporte. Si una regla de negocio de diez líneas hace lo mismo que un modelo caro, la regla gana.
El costo de operarlo supera el valor por un margen que no cierra ni optimizando. Aun bajando el gasto un 70%, si la ecuación sigue en rojo, se apaga.

Por qué le conviene: un “cancele esto” fundamentado, con las razones y la cuenta hecha, vale tanto como un sistema funcionando y le ahorra el goteo mensual de operar algo que nunca iba a pagar. Un proveedor que solo sabe decir “sí, lo arreglamos” le cobrará por rescatar lo irrescatable.

Qué exigir en una auditoría de rescate

Si va a pagar por rescatar un proyecto de IA —a nosotros o a cualquiera—, esto es lo mínimo que debe recibir. Si le ofrecen menos, le venden horas, no criterio.

Auditoría técnica honesta, por escrito. Qué funciona, qué no y qué se puede salvar, con nombres y detalles, no un “está mal, hay que rehacer” genérico. Si no entienden por qué falla, no lo van a arreglar.
Análisis de los costos actuales. Cuánto paga hoy en modelos, infraestructura y mantenimiento, y dónde se va la plata. Sin esa foto no hay forma de prometer un ahorro real.
Un plan con los tres escenarios costeados. Parche, refactor y reconstrucción, cada uno con precio, plazo y resultado esperado. Que decida con las tres opciones sobre la mesa, no con la única que al proveedor le conviene vender.
La opción de cancelar, sobre la mesa. Si nadie contempla que la respuesta sea “no siga”, nadie será honesto cuando esa sea la correcta.
Documentación completa y transferencia a su equipo. Al terminar, su gente tiene que poder mantener el sistema. Si queda más dependiente del proveedor que antes, el rescate falló aunque el sistema funcione. La independencia técnica es parte del entregable, no un extra.

Esos cinco puntos son, exactamente, el alcance de nuestro Rescate de Implementación de IA (USD 5,000–15,000, de 4 a 6 semanas), sumando la implementación del escenario que se elija. El resultado típico es un sistema de IA funcionando como se prometió —con una reducción del 40% al 70% en el costo de operarlo— o la claridad técnica para cancelar sin seguir sangrando. Las dos son victorias.

En resumen

Alrededor del 95% de los proyectos de IA no llegan a producción ni dan retorno (MIT y RAND, 2024-2025), y casi nunca por “la tecnología”: es caso de uso mal elegido, datos sucios, RAG mal hecho, prompts flojos, cero medición, tokens descontrolados o agentes sin manejo de errores.
Es rescatable cuando el caso de uso era correcto, los datos existen y el sistema acierta al menos a veces. Es para cancelar cuando el caso de uso estaba mal de raíz o rescatarlo cuesta más que rehacerlo.
Hay tres caminos según cuánto de lo existente sirva: parche (defectos puntuales), refactor (rehacer lo podrido conservando lo bueno) y reconstrucción (empezar de cero con lo aprendido).
Cancelar con criterio es legítimo: la razón técnica para cerrar una inversión vale tanto como el sistema funcionando, y le ahorra el costo mensual de algo que no iba a pagar.
Exija: auditoría honesta por escrito, análisis de costos, plan con los tres escenarios costeados, la opción de cancelar sobre la mesa y transferencia de conocimiento para no quedar dependiente.
Un rescate bien hecho reduce típicamente entre 40% y 70% el costo de operar el sistema y le deja independencia técnica.

Próximo paso

Rescate de Implementación de IA — Auditamos qué falló y lo dejamos funcionando, o le decimos si conviene cancelar (USD 5,000–15,000)
Diagnóstico Operativo Express — Si aún no invirtió y quiere evitar el error desde el principio (USD 1,500)
Agendar sesión exploratoria sin costo — 45 minutos para revisar su caso y decirle honestamente si tiene arreglo