Agentes de IA: 40% se cancelará por falta de gobernanza

Gartner proyecta que más del 40% de los proyectos de IA agéntica se cancelará antes de que termine 2027, por tres causas: costos que se disparan, valor de negocio poco claro y controles de riesgo insuficientes. Para una startup que ya tiene agentes escribiendo en producción, la traducción es incómoda: casi nunca el problema es el modelo, sino que nadie dejó por escrito qué puede y qué no puede hacer ese agente.

La nota original de Unite.AI plantea la brecha con una comparación simple. Si preguntas qué puede hacer una nueva analista de cuentas por pagar, la empresa responde con precisión: trabaja con estos proveedores, cualquier importe por encima de un límite de aprobación —por ejemplo, 10.000 dólares— pasa a su gerente, está a prueba sus primeros meses, y todo queda en una matriz de delegación de autoridad que auditoría interna revisa cada año. Si preguntas lo mismo por el agente de facturación, la respuesta suele ser una captura de pantalla de una instrucción.

Por qué una instrucción de prompt no funciona como control

Una instrucción describe una intención: para qué sirve el agente. Rara vez dice qué no debe hacer nunca, dónde están sus límites o cuándo tiene que detenerse y devolver la decisión a una persona. Y aunque lo diga, nada lo hace cumplir. Pedirle a un sistema probabilístico que no emita reembolsos superiores a 500 dólares es una petición, no un mecanismo de control. Ningún auditor aceptaría un control que consista en pedirle amablemente al analista que lo haga.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La autorización tiene que vivir donde se ejecuta la acción, no dentro del prompt. Eso significa tres puntos concretos: la identidad de servicio del agente, los permisos de sus herramientas y el límite de gasto de la pasarela de API por la que pasan sus llamadas.

El error más común es el tercero. Varios agentes colgando de una misma cuenta de servicio compartida equivale a darle a cinco empleados la misma credencial: cuando algo sale mal, el registro de auditoría dice que actuó la cuenta y nadie sabe cuál de los cinco fue.

La agencia excesiva ya es el tercer riesgo del ranking de OWASP

El marco de referencia del sector se movió en esa dirección. En la edición 2026 del Top 10 para aplicaciones con LLM de OWASP, publicada el 3 de agosto, la agencia excesiva subió del sexto al tercer puesto, según reportó Tech Times. Fue la primera edición ponderada con evidencia y no solo con consenso: 6.639 incidentes reales, con un peso del 25% sobre el ranking final.

OWASP descompone la agencia excesiva en tres causas de diseño, todas verificables en una revisión de arquitectura: darle al agente más herramientas de las que su tarea necesita (funcionalidad excesiva), darle a esas herramientas permisos más amplios de los necesarios (permisos excesivos) y dejarlo actuar sin aprobación humana en acciones de alto impacto (autonomía excesiva).

El detalle que importa: cada una de esas fallas amplifica todas las demás vulnerabilidades de la lista. Un modelo manipulado por inyección de instrucciones hace un daño acotado si tiene permisos estrechos y un punto de aprobación humana. El mismo modelo comprometido, con permisos amplios y autonomía total, propaga el daño a sistemas de archivos, repositorios de código, sistemas financieros y canales de comunicación. Steve Wilson, co-líder del proyecto y chief AI officer de Exabeam, lo resumió en The Next Web: el problema difícil ya no está en el modelo, está en lo que el agente tiene permitido hacer. Su receta es poco glamorosa: herramientas de solo lectura en lugar de conectores generales, peticiones dentro de la identidad acotada del propio usuario, un punto de aplicación de políticas entre el modelo y lo que hay aguas abajo, y aprobación humana para todo lo que sea difícil de revertir.

En septiembre, el OWASP GenAI Security Project sumó a ese corpus el Agent Control Standard, orientado a llevar los controles de gobernanza de agentes a la aplicación en tiempo de ejecución, según el anuncio recogido por Yahoo Finance.

Qué pasa cuando los controles llegan tarde

Según Diginomica, que cita investigación de Gartner, para 2030 la mitad de las fallas en despliegues de agentes de IA vendrá de una aplicación insuficiente de controles en tiempo de ejecución en las plataformas de gobernanza. Es decir: no de que el modelo falle, sino de que no había nada que lo frenara cuando falló.

El mismo artículo deja dos datos incómodos para quien esté comprando la categoría. El primero: Gartner advierte sobre el fenómeno que llama agent washing —el rebautizo de asistentes, RPA y chatbots existentes como agentes, sin capacidades nuevas— y estima que solo unos 130 de los miles de proveedores que se autodenominan de IA agéntica lo son de verdad. El segundo: el informe GenAI Divide del NANDA de MIT encontró que apenas alrededor del 5% de los pilotos de IA llega a una aceleración rápida de ingresos, con una brecha de aprendizaje y una integración empresarial deficiente como causas principales.

Y hay una capa de cumplimiento asomando. Desde el 11 de septiembre, el Cyber Resilience Act europeo obliga a los fabricantes a reportar una vulnerabilidad explotada a su equipo nacional de respuesta en 24 horas, con notificación completa a las 72, bajo sanciones de hasta 15 millones de euros o el 2,5% de la facturación mundial, según The Next Web. El debate regulatorio sigue discutiendo si el software entregado en la nube —por donde llega la mayoría de los agentes a un cliente— queda dentro del alcance.

