IA agéntica: nuevos riesgos de las acciones autónomas

Un agente de compras recibe una instrucción sencilla: acelerar el abastecimiento de un componente crítico. Consulta inventario, revisa correos, compara proveedores y prepara una orden. Hasta ahí, parece una versión más rápida de un asistente digital. El riesgo cambia cuando también puede ejecutar: crear la orden, modificar datos, enviar comunicaciones o invocar otras herramientas sin que una persona revise cada paso.

En un caso hipotético, una instrucción maliciosa escondida en un documento de proveedor induce al agente a seguir una ruta no prevista. Con credenciales demasiado amplias, ejecuta una transacción fuera de parámetros antes de que alguien la revise. El problema ya no es una respuesta incorrecta, sino una consecuencia empresarial real.

Esa es la tesis central para auditoría: a medida que aumenta la autonomía, el control debe desplazarse de revisar respuestas a gobernar autoridad, acciones y ejecución.

La frontera crítica es pasar de generar a actuar

Un sistema generativo puede redactar un correo equivocado. Un agente conectado a herramientas puede enviarlo, actualizar un registro, desplegar código, mover un caso a otra etapa o iniciar una transacción. El NIST AI Agent Standards Initiative, lanzado en 2026, refleja esta evolución hacia agentes capaces de realizar acciones autónomas y operar en nombre de usuarios. El NIST AI Risk Management Framework sigue siendo una referencia voluntaria para gestionar riesgos de IA; NIST indica que su versión 1.0 está actualmente en revisión. Los trabajos específicos sobre agentes siguen evolucionando y no son requisitos obligatorios.

No todos los agentes tienen el mismo nivel de autonomía. Para auditoría, importa menos la etiqueta comercial y más la combinación de capacidad de acción, permisos, duración, posibilidad de delegar y reversibilidad.

Patrón de uso	Qué puede hacer el sistema	Prioridad de control
Recomendar	Genera una propuesta; una persona actúa	Calidad y validación de la respuesta
Preparar	Completa borradores o formularios sin ejecutar	Integridad de datos y revisión humana
Ejecutar con aprobación	Invoca herramientas después de una autorización	Contexto de aprobación y segregación
Ejecutar dentro de límites	Realiza múltiples acciones sin aprobación individual	Permisos, límites, monitoreo y parada
Delegar o persistir	Encadena herramientas, memoria u otros agentes	Identidad, propagación de autoridad y trazabilidad extremo a extremo

El riesgo ya no termina en el modelo. Se extiende a identidades, APIs, credenciales, aplicaciones empresariales y reglas de autorización. Un agente mediocre con permisos estrechos puede ser menos peligroso que uno excelente con acceso excesivo.

Cuatro controles se vuelven decisivos con la autonomía

1. Identidad y permisos: saber quién actúa y con qué autoridad

El proyecto del NIST National Cybersecurity Center of Excellence sobre identidad y autorización de agentes parte de una pregunta básica: cómo identificar a los agentes, autorizar sus accesos y controlar las acciones que realizan. La preocupación es material porque los agentes suelen conectarse a múltiples fuentes de datos, herramientas y aplicaciones.

Una práctica débil es permitir que el agente herede las credenciales completas de un usuario. Eso dificulta distinguir si una acción fue realizada por la persona o por el agente y puede otorgar privilegios muy superiores a los necesarios. La orientación emergente de NIST apunta hacia identidades propias, delegación explícita, privilegio mínimo y autorizaciones ajustadas al contexto.

Para auditoría, la pregunta no es solo “¿tiene acceso?”, sino “¿qué autoridad exacta puede ejercer, durante cuánto tiempo y sobre qué objetos?”.

2. Límites de acción: controlar la transacción, no solo la herramienta

El acceso a un sistema no debe equivaler a autorización total. Un agente de compras puede consultar proveedores y preparar órdenes sin poder cambiar datos bancarios o superar umbrales. Un agente de desarrollo puede ejecutar pruebas sin desplegar directamente en producción.

Los controles más útiles suelen ser específicos de la consecuencia: límites de importe, listas de destinatarios permitidos, entornos autorizados, tipos de comandos, campos no modificables, segregación de funciones y aprobaciones adicionales para acciones irreversibles.

Aquí aparece una diferencia importante con los controles tradicionales de acceso. El objeto de control es la acción propuesta en su contexto, no únicamente la identidad que inició la sesión.

3. Condiciones de parada y recuperación: decidir cuándo el agente deja de intentar

Un agente puede explorar rutas alternativas para cumplir un objetivo. Esa flexibilidad crea valor, pero también puede amplificar un error. Si una herramienta falla, el agente puede intentar otra. Si un permiso es denegado, puede buscar una ruta distinta. Si una respuesta parece incompleta, puede repetir el proceso muchas veces.

ISO/IEC 42001:2023 exige procesos de evaluación y tratamiento del riesgo y que los controles necesarios queden documentados. Su guía de implementación sobre el ciclo de vida aborda, entre otros temas, supervisión humana, controlabilidad, monitoreo operativo, respuesta a fallas, actualizaciones y registros de eventos. La norma no prescribe una única “palanca de emergencia” para todos los agentes. En un sistema agéntico, una implementación razonable y basada en riesgo es definir criterios explícitos para detener, escalar o recuperar la ejecución.

