La mayoría de los proyectos de agentes no mueren porque el modelo no fuera lo bastante inteligente. Mueren porque nadie pudo enviarle los datos, atribuir el coste, reconstruir una ejecución defectuosa o conseguir que riesgo y legal autorizaran que actúe. Gartner prevé que más del 40% de los proyectos de IA agéntica se cancelen antes de que termine 2027, y las razones que enumera son operativas, no intelectuales. Esta entrada fundamenta esa predicción en seis patrones de fallo documentados entre 2024 y 2026, asocia cada uno al control concreto que lo evita y termina con una lista de comprobación pre-mortem que puede ejecutar antes de escribir una línea de código.
¿Por qué se cancelan tantos proyectos de agentes?
La cifra de titular procede de una nota de prensa de Gartner del 25 de junio de 2025: más del 40% de los proyectos de IA agéntica se cancelarán antes de que termine 2027, por “costes crecientes, valor de negocio poco claro o controles de riesgo inadecuados.” El analista de Gartner también señala el “agent washing,” la reetiquetación de antiguos chatbots y de la automatización robótica de procesos como agentes, y estima que solo unos 130 de los miles de proveedores que dicen tener capacidad agéntica son reales.
Junto a ella hay una segunda cifra. El State of AI in 2025 de McKinsey informa de que aproximadamente nueve de cada diez organizaciones ya usan IA en algún punto, pero solo alrededor de un tercio la ha escalado en toda la empresa, y el rasgo que separa a los equipos que escalan de los que se estancan es el rediseño fundamental del flujo de trabajo, no la elección del modelo. Una tercera cifra, del informe Project NANDA del MIT The GenAI Divide: State of AI in Business 2025, halló que, pese al elevado gasto empresarial, alrededor del 95% de los pilotos de IA generativa no produjeron ningún retorno medible, y atribuyó la brecha a flujos de trabajo frágiles y a un desajuste con las operaciones diarias, más que a la calidad del modelo.
Tres estudios, una sola historia. El trabajo que sobrevive está defendido operativamente. El trabajo que muere era una buena demo que nadie pudo llevar a producción.
¿Cuáles son los patrones de fallo y qué detiene cada uno?
Los patrones siguientes son los que se reportan una y otra vez en notas de analistas y en reportajes solventes entre 2024 y 2026. Para cada uno, el fallo documentado y el control concreto que lo evita.
| Patrón de fallo | Cómo se ve | El control que lo evita |
|---|---|---|
| La privacidad bloquea la adopción | Seguridad no deja que los datos regulados salgan de la frontera, así que el piloto nunca arranca | Desplegar el agente dentro del entorno del cliente |
| Sin atribución de coste | La factura se triplica, nadie sabe qué flujo de trabajo la disparó | Medir el coste por tarea completada, por flujo de trabajo |
| Sin depurabilidad | Una ejecución errónea no puede reconstruirse, la confianza se desploma | Trazas y reproducción de la ejecución en cada ejecución |
| Desbordamiento de alcance | Un ayudante acotado se convierte en un sistema de razonamiento abierto | Un manifiesto acotado con herramientas y conocimiento fijados por escrito |
| Supervisión humana débil | El agente actúa antes de que nadie pueda revisar, los errores llegan a producción | Una puerta de aprobación explícita por cada acción con consecuencias |
| Sobreautomatización | Una tarea con consecuencias y difícil de revertir se automatiza por completo | Una escalera de autonomía graduada según el radio de impacto |
Fallo 1: la privacidad bloquea la adopción antes de que arranque el piloto
La primera conversación con un proveedor de agentes de frontera suele acabar en el mismo punto. Los datos que el agente necesita son PII (información de identificación personal) de clientes, contratos, reclamaciones, historiales clínicos, código fuente o posiciones financieras. Enviar eso a un endpoint de un tercero es una transferencia que el equipo de seguridad no firmará, y bajo el RGPD y, para las entidades financieras de la UE, DORA, tienen razón en no hacerlo. El proyecto no fracasa en producción. Fracasa antes de la primera consulta real, porque nadie puede alimentar legalmente al agente con nada que valga la pena automatizar. Lo que lo paraliza es la revisión de seguridad, no una vulnerabilidad de seguridad.
El control: lleve el agente a los datos, no los datos al agente. Despliéguelo dentro de la propia cuenta cloud, VPC o entorno on-premise del cliente, de modo que los registros regulados nunca crucen la frontera de confianza, con las claves custodiadas en el propio almacén de claves del cliente. Esa es la diferencia entre “no podemos empezar” y “podemos empezar con datos reales el lunes.” Detallamos la mecánica de esto en Dentro de la frontera de confianza, y la arquitectura está en la página de plataforma y en la página de seguridad.
Fallo 2: sin atribución de coste, así que finanzas retira el presupuesto
El piloto corre sobre una clave de API compartida y una factura global. A las seis semanas, la factura se ha triplicado y nadie sabe qué flujo de trabajo la disparó: el triaje de reclamaciones de alto valor, o el bot de preguntas frecuentes interno de bajo valor que alguien montó un viernes. Cuando finanzas pide la economía unitaria y la respuesta es una sola cifra agregada, el proyecto pierde su defensa presupuestaria. El “coste creciente, valor poco claro” de Gartner suele ser esto. El agente no era caro. Nadie pudo atribuir el gasto a un resultado.
El control: mida a nivel de flujo de trabajo, no a nivel de cuenta. Etiquete cada token, llamada a herramienta y reintento a un flujo de trabajo concreto y, cuando sea posible, a una tarea completada. La cifra que finanzas necesita es “coste por reclamación resuelta,” no “gasto del mes pasado.” Cuando puede poner el coste unitario junto al valor unitario, la conversación pasa de “esto se está poniendo caro” a “esto cuesta 3,40 EUR por tarea completada y sustituye 25 EUR de tramitación manual.” Ese es el argumento de Coste por tarea completada y lo que la torre de control existe para producir.
Fallo 3: sin depurabilidad, así que una sola ejecución defectuosa lo termina
Un agente produce una respuesta errónea delante de un responsable de alto nivel. Alguien hace la pregunta razonable: ¿qué pasó en esa ejecución? Si la respuesta es “no podemos reconstruirla,” la confianza no se degrada de forma gradual, se desploma. Un único fallo sin explicar y sin traza hace más daño político que el crédito que ganan cincuenta éxitos silenciosos.
El control: instrumente cada ejecución para que pueda reconstruirse. Una traza registra las entradas, el contexto de recuperación, las llamadas a herramientas y las decisiones intermedias, idealmente bajo las convenciones semánticas de OpenTelemetry para GenAI para que el formato sea portable y no el dialecto privado de un proveedor. La reproducción vuelve a ejecutar el caso fallido exacto. Las evaluaciones convierten la depuración puntual en una batería de regresión, de modo que una corrección se vuelve un test. Cuando un responsable señala una respuesta errónea, usted responde con la ejecución, no con una disculpa.
Fallo 4: el desbordamiento de alcance convierte una herramienta en un proyecto de investigación
El desbordamiento de alcance es, según varios análisis de 2025, la razón individual más común por la que se estancan los proyectos de agentes. A un ayudante acotado que redactaba un tipo de correo se le empieza a pedir que gestione excepciones, luego que extraiga de tres sistemas más, luego que razone de forma abierta sobre todo el departamento. Cada añadido necesita más integraciones, más acceso a datos y más evaluación, y el proyecto pierde en silencio la victoria pequeña y defendible que podría haber entregado.
El control: fije el alcance por escrito antes de construir, como un manifiesto que el agente no pueda exceder en tiempo de ejecución. Un manifiesto nombra al responsable, el único flujo de trabajo, las herramientas permitidas (y las prohibidas), las fuentes de conocimiento, el nivel de riesgo, el tope de coste y el plan de reversión. Uno breve:
name: invoice-exception-resolver
owner: finance-ap@customer
workflow: accounts-payable / exception handling
allowed: erp.read, erp.match, ticket.create (no erp.post)
knowledge: vendor-master, po-history, ap-policy
risk_tier: 2 (financial, reversible)
cost_cap: 0.60 EUR / completed task
autonomy: execute-with-approval
rollback: void ticket, requeue to human, alert ownerLa línea no erp.post es la decisión de radio de impacto tomada por escrito en lugar de descubierta en un incidente. Más sobre esto en Skills de agente: un manifiesto para cada flujo de trabajo.
Fallo 5: supervisión humana débil, así que los errores llegan antes de que nadie mire
Una demo en la que el agente solo sugiere es fácil de aprobar. El problema empieza cuando alguien conecta la sugerencia directamente a la acción (enviar el correo, contabilizar la factura, liberar el pago) sin paso de revisión, porque la revisión parecía lenta. La primera acción errónea que llega a un cliente o a un regulador es la que pone el proyecto en pausa.
Esto no es solo prudencia operativa, es ley. Bajo la Ley de IA de la UE, los responsables del despliegue de sistemas de alto riesgo deben asignar la supervisión humana a personas competentes y formadas con autoridad real para intervenir, incluida la capacidad de decidir no usar la salida (Artículo 14 y Artículo 26). “Lo dejamos actuar y vemos” no es una postura que legal pueda aceptar.
El control: una puerta de aprobación explícita en cada acción con consecuencias, mapeada a roles (RBAC) y a límites de valor y de radio de impacto. La puerta es además su plan de reversión durante la primera etapa de vida del agente: el plan de reversión es una persona que dice que no. Esto es lo que permite que riesgo y legal aprueben la primera versión el primer día. El modelo de confianza se construye en torno a esto.
Fallo 6: sobreautomatización de aquello que no se puede deshacer
Lo opuesto a la supervisión débil es el exceso de confianza. Un equipo que consigue que un flujo de trabajo funcione bien va a por la autonomía total en una tarea con consecuencias y difícil de revertir: una recomendación clínica, una reclamación denegada, un pago transferido, una cláusula contractual. Cuando eso sale mal, el coste no es una nueva ejecución, es un daño en el mundo real y una responsabilidad en el mundo real. Los reportajes a lo largo de 2025 y ya en 2026 siguen sacando a la luz la misma lección: los fallos que llegan a los titulares son aquellos en los que se automatizó una tarea de alto riesgo y baja reversibilidad sin un freno.
El control: una escalera de autonomía graduada, donde el peldaño que se permite ocupar a un agente está ligado a cuán reversible es la acción. Lo de bajo radio de impacto y reversible puede correr de forma autónoma con humanos sobre las excepciones. Lo de alto radio de impacto e irreversible se queda en ejecución-con-aprobación por muy buena que se viera la demo. El detalle está en La escalera de autonomía.
¿Cómo evita convertirse en la estadística?
El orden importa tanto como los controles. La mayoría de los proyectos cancelados intentaron hacerlo todo a la vez, o en el orden equivocado, y se quedaron sin confianza o sin presupuesto antes de que el valor aterrizara. La secuencia que sobrevive:
- Despliegue primero en privado. Levante el agente dentro de la frontera de confianza sobre datos reales. Esto despeja el veto de seguridad y le da un sistema autorizado a hacer trabajo útil.
- Instrumente antes de automatizar. Active la atribución de coste y las trazas mientras el agente todavía solo sugiere. El medidor y los registros deberían estar funcionando antes de que nadie proponga darle al agente la capacidad de actuar.
- Automatice con evidencia. Suba la escalera de autonomía un peldaño cada vez, promoviendo según el registro de trazas (tasa de aprobación, tasa de fallo, cobertura de reproducción, un plan de reversión que se haya ejercitado de verdad), no según una diapositiva.
La lista de comprobación pre-mortem
Antes de construir, asuma que el proyecto fracasó y pregunte por qué. Si no puede responder cada línea de abajo, ha encontrado el riesgo antes de que él lo encontrara a usted.
- Responsable. ¿Hay una única persona nombrada que rinde cuentas por este agente en producción, no un equipo y no un prompt en un notebook?
- Frontera. ¿Dónde residen los datos regulados, y ha confirmado que nunca tienen que salir del entorno del cliente para funcionar?
- Tope de coste. ¿Cuál es el coste por tarea completada que defendería ante finanzas, y cuál es el tope rígido que pone el agente en pausa?
- Traza. Para cualquier ejecución, ¿puede reconstruir las entradas, la recuperación, las llamadas a herramientas y las decisiones, y reproducir el caso fallido exacto?
- Alcance. ¿Está el manifiesto escrito, con herramientas permitidas y prohibidas, antes de cualquier código, y puede el agente excederlo en tiempo de ejecución?
- Aprobación. ¿Qué acciones requieren una puerta humana, quién tiene la autoridad para decir que no, y es eso coherente con sus obligaciones bajo la Ley de IA de la UE?
- Reversibilidad. Para cada acción que el agente puede tomar, ¿es reversible, y si no lo es, está fijada por debajo de lo autónomo?
- Plan de reversión. ¿Se ha ejercitado de verdad el plan de reversión para el peor fallo plausible, no solo escrito?
Un proyecto capaz de responder esas ocho no tiene garantizado el éxito. Pero ya no está en el 40%. Las cancelaciones que Gartner prevé son en su mayoría proyectos técnicamente sólidos y operativamente indefensos. La defensa no es un modelo mejor. Es una frontera, un medidor, un registro, un manifiesto, una puerta y una escalera, en ese orden. Para más sobre el modelo operativo tras estos controles, consulte la biblioteca de análisis completa.
Preguntas frecuentes
¿La cifra del 40% de cancelaciones tiene que ver con la calidad del modelo?
No. Gartner atribuye las cancelaciones a costes crecientes, valor de negocio poco claro y controles de riesgo inadecuados. El trabajo independiente de McKinsey y del MIT apunta en la misma dirección: la restricción vinculante es operativa y organizativa (acceso a datos, atribución de coste, depurabilidad, diseño del flujo de trabajo), no si el modelo sabe razonar. Cambiar a un modelo más nuevo rara vez cambia el resultado.
¿Qué control individual evita más fallos?
Desplegar dentro del propio entorno del cliente elimina el bloqueador más común, porque es lo que permite que un equipo regulado empiece siquiera con datos reales. Pero los controles funcionan como conjunto. El despliegue privado despeja el veto de seguridad, la medición defiende el presupuesto, las trazas defienden la confianza, el manifiesto sostiene el alcance, y la puerta de aprobación y la escalera de autonomía mantienen seguras las acciones con consecuencias. Cada uno cierra un modo de fallo distinto.
¿Qué es un pre-mortem y cuándo se ejecuta?
Un pre-mortem es un ejercicio breve en el que asume que el proyecto ya ha fracasado y trabaja hacia atrás hasta las razones, antes de escribir nada de código. Para un agente, eso significa nombrar al responsable, la frontera de datos, el tope de coste, el requisito de traza, el alcance, la puerta de aprobación, la reversibilidad de cada acción y un plan de reversión que se haya probado. Es el seguro más barato contra ser uno de los proyectos cancelados.