Gobernanza de agentes de IA: por qué la autonomía cambia el blast radius (lo que dice la entrevista a SAS)

Cuando el «fallo» deja de verse en pantalla

Marinela Profi, responsable global de estrategia de mercado para agentes de IA y GenAI en SAS, lo resume en una frase que deberíagrabarse en la pared de cualquier equipo que esté desplegando agentes: «Con la IA autónoma, el blast radius cambia. Un error ya no es necesariamente una mala respuesta en la pantalla de alguien. Un agente puede disparar un workflow, interactuar con otro sistema, tomar una decisión o ejecutar una acción antes de que un humano la vea».

La cita llega en plena efervescencia del agentic AI y conecta con una evidencia incómoda que la propia SAS publicó en su informe Data & AI Impact: la confianza en la IA generativa se sitúa en un 76 %, pero cae al 66 % cuando hablamos de agentes. Y, sin embargo, el 89 % de los agentes desplegados en producción ya están actuando en lugar de asistir, y más de la mitad lo hace con aprobación humana limitada o inexistente.

El «blast radius»: por qué hay que cambiar qué significa «mover rápido»

El manual clásico de Silicon Valley — «ship, observe, learn, iterate» — funcionaba razonablemente bien cuando el coste de un fallo era un usuario encontrando una mala feature. Con agentes que tienen autoridad para actuar, la superficie de fallo se multiplica. Por eso Profi propone cambiar la pregunta: en lugar de «¿con qué rapidez podemos desplegar este agente?», las organizaciones deberían preguntarse:

• ¿Qué autoridad le estamos dando?

• ¿Cuál es el blast radius si falla?

• ¿Podemos revertir lo que hace?

La idea de fondo es que la autonomía convierte el fallo en algo que el sistema puede propagar, no solo mostrar. En términos de seguridad, es la diferencia entre un XSS y un SSRF con ejecución remota: el primero te lo enseña el navegador, el segundo puede estar ya en tu base de datos cuando te enteras.

Gobernanza como arquitectura, no como documentación

Otro de los puntos clave de la entrevista es dónde se esconde la deuda técnica. Profi lo tiene claro: «Los atajos peligrosos a menudo no son visibles en el modelo. Están en todo lo que lo rodea».

¿Suena familiar? Hemos visto este patrón en las últimas semanas: el enjambre de 700 agentes de OpenAI que salió de su sandbox arrastrando credenciales, el malware CLOSEDQUORUM que hacía votar a varias IAs sobre su próximo movimiento, o los agentes que filtran credenciales al doble de velocidad según el último informe. En todos los casos, el modelo hacía exactamente lo que se le pedía; el problema estaba en la infraestructura alrededor.

Los atajos «baratos durante el piloto» que Profi señala son:

• Ausencia de linaje fiable entre datos, modelo, decisión y acción resultante.

• Permisos concedidos a nivel de aplicación en lugar de a nivel de agente o tarea individual.

• Logs que capturan outputs pero no qué herramientas fueron invocadas.

• Gobernanza que existe como documentación en lugar de como controles ejecutables.

Dos años después, ¿puedes reconstruir la cadena?

La pregunta que Profi lanza a los equipos es incómodamente directa: «Dos años más tarde, un regulador, un auditor o un cliente pregunta: ¿por qué este sistema tomó esta decisión, qué datos usó, qué política lo gobernó y quién era responsable? Si tu arquitectura no puede reconstruir esa cadena, no vas a arreglar el problema escribiendo otra política de gobernanza».

Es exactamente la diferencia entre tener un runbook y tener trazabilidad. El runbook te dice qué deberías haber hecho; la trazabilidad te dice qué pasó realmente. Para un agente que ha ejecutado 400 acciones sobre 20 sistemas, solo lo segundo sirve en una auditoría o en una investigación de incidentes.

Cinco trampas estratégicas para los despliegues de agentes

Aunque la entrevista se centra en el ángulo empresarial, las cinco trampas estratégicas que menciona Profi encajan como un guante con el lado de la seguridad:

• Velocidad vs. capacidad de observar, restringir, interrumpir y recuperar.

• Atajos arquitectónicos que se convierten en deuda de cumplimiento a varios años vista.

• Controles que viven en documentos en lugar de en código ejecutable.

• Falta de linaje dato–modelo–decisión–acción, que mata la capacidad de auditar.

• Asumir que el modelo es el problema cuando, en realidad, lo es todo lo que lo rodea.

Para los que estamos en el lado defensivo, el mensaje es claro: cuando revisemos despliegues de IA en nuestros entornos, no auditemos solo el modelo. Auditemos la orquestación, los permisos, los logs, el linaje y los kill switches. Ahí es donde se decide si un agente será un asistente útil o el próximo incidente de seguridad del año.

«La gobernanza no es un documento: es una arquitectura. Y la autonomía cambia el fallo de algo que observas a algo que el sistema puede propagar.» — Marinela Profi, SAS

Si quieres leer la entrevista completa, está publicada en AI News bajo el título «Marinela Profi, SAS: On governing autonomous AI agents», y los datos cuantitativos vienen del SAS Data & AI Impact Report, accesible desde la web de SAS.