Esos criterios pueden incluir superar un número de pasos, tiempo o coste; intentar una herramienta no autorizada; recibir denegaciones repetidas; detectar una desviación de política; entrar en una operación irreversible; o perder la capacidad de verificar el resultado. La parada solo es útil si existe además un mecanismo de toma de control humana, reversión o compensación cuando la acción ya produjo efectos.

4. Registros: reconstruir qué ocurrió, no solo qué respondió el modelo

Cuando un agente puede producir consecuencias, un registro de conversación es insuficiente. ISO/IEC 42001 incluye orientación para conservar registros de eventos u otra documentación de despliegue y operación que permita demostrar el uso previsto y apoyar la comunicación de problemas. El trabajo de NIST sobre identidad de agentes también pone énfasis en auditoría, no repudio, acciones e intención.

Un registro útil debería permitir reconstruir quién inició la tarea, qué identidad y autoridad usó el agente, qué herramientas y datos utilizó, qué acciones ejecutó, qué aprobaciones obtuvo, cuál fue el resultado y cuándo se produjo una intervención o parada.

La trazabilidad de un agente debe seguir la cadena de consecuencias, no quedarse en la cadena de mensajes.

“Human in the loop” no es un control automático

Colocar un botón de “Aprobar” delante de una acción no resuelve por sí mismo el riesgo. En agosto de 2026, una publicación del NIST sobre identidad en IA agéntica advirtió que depender demasiado de aprobaciones humanas puede generar fatiga de consentimiento: si el agente solicita permiso continuamente, el usuario puede habituarse a aceptar sin evaluar.

Una aprobación efectiva necesita ocurrir en puntos materialmente relevantes, mostrar suficiente contexto y permitir una negativa real. Para una transacción, por ejemplo, el aprobador debería ver el objeto, importe, contraparte, cambio respecto del estado anterior y razón de la acción. Pedir “¿permitir continuar?” veinte veces no crea control; puede crear una rutina de clics.

Por eso, el diseño más sólido combina autorizaciones preventivas bien acotadas con aprobaciones puntuales para excepciones o consecuencias significativas. El objetivo no es insertar una persona en cada paso, sino conservar responsabilidad y capacidad de intervención donde realmente cambia el riesgo.

Qué debería probar un auditor

La auditoría de IA agéntica no debería limitarse a políticas o diagramas. El control vive en la ejecución; una evaluación útil combina configuración, muestras de transacciones y pruebas de escenarios.

Pregunta de auditoría	Evidencia útil	Prueba posible	Señal de alerta
¿El agente tiene una identidad y autoridad propias?	Identidades de servicio, scopes, políticas de delegación, tokens	Comparar permisos reales con el caso de uso aprobado	Credenciales compartidas o acceso equivalente al usuario humano
¿Las acciones están limitadas por consecuencia?	Reglas de transacción, allowlists, límites monetarios, segregación	Intentar una acción fuera de límites en entorno controlado	El sistema confía solo en instrucciones del prompt
¿Puede detenerse y recuperarse?	Reglas de parada, runbooks, mecanismos de takeover y rollback	Simular error repetido, herramienta no prevista o pérdida de verificación	No existe criterio claro de parada o la intervención llega después del efecto irreversible
¿La ejecución es trazable?	Logs del agente, API, aplicación destino y aprobaciones	Reconciliar una muestra de ejecuciones entre sistemas	No se puede atribuir una acción o reconstruir su secuencia
¿Los cambios reabren la evaluación de riesgo?	Gestión de cambios, nuevas herramientas, permisos y versiones	Revisar un cambio reciente y su aprobación	Se agregan capacidades sin reevaluar autoridad, límites o monitoreo

Pruebas como inyección indirecta de prompts, escalamiento de privilegios o comportamiento adversarial suelen requerir especialistas. El auditor interno no necesita ejecutarlas todas, pero sí saber qué pregunta de aseguramiento debe responder, qué evidencia espera y dónde requiere competencia especializada.

El error de diseño es tratar al agente como un usuario muy rápido

Los agentes no solo aceleran pasos conocidos. Pueden seleccionar rutas, combinar herramientas y adaptar su secuencia en función de resultados intermedios. NIST ha señalado que esa velocidad y escala pueden amplificar debilidades históricas de identidad y acceso. Un permiso amplio puede convertirse en una superficie de riesgo mucho mayor cuando un sistema automatizado explora múltiples caminos en segundos.

La madurez no consiste en maximizar autonomía, sino en conceder la autonomía mínima que produce el valor esperado dentro de una arquitectura que limita consecuencias, registra acciones y permite detener la ejecución.

La pregunta que debería cerrar una revisión de IA agéntica es sencilla: ¿qué puede hacer este agente sin volver a pedir permiso, cómo sabríamos exactamente lo que hizo y cómo lo detendríamos antes de que un error se convierta en una cadena de acciones?

A medida que los agentes se integren en procesos financieros, operativos y tecnológicos, esa pregunta será una cuestión básica de gobierno, control interno y aseguramiento.