Cómo se escribe la descripción de puesto de un agente

Antes de que un agente toque un sistema en producción, alguien debería poder redactar un documento de una página con cinco casillas: qué puede hacer, qué no debe hacer nunca, cuáles son sus umbrales de aprobación, qué persona es responsable última de él y quién puede ampliar sus límites. En la matriz RACI, el responsable último tiene que ser una persona con nombre. Si el equipo no puede redactar ese documento, el puesto no está listo para cubrirse, exactamente lo mismo que dirías de una contratación humana.

Dos reglas clásicas de delegación de autoridad se trasladan tal cual:

No puedes delegar una autoridad que no tienes. Un subagente nunca debería recibir permisos más amplios que los del agente que lo creó.
La segregación de funciones sigue siendo necesaria. Que un agente pueda dar de alta un proveedor y además pagarle es el mismo hallazgo de auditoría que si lo hiciera una persona.

Después viene la prueba de selección, y aquí la mayoría de los equipos mide lo que no importa. Evaluamos agentes como evaluaríamos una calculadora: si la respuesta es correcta. Una prueba de trabajador comprobaría otra cosa: si se mantuvo dentro de sus límites, si pidió aprobación cuando correspondía, si escaló el caso cuando la situación excedía sus instrucciones y si se detuvo cuando debía hacerlo. El autor de la nota original está construyendo un benchmark de 50 escenarios con esos fallos —exceder límites de aprobación, operar con datos desactualizados, seguir instrucciones inyectadas que amplían el alcance y conservar accesos tras un cambio de rol— y aclara que hasta ahora solo lo corrió con agentes programados por guiones para validar los escenarios, sin resultados públicos sobre modelos.

Los conceptos de período de prueba y ascenso también se trasladan. Se empieza con un ámbito reducido y se amplía a medida que el agente demuestra criterio dentro de los límites. Con una complicación que no existe con las personas: cuando el proveedor actualiza el modelo subyacente, en la práctica tienes a alguien recién contratado usando la credencial del anterior. Eso es un cambio de puesto y amerita reevaluación antes de transferir la autorización.

¿Qué significa esto para tu startup?

Escribe la carta de autorización de cada agente en producción esta semana. Una página, cinco casillas, una persona responsable con nombre. Si tu equipo no puede escribirla, esa es la señal de que el despliegue se apuró.
Saca a tus agentes de la cuenta de servicio compartida. Identidad propia por agente, permisos mínimos por herramienta y un tope de gasto en la pasarela de API. Cuando algo se rompa, el log tiene que decir quién lo hizo.
Corre un simulacro de revocación. ¿Podrías detener a tu agente más crítico y quitarle los accesos en la próxima hora? ¿Quién tiene autoridad para decidirlo a las 2 de la madrugada? Si nadie lo practicó, estás confiando en un interruptor que nunca se probó.
Mide una métrica de resultado, no de actividad. Costo por caso, tasa de error o resolución real del cliente en lugar de minutos ahorrados. Sin línea base previa, no vas a poder decir si el agente mejoró algo.

Y un filtro al comprar: si tu proveedor no puede explicar cómo el agente decide el siguiente paso, si no hay mecanismo para detenerlo o devolver el control a una persona, y si no te da un costo por caso estimado sobre volumen real de producción, probablemente estés pagando precio de agente por automatización.

Qué preguntará la auditoría cuando algo falle

Algún agente va a hacer algo que no debería. Cuando eso pase, la revisión posterior va a plantear las mismas preguntas que ya se hacen sobre las personas: qué tenía permitido hacer y dónde está documentado, quién aprobó la ampliación de sus accesos, cuánto se tardó en detenerlo y quién era responsable.

Si las respuestas honestas son ‘un prompt’, ‘nadie se acuerda’, ‘horas’ y ‘no está claro’, un modelo mejor no te habría salvado.

Conclusión

Los modelos se están volviendo un recurso de alquiler: se sustituyen y se actualizan según el calendario del proveedor. Dos empresas pueden usar exactamente el mismo modelo y terminar en situaciones opuestas. Una tiene agentes con presupuesto, límites, un responsable con nombre y un registro de auditoría de cada acción relevante. La otra tiene un piloto caro camino a engrosar las estadísticas de cancelación que reporta Gartner.

La capa de datos es parte de ese problema de control, no solo de rendimiento. En la cobertura de YourStory de TechSparks 2026, Nitin Waghulde, de VeloDB, planteó que un agente de reembolsos que no ve la última transacción tiene que esperar, y que cada consulta adicional al dato suma costo y desactualización. Su ejemplo de escala: un exchange de criptomonedas con más de 120 millones de usuarios que atiende alrededor de 33.000 conversaciones con una latencia de cola cercana a los 3 milisegundos.

La ventaja competitiva de los próximos dos años no va a estar en el modelo que elijas —ese también lo tiene tu competencia— sino en el sistema de gestión que construyas alrededor: autorizaciones, pruebas y revisiones, las cosas que se hacen un martes cualquiera y que ningún PDF de gobernanza reemplaza.

La pregunta de cierre es del texto original: si mañana tu agente más nuevo se excediera de sus atribuciones, ¿alguien en tu empresa se daría cuenta? ¿Y podrías mostrarle por escrito a un auditor dónde estaba el límite?