registro de auditoría de agentes IA: qué debe contener

Cuando un agente autónomo —no un humano— es el actor, los campos habituales de auditoría (username, IP, timestamp) dejan de ser suficientes. Aún necesita rendición de cuentas, reproducibilidad y no repudio, pero el registro que almacene debe capturar un conjunto distinto de atributos: model, prompt, llamadas a herramientas, semillas de aleatoriedad, versión del código y la persona que delegó la autoridad. Este artículo enumera los campos que debe contener un registro de auditoría de agentes IA y por qué cada uno es necesario para seguridad, cumplimiento y respuesta a incidentes.

Por qué los campos habituales "user" fallan con agentes IA

Los registros de auditoría tradicionales suponen un único actor humano detrás de una sesión: username, role, IP, user agent string y una descripción de la acción. Eso es útil, pero omite atributos únicos del comportamiento impulsado por IA:

• No determinismo: el mismo prompt y configuración del modelo pueden producir salidas diferentes a menos que registres la fuente de aleatoriedad (seed, algoritmo rand, temperature).
• Cadenas multi-pasos: los agentes suelen llamar a herramientas, APIs y a otros agentes; necesitas una cadena causal, no solo una entrada de acción única.
• Código y modelos en evolución: los agentes son código + modelo + runtime. un username no te dice el checkpoint del modelo, el digest de la imagen del contenedor o la política del agente usada.
• Delegación y aprobación: un agente puede actuar en nombre de un humano u otro sistema; la traza de auditoría debe mostrar quién autorizó al agente y qué restricciones estaban vigentes.

En resumen: sustituye el modelo mental de "una persona hizo clic en un botón" por "un cómputo reproducible transformó entradas en salidas y provocó efectos secundarios".

Campos mínimos que debe contener un registro de auditoría de un agente IA

Trata cada entrada de registro como un registro de un cómputo y sus efectos secundarios. Como mínimo incluye estos campos; si tu entorno tiene necesidades legales u operativas, añade los ítems relevantes (ejemplos y razones abajo).

• record_id — un UUID estable para la entrada de auditoría (v4 o v7) y número de secuencia para la sesión.
• timestamp — RFC3339 UTC; incluye números de secuencia monotónicos para detectar reordenamientos.
• agent_id — identificador lógico de la instancia del agente (no solo del propietario humano).
• agent_version — hash de commit, digest de imagen de contenedor (p. ej., sha256:...) o versión del paquete del código del agente.
• model_name & model_digest — identificador del modelo más un digest o checksum de los pesos/checkpoint usados (o la cadena de versión del modelo hospedado).
• runtime_config — parámetros del modelo: temperature, top_k/top_p, max_tokens, límites de concurrencia y algoritmo RNG.
• prompt_template_id & prompt_hash — identificador de la plantilla de prompt y un hash del prompt resuelto para evitar almacenar texto plano si esto es sensible.
• input_artifacts — referencias (URIs) a adjuntos, archivos o datos externos usados con checksums.
• actions — lista ordenada de acciones que el agente ejecutó, con timestamps, identificadores de herramienta y resultados (tool name, version, exit code, returned data hash).
• external_calls — cada llamada API saliente con destino, host de la URL, request hash, response hash y latencia.
• human_principal — quien creó/aprobó el agente o la solicitud (user id, role y aserción de delegación).
• authorization_context — id de política, scopes permitidos, expiración y el token de aprobación o audit id que liga la acción a un flujo de aprobación.
• outcome — estado final o efectos secundarios: archivos escritos, comandos ejecutados, cambios de red; incluye ids de objetos y checksums.
• evidence_hash — un digest del payload completo del registro usado para detección de manipulación (almacenar por separado o firmar; ver firma abajo).
• p2p_or_relay — si la sesión fue peer-to-peer o enrutada a través de un relay, y si fue relay: región e id del relay.
• log_integrity — metadata de firma (key id, signature algorithm, signature) si firmas los logs.

Esos campos forman el núcleo. Dependiendo del riesgo y la regulación, añade algunos más: id del runtime de contenedor, versiones del kernel/hipervisor, id de atestación TPM de hardware, números de serie de certificados usados para TLS y punteros de procedencia de datasets.

