El 90% de los fracasos en proyectos de IA: las deudas de indicaciones, de recuperación y de evaluación están socavando la implementación empresarial

En 2025, el 42% de las empresas detuvieron varios proyectos de IA, más del doble del 17% del año anterior.
El problema no radica en que los modelos no sean lo suficientemente fuertes, sino en que una nueva forma de deuda tecnológica se acumula silenciosamente en la infraestructura de IA de las empresas, incluyendo deuda en prompts, deuda en recuperación y deuda en evaluación.
(Resumen previo: ¿Qué es Harness Engineering? Desglose de los 7 módulos principales para la implementación real de un Agente de IA (Ingeniería para dominar la IA))
(Información adicional: GPT-5.5 Instant está disponible para todos los usuarios, OpenAI te enseña cómo escribir prompts de manera más inteligente y eficiente)

Índice de este artículo

Alternar

• Tres tipos de nuevas deudas, más difíciles de detectar que los bugs
• Brechas invisibles en la supervisión
• La solución no está en el modelo, sino en el diseño del sistema

El 42%, esa es la proporción de empresas que en 2025 detuvieron múltiples proyectos de IA, más del doble que el año anterior.
Datos de S&P Global Market Intelligence muestran que los fracasos en IA no son eventos aislados, sino problemas sistémicos.
Un estudio del MIT ese mismo año señala que el 95% de los pilotos de IA nunca entran realmente en producción ni generan valor comercial cuantificable.

Estos fracasos suelen atribuirse a capacidades insuficientes del modelo, mala calidad de los datos o dificultades para justificar el ROI.
Pero Vikram, director de Cota Capital, cree que la causa real es más oculta:
una forma de deuda tecnológica emergente se acumula silenciosamente en las capas de prompts, dependencia del modelo y evaluación, diferente a la deuda de código tradicional, pero igualmente mortal.

Tres tipos de nuevas deudas, más difíciles de detectar que los bugs

La deuda tecnológica tradicional reside en los repositorios de código, donde los bugs pueden ser reproducidos, testeados y corregidos.
La deuda en IA tiene características completamente diferentes:
es descentralizada, dispersa en prompts, APIs de modelos, pipelines de datos y en la infraestructura.

Es intermitente, porque los sistemas de IA son inherentemente probabilísticos;
el mismo input no garantiza el mismo output;
y casi invisible, porque el sistema "parece" funcionar normalmente hasta que en un momento clave, colapsa por completo.

Deuda en prompts (Prompt Debt) es la más evidente de las tres.
No hay registros temporales de ajustes, sin control de versiones en los prompts, y el "relleno de prompts" inserta información irrelevante en masa, intentando que el modelo entienda más.

El resultado es que los prompts se convierten en un código informal, sin tipos, sin pruebas, sin gestión de versiones.
Cada ajuste es una modificación en un sistema opaco; acumulándose, la vulnerabilidad del sistema crece exponencialmente.

Deuda en dependencia del modelo (Model Dependency Debt) surge de la alta dependencia de APIs de modelos externos.
La lógica de la aplicación se basa en llamadas a modelos externos, pero estas actualizaciones no están bajo control de la empresa.

Cuando el proveedor del modelo actualiza silenciosamente la versión, los prompts ajustados para versiones anteriores pueden fallar, o el comportamiento de salida puede driftar impredeciblemente.
La reproducibilidad desaparece.

Deuda en recuperación (Retrieval Debt) aparece en la mayoría de las implementaciones de IA con arquitectura RAG.
El problema es que los repositorios de datos están llenos de información desordenada, archivos duplicados y datos obsoletos.
Por eso, las respuestas de IA, aunque técnicamente correctas en su momento, ya no son válidas.
Es más difícil de detectar que las alucinaciones, porque parecen completamente razonables y pueden pasar incluso por revisiones de testers comunes.

Brechas invisibles en la supervisión

Deuda en evaluación (Evaluation Debt) es la más subestimada de las cuatro.
Las métricas de referencia actuales en IA se centran en evaluaciones puntuales y de alcance limitado, que no reflejan el rendimiento real en producción.
La mayoría de las empresas carecen de estándares de prueba consistentes, conjuntos de datos de referencia y mecanismos de monitoreo en tiempo real de los modelos desplegados.

En comparación con el desarrollo de software tradicional, que ya cuenta con procesos maduros de CI/CD (integración y entrega continua), en IA aún no existe un mecanismo equivalente de "integración continua de prompts".

En términos simples:
los ingenieros pueden hacer merge de código con pruebas automáticas que detectan errores;
pero cuando un prompt se modifica, no hay ningún sistema que alerte inmediatamente.
Como resultado, los CIO y CTO carecen de visibilidad sobre el rendimiento real del modelo y no pueden rastrear si la eficiencia se está deteriorando.

Estas cuatro nuevas deudas, sumadas a la deuda técnica de código, aceleran su acumulación compuesta.
Y lo peor es que la propiedad de los sistemas de IA es dispersa: los equipos de ingeniería, producto, datos y negocio controlan diferentes partes, y cuando algo falla, la responsabilidad suele ser difusa.

La solución no está en el modelo, sino en el diseño del sistema

Tener modelos más precisos no resolverá este problema.
Vikram argumenta directamente:
las altas tasas de fracaso no están relacionadas con la precisión del modelo, sino con el diseño del sistema, la integración y la cultura organizacional.

Específicamente, los prompts deben tratarse como código, con control de versiones, documentación adicional y pruebas rigurosas antes y después de su despliegue, considerando todas las configuraciones posibles.

Los mecanismos de evaluación deben integrarse en toda la pila de infraestructura de IA, estableciendo pipelines de evaluación continua que cubran métricas técnicas y de negocio, y que integren sistemas de observabilidad de IA para monitorear la calidad de salida, tasas de fallo, drift del modelo y drift de datos.

Además, todos los resultados de IA deben incluir explicaciones interpretables, con fuentes de datos, modelos utilizados y pasos ejecutados, de modo que sean auditables y puedan corregirse rápidamente ante errores sistémicos.

Esto requiere, como en la inversión en ciberseguridad o modernización en la nube, establecer planes claros para eliminar la deuda en IA y presupuestos dedicados, liderados directamente por los ejecutivos de nivel CXO.

Habiendo dicho todo esto, ahora puedes entender:
el 95% de los fracasos no se deben a que la IA no sea lo suficientemente inteligente, sino a que la forma en que construimos sistemas de IA todavía se basa en tratarlos como cajas negras API, en lugar de sistemas complejos que requieren ingeniería rigurosa.
La deuda tecnológica nunca desaparece por sí sola; solo se acumula y, en algún momento, se paga con intereses más altos.