La auditabilidad de agentes es la capacidad de reconstruir sus acciones y revisar la evidencia que las respalda. Una conversación conserva lo que se dijo. Un rastro de auditoría también debe explicar qué identidad actuó, qué podía hacer, qué herramienta se ejecutó, qué fuente informó la respuesta y qué cambió.
Registra decisiones en el límite del servicio
Asigna identificadores estables a cada ejecución y llamada a herramientas. Registra usuario, decisión de autorización, versión de la herramienta, tiempos, resultado y referencias a artefactos relevantes. Conserva las versiones del modelo y del prompt junto al registro de ejecución. El servicio de la herramienta debe registrar lo que realmente ejecutó, sin depender de la descripción del modelo.
No asumas que debes guardar todos los datos para siempre. Define campos permitidos, redacción de información sensible, acceso a los registros y plazos de retención. Una auditoría que expone datos del cliente abre otra superficie de incidentes.
Evento de auditoría ilustrativo:
run_id / tool_call_id / actor_reference
operation / tool_version / authorization_decision
started_at / finished_at / outcome / artifact_references
Estos campos son un punto de partida, no un estándar de cumplimiento. El registro debe responder a las operaciones y preguntas que la organización necesita investigar.
Distingue observar de justificar
Una traza puede mostrar que una herramienta se ejecutó. Eso no demuestra automáticamente que el usuario tuviera permiso, que los datos respaldaran la conclusión o que el despliegue estuviera justificado. Adjunta la evidencia correspondiente a cada decisión. Para un release puede incluir configuración evaluada, resultados de pruebas, aprobación e identidad desplegada.
Mi preprint From Traceability to Justifiability examina esta diferencia en registros públicos de entrega de software. Sus hallazgos corresponden a una muestra y una fecha de observación definidas. El paper y su repositorio permiten revisar el método, en lugar de aceptar una afirmación general sobre todos los pipelines de agentes.
Comprueba si el rastro responde a una pregunta de incidente
Toma una acción fallida o disputada e intenta reconstruirla sin preguntarle al agente original. ¿Otro revisor puede identificar argumentos reales, decisión de permisos y resultado? ¿Puede distinguir un intento de una modificación confirmada? ¿Puede reconocer evidencia faltante sin recibir una explicación inventada?
Prueba ejecuciones interrumpidas, operaciones denegadas, reintentos y fallos parciales. Comprueba que la información sensible siga protegida cuando alguien consulta la auditoría.
Qué evidencia pedir al elegir un ingeniero
Pide una reconstrucción de incidente y los registros que la sustentan. Busca límites claros entre lo observado por el sistema, lo inferido por el ingeniero y lo que todavía se desconoce. Los casos de MetaMCP y del harness de evaluación muestran trabajo de implementación; la investigación explica las preguntas de responsabilidad que lo orientan.