Por Qué el 40% de los Proyectos de AI Agents Se Cancelan: Modos de Fallo que Hemos Vivido
Gartner publicó una cifra sugiriendo que alrededor del 40 por ciento de los proyectos enterprise de AI agents se cancelan para 2027. Desde nuestro asiento construyendo sistemas de agents en DACH y la UE, las cancelaciones no son misteriosas. Se agrupan en 8 modos de fallo. Cada uno tiene una señal, cada uno mata el proyecto de una forma distinta, y la mayoría tienen un fix barato si los atrapas en el primer mes en lugar del sexto. Este post es el post-mortem que nos hubiera gustado que alguien escribiera antes de nuestro primer build de agent.
La base de evidencia. Engagements de Wavect en productos de agents y de IA incluyendo Twinsoft AI, PromptID, Quivr y Hyperstate AI (lanzado con éxito; luego se quedó sin financiación después del launch, no un fallo de producto o tech).
¿Proyecto de agent en riesgo?
Reserva Consultoría GratuitaModo de fallo 1. Alucinación como asesina de confianza
La señal. Dos respuestas equivocadas confiadas en una demo. El equipo parchea el prompt. Siguiente demo, dos respuestas más equivocadas de forma distinta.
Cómo mata el proyecto. La confianza no decae linealmente. Una respuesta demostrablemente equivocada delante de un exec vale por diez éxitos silenciosos. El agent se vuelve "esa cosa de IA que miente" y el presupuesto se va.
El fix barato si se atrapa temprano. Restringe el espacio de acción. Un agent que dice "no puedo responder esto desde las fuentes provistas, aquí está el humano más cercano en el loop" le gana a un agent que confabula. Construye el camino de rechazo antes que el happy path.
Modo de fallo 2. Apilamiento de latencia de tool-use
La señal. La latencia P50 se ve bien en aislamiento. La latencia P95 de cara al usuario en tareas multi-paso es de 25 a 45 segundos.
Cómo mata el proyecto. Los usuarios abandonan el agent por el flujo manual que estaban intentando reemplazar. La adopción se aplana. El CFO pregunta por qué estamos pagando por tokens que nadie usa.
El fix barato. Mide la tail latency por tool call desde la semana uno. Paraleliza las tool calls donde el orden no sea load-bearing. Cachea reads idempotentes. Elige un tier de LLM por paso, no por agent. El modelo más barato que satisface la tarea gana.
Modo de fallo 3. Eval-debt acumulándose
La señal. El equipo lanza un cambio de prompt. Nadie sabe si mejoró algo. Regression testing basado en vibes en un thread de Slack.
Cómo mata el proyecto. Sin evals, cada cambio es una apuesta. El sistema deriva. Después de ocho sprints, nadie confía lo bastante en el agent como para exponerlo a usuarios reales. El proyecto silenciosamente deja de priorizarse.
El fix barato. TDD para agents. Construye el eval harness en el sprint uno. Tests de golden-set para las 20 intenciones de usuario top. Pass-rate como puerta de deployment. Hemos escrito sobre esto en nuestra práctica más amplia de QA y aplica el doble para agents.
Modo de fallo 4. Cost-per-action superando la economía unitaria
La señal. La primera factura del provider de LLM está bien. La tercera factura es 12x.
Cómo mata el proyecto. El CFO pide la economía unitaria. El coste por ticket resuelto excede el margen bruto. El agent es técnicamente exitoso y comercialmente muerto.
El fix barato. Trackea cost-per-action desde el día uno. Selección de modelo por paso. Acortamiento agresivo de prompts. Caching de contexto estático. RAG con embeddings más pequeños le gana a meter 200k tokens de contexto en el prompt. Hemos visto reducciones de coste de 4 a 8x desde elecciones arquitectónicas que tomaron una semana implementar.
Modo de fallo 5. Diseño de human-handoff ausente
La señal. El agent funciona para el 80 por ciento de los casos. El otro 20 por ciento no tiene escape. Los usuarios se quejan a soporte. Soporte no puede ver lo que hizo el agent.
Cómo mata el proyecto. Los equipos de cara al cliente construyen un workaround paralelo. El agent se vuelve un Tier-0 que rodean. El coste de operar ambos flujos mata el case para cualquiera.
El fix barato. Diseña el handoff antes de la autonomía. Cada acción de agent logueada con contexto completo. Escalation de un click a un humano con el historial de conversación adjunto. Política clara sobre qué debe diferir el agent.
Modo de fallo 6. Problemas de calidad de datos disfrazados de problemas de agent
La señal. El agent devuelve respuestas equivocadas desde la base de conocimiento. El equipo afina el prompt. Nada mejora.
Cómo mata el proyecto. El equipo está arreglando la capa equivocada. Los datos fuente están obsoletos, contradictorios o equivocados. Ningún prompt arregla eso. Meses desaparecen en prompt engineering sobre fundaciones podridas.
El fix barato. Audita el corpus fuente antes de escalar el agent. Owner por documento, cadencia de refresh, detección de contradicciones. El camino más rápido a un agent útil suele ser un pipeline de datos más limpio, no un modelo más inteligente.
Modo de fallo 7. Avaricia de scope (un agent haciendo 9 cosas)
La señal. El roadmap dice "el agent manejará soporte, sales qualification, lookup de conocimiento interno, scheduling y revisión de contratos".
Cómo mata el proyecto. Cada capacidad compite por presupuesto de prompt, presupuesto de tools, presupuesto de eval. Ninguna se vuelve buena. El equipo optimiza para la demo y lanza un agent que es mediocre en nueve cosas.
El fix barato. Un agent, un trabajo, una eval. Lanza estrecho. Añade capacidades solo después de que la previa pase su eval en el listón de producción. Composición sobre conflación.
Modo de fallo 8. Huecos regulatorios y de audit-trail
La señal. El agent se lanza. Dos semanas después, legal pregunta "¿dónde está el audit log?" y "¿cómo manejamos una objeción del Art. 22 GDPR?".
Cómo mata el proyecto. El agent se saca de producción hasta que se cierra el hueco. El equipo hace retrofit de compliance durante seis semanas. La inercia muere.
El fix barato. Audit log como estructura de datos de primera clase, no un console.log. Tool calls MCP logueadas con input, output, versión de modelo, timestamp, operador. Superficie de human-override que registra quién sobrescribió qué y por qué. Cubrimos la capa de artefactos en nuestro post compañero sobre apilar compliance de GDPR y AI Act.
"Las evals son la única medida honesta de un agent. Todo lo demás es una demo con queries cherry-picked."
¿Cómo se agrupan estos modos de fallo en engagements reales?
Por nuestra experiencia los modos de fallo no aparecen en aislamiento. Se agrupan. Las combinaciones más comunes que vemos en proyectos atascados:
| Cluster | Modos de fallo que viajan juntos | Cómo se ve |
|---|---|---|
| El Acantilado Demo-a-Producción | 1, 3, 7 | Gran demo, sin evals, el scope del agent siguió creciendo, el launch a producción revela alucinaciones en queries reales |
| La Muerte Silenciosa por Coste | 2, 4 | Latencia tolerable, costes invisibles hasta la tercera factura mensual, economía unitaria nunca modelada |
| El Rechazo de Operaciones | 5, 8 | Sin handoff, sin audit trail, el equipo de ops rechaza tomar ownership, el agent se queda en piloto para siempre |
| El Espejismo de la Capa de Datos | 3, 6 | Meses de tuning de prompt sobre un corpus roto, el equipo culpa al modelo, los datos son el problema |
¿Qué separa un agent lanzado de uno cancelado?
Tres movimientos de disciplina que hemos visto consistentemente. Ninguno es exótico.
- Eval harness en el sprint uno. Si no puedes medir mejora, no puedes lanzar.
- Cost-per-action trackeado desde la primera integración. Selección de modelo por paso tratada como decisión de ingeniería, no como default.
- Human handoff diseñado antes de la autonomía. Audit trail como preocupación de primera clase, no atornillado para legal.
Hyperstate AI se lanzó. Luego la empresa se quedó sin financiación después del launch, lo cual es un fallo de fundraising, no un fallo de producto o tech. El punto. Incluso una ejecución técnica limpia no salva un proyecto de causas externas. Pero la ejecución descuidada garantiza cancelación independientemente del capital.
Reflexiones finales
Los proyectos de agents fallan de formas predecibles. Alucinación, latencia, eval-debt, runaway de coste, handoff ausente, datos sucios, avaricia de scope, huecos de auditoría. Ninguno de estos son problemas exóticos. Todos tienen fixes baratos si se atrapan en el primer mes y caros si se atrapan en el sexto.
Si estás construyendo un agent en DACH o UE en 2026, corre tu proyecto actual contra los 8 modos de arriba. La respuesta honesta de a cuáles estás expuesto es también el backlog de mayor apalancamiento para el siguiente sprint. El número del 40 por ciento de cancelación no es destino. Es lo que pasa cuando los equipos se saltan el eval harness, ignoran el dashboard de costes y diseñan autonomía antes del handoff.
¿Necesitas un segundo par de ojos en tu build de agent?
Reserva Consultoría Gratuita