Cómo auditar agentes de IA

Un agente de IA puede revisar una factura, consultar el ERP, comprobar un contrato, escribir al proveedor y preparar una acción de pago. El problema de control aparece cuando el sistema puede decidir qué herramienta utilizar, qué información combinar y qué acción ejecutar con intervención humana limitada.

Eso cambia el objeto de auditoría. En una aplicación generativa tradicional, gran parte de la revisión puede centrarse en calidad de respuestas, protección de datos y uso adecuado. En un agente, esas preguntas siguen siendo necesarias, pero son insuficientes. La unidad crítica de control es la cadena de acción: quién autorizó al agente, a qué puede acceder, qué puede hacer, cuándo requiere aprobación, qué estado conserva, qué registra y cuándo debe detenerse.

El cambio clave: de evaluar respuestas a gobernar acciones

Una arquitectura agéntica suele combinar instrucciones, un modelo, contexto y herramientas externas. Esas herramientas pueden leer archivos, consultar bases de datos, enviar mensajes, modificar registros, ejecutar código o iniciar transacciones. Una respuesta incorrecta puede detectarse antes de utilizarse; una acción incorrecta puede cambiar el entorno antes de que alguien la revise.

El NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0), cuya revisión está en curso, ofrece una estructura útil mediante Govern, Map, Measure y Manage: definir responsabilidades y límites, entender contexto y consecuencias, medir comportamiento real y gestionar incidentes, cambios y continuidad. NIST también lanzó en 2026 su AI Agent Standards Initiative, centrada en agentes capaces de acciones autónomas y en retos de seguridad, identidad, interoperabilidad y confianza.

ISO/IEC 42001:2023 aporta una perspectiva complementaria de sistema de gestión. No es una norma específica para agentes, pero sus requisitos sobre roles, riesgos, cambios, operación, monitoreo e información documentada, junto con controles sobre ciclo de vida, uso responsable y registros de eventos, ofrecen criterios relevantes para el entorno donde opera un agente.

La pregunta de auditoría, por tanto, no es solo “¿funciona?”, sino “¿puede actuar únicamente dentro de la autoridad que la organización decidió concederle?”

Empiece por el mapa de autoridad del agente

Antes de diseñar pruebas, el auditor necesita reconstruir el mapa de autoridad: qué identidad utiliza el agente, qué herramientas puede invocar, con qué permisos, en nombre de quién actúa y qué decisiones están fuera de su alcance.

El trabajo conceptual de NIST sobre identidad y autorización de agentes de software e IA es útil como señal de riesgo emergente, no como requisito obligatorio. Examina cuestiones como mínimo privilegio, prueba de autoridad para acciones específicas, delegación “en nombre de” una persona, vinculación con autorizaciones humanas y trazabilidad. Para auditoría, un permiso amplio porque “el agente podría necesitarlo” es una señal de debilidad. También lo son las credenciales compartidas que impiden distinguir acciones humanas de acciones del agente.

Ocho superficies de control que deben resistir pruebas

La siguiente matriz convierte los riesgos principales en evidencia y procedimientos. Debe ajustarse al caso de uso, nivel de autonomía, sensibilidad de los datos y consecuencias de una acción incorrecta.

Superficie de control	Riesgo principal	Evidencia esperada	Prueba de auditoría
Acceso a herramientas	Uso de herramientas o fuentes no aprobadas.	Inventario, arquitectura, conectores y propietarios.	Comparar herramientas disponibles en ejecución con la lista autorizada y comprobar que una no aprobada sea inaccesible.
Permisos y delegación	El agente puede leer, modificar o ejecutar más de lo necesario.	Identidad, roles, scopes, tokens y matriz de autorización.	Verificar mínimo privilegio e intentar una acción fuera del alcance autorizado.
Límites de acción	Una tarea legítima deriva en una acción no prevista.	Caso de uso, acciones permitidas/prohibidas y reglas de negocio.	Probar escenarios límite y confirmar rechazo, escalamiento o nueva autorización.
Aprobaciones humanas	Una acción sensible ocurre sin revisión efectiva.	Umbrales, matriz de aprobaciones, registros y requisitos de competencia.	Reejecutar casos de alto impacto y comprobar que no finalicen antes de una aprobación válida.
Memoria y estado	Contexto previo cruza usuarios, altera decisiones o persiste indebidamente.	Diseño de memoria, retención, aislamiento, borrado y reinicio.	Introducir estado controlado y verificar aislamiento, persistencia y eliminación según diseño.
Registro y trazabilidad	No puede reconstruirse qué hizo el agente ni quién lo autorizó.	Logs de acciones, herramientas, errores, aprobaciones, identidades y tiempos.	Muestrear ejecuciones y reconstruir la secuencia de extremo a extremo.
Excepciones y recuperación	El agente continúa ante ambigüedad, fallas o ejecución parcial.	Reglas de excepción, colas de revisión, rollback y takeover humano.	Forzar fallas previsibles y comprobar escalamiento, reversión o transferencia de control.
Condiciones de parada	El agente entra en bucles o continúa cuando el riesgo excede un límite.	Límites de tiempo, coste o acciones; alertas; procedimiento de desactivación.	Activar una condición de parada y verificar que cesen nuevas acciones y quede registro.

