Auditoría técnica de agentes de IA: trazabilidad, logs y evidencia de ejecución

Cuando un auditor pregunta qué hizo un agente el martes a las tres de la tarde, la respuesta tiene que salir de un registro verificable, no de una reconstrucción hecha a las apuradas. Esta guía completa el marco de gobernanza de agentes de IA con el detalle técnico de qué evidencia dejar, cómo protegerla y cómo se lee frente a ISO 42001 y el EU AI Act.

Qué evidencia exige un auditor: quién, qué, cuándo, con qué autorización, con qué resultado

Un auditor técnico —interno, externo o el propio equipo durante la respuesta a un incidente— no pregunta "¿tienen una política de IA?". Pregunta, sobre una acción específica: ¿quién la ejecutó, qué hizo exactamente, cuándo, bajo qué autorización, y qué resultado produjo? Cinco elementos, y los cinco tienen que estar en el mismo registro, no repartidos entre un log de aplicación, la memoria de alguien y un canal de chat.

• Quién: la identidad propia del agente que ejecutó la acción, y el principal humano responsable de la sesión o tarea que la originó. No "el sistema" ni "el bot": una identidad atribuible.
• Qué: la capacidad concreta invocada y sus parámetros reales —qué archivo, qué endpoint, qué monto, qué recurso—, no una descripción genérica como "operación en base de datos".
• Cuándo: un timestamp de una fuente de tiempo confiable, no el reloj local de un proceso que puede desincronizarse.
• Con qué autorización: qué política se evaluó, en qué clase de riesgo cayó la acción, y si requirió aprobación humana, quién la dio y cuándo.
• Con qué resultado: qué devolvió el sistema, incluidos los errores y los intentos denegados —una acción bloqueada es tan parte de la evidencia como una acción ejecutada.

Si alguno de estos cinco elementos requiere reconstrucción manual en vez de una consulta directa al registro, hay una brecha de auditabilidad, aunque el sistema funcione bien en la práctica.

Logs de aplicación vs. evidencia de decisión

Es un error común asumir que los logs que ya genera una aplicación cumplen esta función. Un log de aplicación típico registra que algo ocurrió: una función se llamó, un endpoint respondió, un proceso terminó. Es información operativa, pensada para depurar errores de software, no para responder si una acción estaba autorizada.

La evidencia de decisión es otra cosa: registra por qué se permitió (o se bloqueó) que la acción ocurriera. Qué política se evaluó contra qué identidad, qué nivel de riesgo se asignó, si hubo un gate de aprobación humana y cuál fue su resultado. Esta capa suele no existir en absoluto en arquitecturas que solo tienen logging de aplicación, porque la decisión de autorización nunca quedó materializada como un evento propio — pasó, implícita, dentro del código, sin dejar rastro separado de la ejecución misma.

La distinción importa porque son los logs de decisión, no los de aplicación, los que un auditor necesita para verificar control: un log de aplicación prueba que algo pasó; un registro de decisión prueba que estaba permitido que pasara, y por qué.

Audit trail append-only y cadena de hashes, en términos de negocio

Un registro que se puede editar después de escrito no sirve como evidencia, sin importar cuán completo sea su contenido: si el propio agente, un administrador con acceso a la base o un atacante con esas credenciales puede modificar una entrada, nada garantiza que lo que ves hoy sea lo que ocurrió entonces. El requisito es un registro append-only: solo se puede agregar, nunca modificar ni borrar una entrada existente.

Que nadie edite el registro por las buenas no alcanza; hace falta que la edición sea detectable si alguien la intenta. Ahí entra la cadena de hashes: cada entrada nueva incluye el hash (una huella digital matemática) de la entrada inmediatamente anterior —el prevHash—, el mismo principio que sostiene la integridad de un blockchain. Si alguien altera una entrada pasada, su hash cambia y rompe el encadenamiento con la entrada siguiente, que sigue apuntando al hash original. La ruptura queda expuesta con solo recorrer la cadena.

Sobre eso, una firma HMAC-SHA256 agrega una segunda barrera: cada entrada se firma con una clave secreta que un atacante externo, o incluso un administrador sin esa clave, no puede reproducir. En términos de negocio: no es solo que nadie debería editar el historial, es que técnicamente no puede hacerlo sin dejar una prueba matemática de que algo no cuadra.

Cómo se detecta la manipulación del registro

La detección no depende de que alguien "note algo raro" revisando manualmente miles de entradas. Es un proceso mecánico: recorrer la cadena en orden, recalcular el hash de cada entrada y confirmar que coincide con el prevHash que la entrada siguiente declara, y validar la firma HMAC de cada una contra la clave del sistema. Si una sola entrada fue alterada, insertada fuera de orden o borrada, la verificación falla en el punto exacto de la ruptura, no en un lugar aproximado.

Esta verificación puede automatizarse y correr de forma periódica o bajo demanda, lo que la vuelve un control continuo y no una auditoría forense que solo se hace después de que algo salió mal. Poder correrla en cualquier momento —y mostrar el resultado a un auditor— es en sí mismo parte de la evidencia.