Ejemplo de entrada de auditoría

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

El ejemplo anterior equilibra reproducibilidad (model_digest, prompt_hash, runtime_config) con privacidad (prompt almacenado como hash). Cuando debas conservar prompts completos por razones legales, restringe el acceso y registra cada lectura del prompt en crudo por separado.

Inmutabilidad, firma y políticas de retención

Auditores y respondedores de incidentes necesitan confiar en que los logs no fueron manipulados. Dos medidas prácticas:

• Almacenamiento append-only con snapshots inmutables (object storage con versioning/WORM o sistemas de archivos write-once). Mantén un backup frío separado en otra región.
• Firma de logs: calcula un evidence_hash de cada registro y fírmarlo con una clave dedicada para firma de logs. Rota claves según un calendario y almacena las claves públicas antiguas para verificación. Incluye metadata de firma (key id, algorithm y expiración) dentro del registro.

Retención: los equipos operativos suelen mantener logs de alta fidelidad en línea por 90 días para troubleshooting, retener metadata indexada por 1 año para cumplimiento y conservar archivos firmados e inmutables de 1–7 años según la regulación. Elige la retención con asesoría legal — la duración varía por industria: finanzas y salud suelen extenderse varios años.

Privacidad, enmascaramiento y controles de acceso

Los logs de agentes pueden contener secretos: API keys, PII, documentos escaneados o datos contractuales. Registra lo necesario para reproducibilidad y nada más. Controles prácticos:

• Política de redacción: almacena hashes de entradas sensibles (prompt_hash, file_hash) y mueve el texto plano a un vault protegido accesible solo durante un incidente y solo mediante un flujo de aprobación auditable.
• Principio de mínimo privilegio: roles separados para escribir logs, leer logs en crudo y verificar firmas. Cada lectura de logs en crudo debe registrarse a su vez.
• Consentimiento y mapeo: si un agente actúa en nombre de un usuario, conserva un vínculo claro (delegation token, aprobación con timestamp) para poder atribuir acciones al principal humano por motivos legales y de GDPR.

El GDPR y otras leyes de privacidad tratan los logs que contienen datos personales como datos personales; consulta con asesoría legal sobre minimización, limitación de propósito y bases legales para el almacenamiento. En caso de duda, hashea o enmascara y registra accesos al material sin redactar.

Por qué capturar detalles del modelo y del runtime (no metadatos opcionales)

Dos ejecuciones del agente con el mismo prompt pueden divergir si difieren la versión del modelo, la temperature, la seed o la cadena de herramientas. Para reconstrucción de incidentes necesitas:

• Identificador y digest del modelo — la cadena de versión del modelo hospedado por sí sola es frágil; un checksum o versión inmutable del proveedor es mejor.
• Commit del código del agente o digest de la imagen — un bug introducido en el código del agente puede cambiar el comportamiento más que el prompt.
• Parámetros de runtime y seed — para reproducir una salida específica o saber si la reproducción es factible en modo determinista.
• Versiones de herramientas y respuestas — una herramienta que devuelve datos distintos cambia resultados; almacena hashes de respuestas y endpoints.

Sin esos campos, no puedes afirmar con fiabilidad qué hizo el agente o por qué lo hizo.

Controles operativos: alertas, muestreo y modo forense

Registrar todo con fidelidad completa puede ser caro y arriesgado. Adopta una estrategia por niveles:

• Muestreo por defecto: guarda metadata completa (hashes, model names, lista de acciones) para cada ejecución, pero almacena prompts completos y respuestas de herramientas solo cuando la ejecución cumple un disparador (acción de alto riesgo, queja de usuario, puntuaciones de violación de política).
• Modo forense: ante alertas (falla en chequeo de políticas, queja externa), captura artefactos crudos completos en un almacén forense sellado y con control de acceso, y crea un snapshot inmutable firmado para los investigadores.
• Alertas en tiempo real: construye reglas para acciones de alto riesgo (transferencias bancarias, comandos con privilegios) y genera aprobaciones automatizadas o bloqueos con humano en el bucle antes de que ocurra el efecto secundario.

