Por qué se cancelan los proyectos de agentes de IA: una revisión basada en evidencia

En junio de 2025, Gartner predijo que más del 40 % de los proyectos de IA agéntica se cancelarían antes de terminar 2027 por el aumento de costes, la falta de claridad sobre el valor empresarial o unos controles de riesgo insuficientes. Es una previsión de analistas, no una tasa de cancelación observada ni una conclusión sobre proyectos de Wavect. Consulta el comunicado original de Gartner.

En mayo de 2026, Gartner publicó otra previsión: para 2027, el 40 % de las empresas degradaría o retiraría agentes autónomos de IA debido a carencias de gobernanza descubiertas tras incidentes de producción. La unidad aquí son empresas, no proyectos, y el resultado es degradación o retirada. Por eso no debe mezclarse con la previsión anterior sobre cancelaciones. Véase la previsión de gobernanza de 2026.

Wavect no ha publicado un conjunto de datos completo, codificado de forma coherente y auditado de manera independiente que clasifique las causas de cancelación. Las ocho áreas siguientes son una lista de revisión derivada de la práctica de ingeniería y de guías públicas de riesgo, no frecuencias observadas, prueba causal ni garantía de arreglos baratos.

1. ¿Están explícitos el valor previsto y la regla de salida?

Empieza por la tarea, las personas afectadas, la línea base, el beneficio esperado, la tolerancia al riesgo y el responsable. Decide qué evidencia justificaría escalar, rediseñar, pausar o detener. Un agente capaz puede ser la intervención equivocada si la automatización convencional, la búsqueda o el rediseño del flujo resuelven el problema con menos riesgo.

No trates la continuidad del piloto como prueba de valor. Mide un resultado empresarial o de usuario aceptado, su fuente y el coste necesario para lograrlo. Registra los supuestos que dependan de adopción, cambios de proceso, precios de proveedores o equipos posteriores.

2. ¿Son las evaluaciones representativas del despliegue?

Una demostración con prompts o un conjunto pequeño elegido a mano no prueba el rendimiento en producción. Define casos de prueba, métricas y umbrales para la distribución real de tareas, casos límite críticos, errores fácticos y alucinaciones, rechazos, uso de herramientas y grupos afectados. Versiona las evaluaciones y revisa regresiones cuando cambien el modelo, el prompt, las herramientas, los datos o las políticas.

El núcleo del AI Risk Management Framework de NIST pide métodos documentados de prueba, evaluación, verificación y validación, mediciones en condiciones similares al despliegue, seguimiento en producción y supervisión humana definida. Consulta el AI RMF Core oficial. Un sistema de evaluaciones es útil, pero ninguna regla universal exige terminarlo en el primer sprint o incluir exactamente 20 intenciones. Adáptalo al impacto, la incertidumbre y la frecuencia de cambio. Nuestra práctica de QA y el glosario de TDD explican conceptos relacionados sin sustituir la evaluación específica de agentes.

3. ¿Se miden de extremo a extremo la fiabilidad y la latencia?

Mide la latencia percibida y el éxito del flujo completo, no una mediana aislada. Registra latencia por paso, tiempos de espera, reintentos, límites de uso, fallos parciales, efectos duplicados y disponibilidad de dependencias. Segmenta por tarea y entorno. No existe un umbral universal de latencia para el fracaso; la tolerancia depende del flujo y de la alternativa.

Paraleliza solo trabajo independiente, usa caché solo si la actualidad y la autorización lo permiten y haz idempotentes las escrituras cuando la operación lo admita. Elige un LLM y un presupuesto de razonamiento por tarea según calidad, latencia y coste medidos. Un modelo más barato no gana si incumple el umbral de aceptación o riesgo.

4. ¿Usa la economía unitaria resultados aceptados?

Las facturas pueden variar con el volumen, modelo, longitud del prompt, reintentos, llamadas a herramientas, caché y cambios de precio. Considera una anécdota de facturación o un ahorro arquitectónico como evidencia solo si documenta línea base, carga, umbrales de calidad y riesgo, y costes completos.

Mide el coste por intento, acción correcta, resolución aceptada y escalado humano. Incluye tokens, herramientas, recuperación de información, infraestructura, observabilidad, revisión, soporte y recuperación ante fallos. Compara arquitecturas con el mismo umbral de calidad y riesgo. RAG, prompts más cortos, caché u otras opciones de embeddings y almacenes vectoriales pueden ayudar, pero ninguna garantiza menor coste total sin medir.

5. ¿Están diseñados la supervisión, el traspaso y la recuperación?