Mapeo a ISO 42001 y al EU AI Act (art. 12)

ISO/IEC 42001:2023 establece los requisitos para un sistema de gestión de IA (AIMS) certificable. Entre su documentación exigida están los registros del ciclo de vida de los sistemas de IA: evidencia de que la organización efectivamente opera los controles que declara, no solo que los documentó. Un audit trail append-only de las acciones de tus agentes —con las cinco dimensiones descriptas arriba— es exactamente el tipo de registro operativo que ese requisito busca.

El EU AI Act (Reglamento UE 2024/1689), en su artículo 12, exige que los sistemas de IA de alto riesgo cuenten con capacidad de registro automático de eventos (logging) durante todo su ciclo de vida operativo, para asegurar un nivel de trazabilidad adecuado al propósito del sistema. Un pipeline con audit trail append-only, atribución por identidad y registro de decisiones de aprobación responde directamente a esa exigencia para agentes que califiquen como alto riesgo, y es buena práctica razonable incluso para los que no califiquen.

Una precisión importante: ni ISO 42001 ni el EU AI Act se satisfacen instalando una herramienta. ISO 42001 certifica el sistema de gestión de tu organización en su conjunto, y el EU AI Act impone obligaciones legales que dependen de cómo opera tu empresa entera, no de qué software corre por debajo. Tener evidencia técnica sólida es condición necesaria para ambos marcos —y la parte que más rápido se cae si no se diseñó desde el principio— pero no es, por sí sola, condición suficiente.

Cómo lo implementa NexusOS

El último gate del pipeline de NexusOS —identidad → capability → contrato → política → permisos → riesgo → aprobación → PEP → ejecución → auditoría— escribe cada acción, permitida, denegada o aprobada, en un audit trail append-only con cadena de prevHash y firma HMAC-SHA256, atribuido a la identidad que la originó y con la decisión completa de cada gate anterior. Sobre ese diseño corre una suite de más de 1.300 tests que valida, entre otras cosas, la integridad de la cadena y la correcta atribución de cada evento. Podés ver el registro generándose en tiempo real frente a una acción evaluada en la demo interactiva.

Este registro es también la materia prima del control de aprobación humana: human-in-the-loop para agentes de IA detalla cómo se diseña ese gate para que la evidencia que deja sea real, y no un trámite. Y el punto donde toda esta cadena de decisiones se hace cumplir en el momento está en control de ejecución de agentes de IA.

Preguntas frecuentes

¿En qué se diferencia esto de una auditoría de gobierno corporativo?

Una auditoría de gobierno corporativo —el terreno clásico de las Big Four— revisa políticas, comités, roles y procesos en papel: si existe una política de uso de IA, si hay un comité que la aprobó, si hay un registro de casos de uso. La auditoría técnica de agentes de IA revisa otra cosa: si esas políticas efectivamente se hicieron cumplir en el momento en que un agente actuó, y si existe evidencia técnica —no una declaración— de cada acción, cada decisión y cada aprobación. Son complementarias: la primera audita el diseño de la gobernanza, la segunda audita su ejecución real.

¿Alcanza con los logs que ya genera nuestra aplicación?

Casi nunca alcanza tal como están. Los logs de aplicación típicos registran que algo pasó (una función se ejecutó, una API respondió 200) pero no por qué se permitió que pasara: qué política se evaluó, qué identidad estaba detrás, qué nivel de riesgo se le asignó, quién aprobó si hizo falta aprobación. Esa capa de decisión suele no existir como registro separado. Además, los logs de aplicación rara vez tienen protección de integridad: cualquiera con acceso de escritura al sistema de logging puede editarlos, lo que los vuelve poco útiles como evidencia ante un auditor exigente.

¿ISO 42001 o el EU AI Act certifican automáticamente que mis agentes están bien gobernados?

No. Ninguna herramienta ni plataforma te certifica por sí sola: ISO/IEC 42001 certifica al sistema de gestión de tu organización, no a un producto de software, y el EU AI Act impone obligaciones legales que tu empresa cumple o no cumple según cómo opera en conjunto, no según qué software use. Tener un audit trail append-only con integridad verificable es evidencia necesaria para ambos marcos —sin registros, la conversación con un auditor ni empieza— pero no sustituye el resto del sistema de gestión, la evaluación de riesgo del caso de uso ni la documentación técnica que cada marco exige.

¿Cómo se detecta si alguien manipuló el registro de auditoría?

En un audit trail append-only con cadena de hashes, cada entrada incluye el hash de la entrada anterior. Si alguien edita, borra o inserta un registro fuera de secuencia, el hash de esa entrada deja de coincidir con lo que la siguiente entrada esperaba, y la ruptura es matemáticamente detectable con solo recorrer la cadena y recalcular. Si además cada entrada está firmada con una clave —por ejemplo HMAC-SHA256— que el atacante no controla, ni siquiera alguien con acceso de administrador a la base de datos puede fabricar una entrada nueva que pase la verificación sin la clave correspondiente.