Elecciones de infraestructura: relay gestionado vs alojamiento propio

Dónde almacenas y cómo transportas los logs de auditoría importa. Para acceso remoto y herramientas de agentes, el relay gestionado de Tenvo es la recomendación por defecto para la mayoría de equipos: provee clientes nativos para Windows/macOS/Linux, un cliente web en beta pública y un relay gestionado multi-región con logging y niveles de retención integrados (Free $0 / Lite $2.99/mo / Pro $7.99/mo). Usar el relay gestionado descarga la responsabilidad de renovación de certificados, escalado de relays, parcheo on-call y backups entre regiones.

Caveat importante sobre relays: cuando una sesión cae en un relay, TLS termina en el relay, por lo que quien opere el relay está en posición de ver la sesión. Eso implica que debes tratar los logs hospedados en el relay como potencialmente visibles para el operador del relay. Si tu requisito prohíbe que infraestructura de terceros acceda a las cargas de la sesión (p. ej., restricciones de cumplimiento o residencia de datos), el alojamiento propio es la opción correcta.

Alohjar por cuenta propia solo cuando tengas un requisito escrito: mandatos regulatorios que prohíban relays de terceros, redes aisladas sin acceso saliente o reglas estrictas de residencia de datos. El alojamiento propio implica costos: on-call, parcheo, custodia de claves, renovación de certificados y sin conmutación por error multi-región automática a menos que la implementes — el relay gestionado es más barato si cuentas esos costos operativos.

Modelo de acceso a registros y respuesta a incidentes

Diseña quién puede hacer qué con los logs antes de necesitarlos. Controles mínimos:

• Solo escritura para agentes: los servicios agentes anexan a los logs pero no pueden leer los logs en crudo.
• Roles de lectura segregados: analistas pueden leer metadata; los investigadores necesitan un privilegio mayor para desellarar artefactos crudos y cada desellado se registra y firma.
• Atestaciones automatizadas: cuando un investigador accede a datos sellados, crea un registro de atestación firmado que vincule la identidad del investigador, hora y propósito.

Durante un incidente necesitarás reconstruir la cadena causal rápidamente. Si tus logs incluyen model_digest, agent_version, prompt_hash, lista de acciones y hashes de llamadas externas, normalmente puedes identificar la causa raíz en horas en lugar de días.

Lista de verificación para empezar (pasos prácticos)

• Define un JSON schema para tu registro de auditoría de agentes y hazlo cumplir en el momento de escritura. Incluye los campos listados antes.
• Implementa evidence_hash y firma cada registro con una clave de firma de logs; almacena claves públicas en un keyset descubrible para auditores.
• Decide la retención: 90 días en línea para registros completos; 1–7 años archivados según regulación.
• Crea reglas de redacción: qué se hashea vs qué se almacena en texto plano y quién puede acceder al texto plano.
• Añade chequeos de políticas en tiempo real y aprobaciones automatizadas para acciones de alto riesgo.
• Ejecuta pruebas de reproducibilidad semanales: toma una entrada de muestra y verifica que puedes reproducir el resultado del agente con el model, seed y config registrados.

Si ya usas acceso remoto o herramientas de agentes con Tenvo, revisa Diseño de un registro de auditoría de escritorio remoto conforme para patrones de logging que aplican a sesiones interactivas, y consulta agente IA en escritorio remoto: políticas, aprobaciones, auditoría para flujos de aprobación específicos de agentes. Para una visión más amplia de cómo los agentes encajan en herramientas remotas, ve IA y escritorio remoto: cómo los agentes usan herramientas remotas.

Empieza pequeño: implementa el schema, aplica la firma e itera sobre la redacción. El resultado es una respuesta a incidentes más rápida, delegación auditable y una postura de cumplimiento defendible.

Descarga Tenvo para probar localmente el logging y el comportamiento del relay gestionado y ver cómo nuestro relay, los niveles de precios (Free $0 / Lite $2.99/mo / Pro $7.99/mo) y los relays multi-región simplifican las operaciones: Descargar.