Gartner proyecta que más del 40% de los proyectos de IA agéntica se cancelarán antes de que termine 2027. Las razones declaradas son el aumento de los costes, un valor de negocio poco claro y controles de riesgo inadecuados. Ninguna de ellas es una afirmación sobre si el modelo es capaz de razonar. Son afirmaciones sobre si el proyecto puede financiarse, ganarse la confianza y obtener aprobación con el tiempo.
Esto importa porque la respuesta habitual ante un proyecto de agentes estancado es cambiar el modelo. Los equipos pasan de un modelo de frontera al siguiente, esperando que el riesgo de cancelación baje. Rara vez lo hace. El modelo casi nunca fue la restricción limitante. La restricción es operativa: a dónde se permite que vayan los datos, quién puede leer la factura, quién puede leer el fallo y quién autoriza dejar que el agente actúe sin un humano en el bucle.
Hay una segunda cifra que conviene poner junto a la de Gartner. El trabajo de McKinsey de 2025 informa de que el 88% de las organizaciones ya usan IA en algún punto, pero alrededor de dos tercios no han pasado de los pilotos, y el rasgo que separa a los equipos que escalan de los que se atascan es el rediseño del flujo de trabajo, no la elección del modelo. Las cancelaciones y los atascos son la misma historia contada dos veces. El trabajo que sobrevive está defendido operativamente. El trabajo que muere era una buena demo que nadie pudo llevar a producción.
Este es un análisis de campo de los cuatro modos de fallo que vemos terminar con un proyecto, y los cuatro controles que lo mantienen vivo. El patrón es lo bastante consistente como para planificar en función de él.
Los fallos son operativos, no de calidad del modelo
Una prueba útil: si la demo de tu agente funciona con datos sintéticos en el entorno de pruebas de un proveedor y luego muere al contacto con la organización real, el modelo no es tu problema. El paso de “interesante” a “en producción” es donde mueren los proyectos, y mueren por cuatro obstáculos predecibles.
Fallo 1: los datos no pueden salir, así que la adopción nunca empieza
La primera conversación con un proveedor de agentes de frontera suele terminar en el mismo punto. Los datos que el agente necesita son PII de clientes, contratos, reclamaciones, historiales médicos, código fuente o posiciones financieras. Enviar esos datos 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, DORA, tienen razón en no hacerlo. El proyecto no falla en producción. Falla antes de la primera consulta real, porque nadie puede alimentar legalmente al agente con nada que merezca la pena automatizar.
Fallo 2: sin atribución de costes, finanzas lo cancela
El piloto funciona con una clave de API compartida y una factura mensual fija. A las seis semanas, la factura se ha triplicado y nadie puede decir qué flujo de trabajo la provocó. ¿Fue la clasificación de reclamaciones de alto valor, o el bot de preguntas frecuentes interno de bajo valor que alguien conectó un viernes? Cuando finanzas pide la economía unitaria y la respuesta es una única cifra agregada, el proyecto pierde su defensa presupuestaria. El “coste creciente, valor poco claro” de Gartner suele ser esto: no que el agente fuera caro, sino que nadie pudo atribuir el gasto a un resultado.
Fallo 3: sin capacidad de depuración, una mala ejecución erosiona la confianza
Un agente produce una respuesta incorrecta 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 fallo inexplicable sin traza causa más daño político del que cincuenta éxitos silenciosos generan de crédito. Sin la capacidad de reproducir una ejecución concreta y mostrar las entradas, las llamadas a herramientas y los puntos de decisión, cada error se convierte en un argumento para cerrar el proyecto.
Fallo 4: sin ruta de autonomía, riesgo y legal lo bloquean
El equipo quiere que el agente actúe: enviar el correo, actualizar el registro, mover el ticket, liberar el pago. Riesgo y legal quieren saber qué pasa cuando actúa de forma incorrecta, y cuál es la reversión. Sin una ruta graduada desde “sugiere” hasta “actúa con aprobación” y “actúa de forma autónoma”, la elección se reduce a un binario. O bien el agente es un juguete de solo lectura que nadie valora, o es un actor sin límites que nadie aprobará. Bajo el Reglamento de IA de la UE, los responsables del despliegue de sistemas de mayor riesgo cargan con obligaciones de documentación y supervisión humana, así que “lo dejamos actuar y ya veremos” no es una postura que legal pueda aceptar.
Los cuatro controles que salvan un proyecto
Cada fallo tiene un control. Los controles no son exóticos. Son el equivalente en AgentOps de lo que ya exiges a cualquier sistema que toca producción: un límite, un medidor, un registro y una puerta de aprobación.
Control 1: un límite de confianza, desplegar en el entorno del cliente
Lleva el agente a los datos, no los datos al agente. Despliega dentro de la VPC del cliente o en su infraestructura on-premise, de modo que la PII y los registros regulados nunca crucen el límite de confianza. Las claves viven en el KMS del cliente. Donde una API de modelo sea inevitable, enrútala a través de controles que el cliente posea, y documenta la base de cualquier transferencia (SCCs, endpoints regionales) antes de la primera consulta en producción. Esto es lo que convierte el “no podemos empezar” en “podemos empezar con datos reales el lunes”.
Control 2: atribución del coste por tarea completada
Mide a nivel de flujo de trabajo, no a nivel de cuenta. Etiqueta cada token, llamada a herramienta y reintento con un flujo de trabajo concreto y, donde sea posible, una tarea completada concreta. La cifra que finanzas necesita no es “gasto del mes pasado”. Es “coste por reclamación resuelta” o “coste por ticket cerrado”. Cuando puedes poner el coste unitario junto al valor unitario, la conversación presupuestaria cambia de “esto se está poniendo caro” a “esto cuesta 3,40 EUR por tarea completada y sustituye 25 EUR de gestión manual”. Esa es una cifra defendible.
Control 3: trazas, replay y evaluaciones
Instrumenta cada ejecución para que pueda reconstruirse. Una traza registra las entradas, la recuperación (contexto RAG), las llamadas a herramientas y las decisiones intermedias, idealmente bajo las convenciones semánticas de OpenTelemetry GenAI para que el formato no sea el dialecto privado de un proveedor. El replay te permite volver a ejecutar el caso fallido exacto. Las evaluaciones convierten la depuración puntual en una batería de regresión, de modo que la corrección de una mala ejecución se convierte en una prueba que previene la siguiente, y de modo que puedes cambiar un prompt, un modelo, un recuperador o una herramienta y probar el cambio antes de desplegarlo. El objetivo es que, cuando un responsable señale una respuesta incorrecta, respondas con la ejecución, no con una disculpa. La capacidad de depuración es lo que convierte un incidente que erosiona la confianza en un ticket cerrado.
Control 4: una escalera de autonomía graduada con aprobaciones
Sustituye el binario por una escalera, y haz de cada peldaño una decisión explícita.
Regla general: un agente se gana el siguiente peldaño de autonomía acumulando evidencia en el actual, no superando una demo.
Una escalera viable va desde solo sugerir (un humano hace todo), pasando por borrador más aprobación, acción recomendada, ejecutar con aprobación, ejecutar bajo política, hasta autónomo con personas en las excepciones. Cada peldaño se corresponde de forma limpia con el RBAC, con los límites de valor y de radio de impacto, y con las expectativas de supervisión humana del Reglamento de IA de la UE. Riesgo y legal pueden aprobar los primeros peldaños el primer día porque la reversión es un humano diciendo que no. La promoción de un peldaño al siguiente se lee en el registro de trazas, no se promete en una diapositiva: tasa de aprobación, tasa de fallo, cobertura de reproducción, calidad del resultado de negocio y una reversión que se haya ejercitado de verdad.
Cada agente necesita un responsable, no solo un prompt
Los cuatro controles comparten una condición previa que es fácil de saltarse y cara de saltarse: cada agente tiene que ser un objeto nombrado y gobernado antes de tocar producción, no un prompt anónimo en el cuaderno de alguien. Lo escribimos en un manifiesto de skill, y el acto de rellenarlo saca a la luz la mayoría de los cuatro fallos antes de que ocurran.
Un manifiesto para un agente registra su nombre y responsable, el flujo de trabajo al que sirve, los usuarios y roles autorizados a invocarlo, las herramientas que puede llamar, sus fuentes de conocimiento, los requisitos de aprobación, su nivel de riesgo, un tope de coste, su registro, las pruebas de evaluación que condicionan cualquier cambio, y la política de fallo y de reversión. Uno breve se ve así:
name: invoice-exception-resolver
owner: finance-ap@cliente
workflow: cuentas-por-pagar / gestion de excepciones
allowed: ap-clerk, ap-manager
tools: erp.read, erp.match, ticket.create (sin erp.post)
knowledge: maestro-proveedores, historial-po, politica-ap (consciente de permisos)
risk_tier: 2 (financiero, reversible)
cost_cap: 0,60 EUR / tarea completada
autonomy: ejecutar-con-aprobacion (L3)
evals: 42 casos; puerta de promocion >= 0,95 coincidencia
rollback: anular ticket, devolver a la cola humana, alertar al responsableFíjate en lo que fuerza el manifiesto. “Sin erp.post” es la decisión de radio de impacto tomada por escrito en lugar de descubierta en un incidente. El tope de coste es la defensa de finanzas, fijada antes de que llegue la factura. Las fuentes de conocimiento conscientes de permisos son la respuesta a “¿puede el agente leer algo que el usuario no puede?”. La puerta de evaluación es lo que convierte la promoción en aritmética en lugar de en opinión. Un agente sin manifiesto es un agente que nadie puede defender en una revisión, y un proyecto lleno de ellos es un proyecto a la espera de ser cancelado.
Secuencia: desplegar de forma privada, instrumentar, luego automatizar con evidencia
El orden es lo importante. La mayoría de los proyectos cancelados intentaron hacer todo esto a la vez, o en el orden equivocado, y se quedaron sin confianza o sin presupuesto antes de que el valor llegara.
La secuencia que sobrevive:
- Despliega primero de forma privada. Levanta el agente dentro del límite de confianza con datos reales. Esto supera el veto de seguridad y te deja con un sistema al que se le permite hacer trabajo útil.
- Instrumenta antes de automatizar. Activa la atribución de costes y las trazas mientras el agente todavía solo sugiere. Quieres el medidor y los registros funcionando antes de que alguien proponga dar al agente la capacidad de actuar.
- Automatiza con evidencia. Sube la escalera de autonomía un peldaño cada vez, usando los datos de coste y de trazas para que cada promoción sea una decisión respaldada por evidencia y no un acto de fe.
Esto es más lento que una demo y más rápido que un relanzamiento tras una cancelación. El 40% que Gartner prevé descartar son, en su mayoría, proyectos que eran técnicamente sólidos y operativamente indefensos. El modelo nunca iba a salvarlos, y un modelo mejor no salvará el siguiente intento. Un límite, un medidor, un registro y una puerta de aprobación sí. Pon esos cuatro en su sitio, en ese orden, y la conversación sobre la cancelación no empieza.