Define qué decisiones necesitan aprobación, cuándo debe aplazar el sistema, quién recibe una escalada, qué contexto necesita y cómo se recupera el usuario de un error. Prueba permisos denegados, ausencia de personas, responsabilidad ambigua y acciones posteriores fallidas. La supervisión necesaria depende del impacto y de la ley aplicable.

No registres todo el contexto por defecto. Los logs pueden contener datos personales, confidenciales o sensibles para la seguridad. Captura solo la evidencia necesaria para operar, investigar y cumplir obligaciones, con control de acceso, retención, integridad y ocultación. El Generative AI Profile actualizado de NIST es un recurso voluntario y transversal para gobernar, mapear, medir y gestionar riesgos, no una certificación ni una garantía.

6. ¿Son adecuados los datos fuente y los permisos?

Una salida errónea puede proceder del modelo, la recuperación, las fuentes, las herramientas, la política o la orquestación. Diagnostica la capa antes de cambiar el prompt. Asigna responsables, procedencia, reglas de actualización, gestión de conflictos y revisiones de acceso. Prueba la recuperación con casos actuales y adversarios.

Aplica mínimo privilegio a documentos, API, credenciales y acciones. Conserva la autorización al recuperar y actuar, no solo al ingerir. La ingeniería de prompts no repara fuentes obsoletas ni un modelo de autorización que expone datos incorrectos.

7. ¿Está el alcance acotado por tareas y límites de confianza?

Un agente puede coordinar varias capacidades, pero cada tarea, herramienta y permiso adicional amplía la superficie de evaluación y fallo. Empieza con una tarea acotada y criterios explícitos de éxito. Añade capacidades cuando la evidencia respalde el siguiente nivel de riesgo. "Un agente, un trabajo, una evaluación" puede ser una heurística útil, no una ley universal de arquitectura.

Documenta qué componentes deciden, recuperan, ejecutan y aprueban. Separa lectura y escritura cuando sea útil. Prueba interacciones entre herramientas y escalado de permisos. La guía Map de NIST AI RMF pide documentar el alcance de la aplicación, los riesgos de componentes y la supervisión humana, no tratar todos los agentes igual.

8. ¿Se han asignado gobernanza y obligaciones legales al caso?

Una pista de auditoría no equivale a guardar todas las entradas y salidas. Decide qué decisiones y acciones requieren trazabilidad, la base jurídica y de seguridad para retener datos, quién puede inspeccionarlos, durante cuánto tiempo y cómo proteger su integridad. Para llamadas de MCP u otras herramientas, la identidad, el contexto de autorización, el resultado, la marca temporal y la versión pueden ser evidencia operativa útil, sujeta a minimización y seguridad.

El artículo 22 del RGPD no es una regla genérica de oposición a la IA. Trata decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o afecten de modo similar y significativo, con excepciones y salvaguardas. El artículo 22.3 incluye intervención humana, expresar el punto de vista e impugnar la decisión para determinadas excepciones. Consulta el texto oficial del RGPD y busca asesoramiento para el tratamiento concreto.

"Una revisión de agentes es creíble cuando la tarea, la evidencia, el límite de fallo, el responsable y la regla de salida son explícitos. Una demo correcta es solo una observación."

¿Qué evidencia debe contener la revisión?

Las áreas pueden interactuar, pero la tabla no refleja frecuencias observadas. Un tiempo de espera puede provocar reintentos, elevar costes y duplicar acciones. Registra la cadena en la evidencia del incidente o evaluación en vez de declarar un patrón universal.

¿Cuándo pausar, rediseñar o detener?

Fija umbrales antes de que el entusiasmo y el coste hundido distorsionen la decisión. Pausa ante fallos graves sin resolver de seguridad, privacidad, autorización o recuperación. Rediseña si son incorrectos la tarea, el flujo, el límite de herramientas o el plan de evidencia. Detén si el valor esperado ya no justifica el coste completo y el riesgo residual, o si una intervención más simple funciona mejor.

Cancelar puede ser una decisión sensata de gobernanza, no prueba de que fallaron la tecnología o la ingeniería. Del mismo modo, desplegar técnicamente no prueba éxito empresarial. Conserva la decisión, evidencia, responsable, opciones de corrección y condiciones para reconsiderar.

¿Qué demuestra la experiencia de Wavect?

Los casos publicados de Twinsoft AI, PromptID, Quivr y Hyperstate AI describen trabajos seleccionados. No forman una cohorte completa, establecen una tasa de cancelación ni clasifican causas. Los resultados empresariales posteriores requieren evidencia independiente y fechada, y no deben inferirse de un caso de entrega.

Wavect puede usar su experiencia para proponer pruebas, controles y opciones arquitectónicas. El responsable aún necesita evidencia actual para el caso, usuarios, proveedores, datos, derecho y entorno operativo concretos.