Dos matices son importantes. La memoria del agente no es una categoría normativa independiente de ISO/IEC 42001; conviene tratarla como estado y datos gobernados: origen, persistencia, aislamiento, retención y efecto sobre acciones futuras. Del mismo modo, una “aprobación humana” en un diagrama no demuestra supervisión efectiva. La aprobación debe ocurrir antes de la acción relevante, aportar información suficiente y permitir realmente rechazar, modificar o detener.

ISO/IEC 42001 refuerza esta lógica con controles sobre requisitos, verificación y validación, despliegue, operación y monitoreo, documentación técnica y registro de eventos. El auditor debe traducir esos conceptos a la arquitectura específica del agente, no conformarse con la existencia de una política general de IA.

Pruebe escenarios, no solo configuraciones

La configuración demuestra diseño; no prueba que el control opere durante una ejecución real. Una auditoría avanzada debería combinar al menos tres familias de escenarios: camino normal, para observar herramientas, aprobaciones y resultados; límites y negativas, para solicitar acciones fuera de alcance o exceder umbrales; y contenido no confiable, para comprobar que instrucciones externas no alteren la tarea legítima ni la autoridad concedida.

Esta última categoría es especialmente relevante para agentes que leen correos, archivos o sitios web. El trabajo técnico de NIST sobre agent hijacking muestra cómo una inyección indirecta puede inducir acciones no previstas. Auditoría puede diseñar pruebas controladas; la evaluación ofensiva profunda puede requerir apoyo de ciberseguridad o especialistas en IA.

También deben probarse estado, recuperación y parada. ¿Una memoria contaminada influye en la siguiente tarea? ¿Una acción parcial puede revertirse? ¿Un operador puede asumir el control sin perder trazabilidad? El NIST AI RMF Playbook vincula el monitoreo posterior al despliegue con override, respuesta a incidentes, recuperación, cambios y desmantelamiento. En un agente, eso debe materializarse en límites observables de tiempo, pasos, coste, tipo de acción, exposición de datos u otros umbrales del caso de uso.

La evidencia debe reconstruir lo que ocurrió

Un expediente sólido no es una colección de capturas de pantalla. Debe permitir reconstruir una ejecución completa y relacionar la solicitud original con la identidad del agente, contexto relevante, herramientas invocadas, decisiones de autorización, cambios de estado, aprobaciones, excepciones y resultado.

ISO/IEC 42001 establece controles para determinar dónde son necesarios los registros de eventos y exige, como mínimo, habilitarlos cuando el sistema está en uso. Por eso, el muestreo debería centrarse en ejecuciones completas, incluyendo éxitos, rechazos, excepciones, acciones de alto impacto e incidentes. Los registros deben permitir que otra persona competente siga la secuencia sin depender de la explicación del desarrollador.

La autonomía madura es autonomía limitada y observable

La madurez de un agente no se mide por cuántas decisiones elimina de la intervención humana. Se mide por la claridad con la que la organización define autoridad, limita acciones, observa comportamiento y puede intervenir.

Auditoría interna no necesita convertirse en desarrolladora de agentes para comprobar identidad diferenciada, mínimo privilegio, aprobaciones significativas, memoria gobernada, trazabilidad y condiciones de parada. Los modelos y protocolos cambiarán; un enfoque centrado en autoridad, acción, evidencia e intervención seguirá siendo útil porque evalúa no solo lo que el agente dice, sino aquello que la organización le permite hacer.