Blog · Guía · 28 de octubre de 2026
Lista de trazabilidad para agentes de IA en producción: qué registrar, qué firmar y qué mostrar a quien revisa
Aviso: en 100monkeys.ai construimos AEGIS, un orquestador de agentes de código abierto, y mantenemos la lista awesome-agent-traceability que se cita más abajo. Esta lista de verificación es neutral respecto a proveedores: cada punto se puede cumplir con herramientas abiertas y ninguno requiere nuestros productos. La redactó uno de nuestros agentes de IA y la revisó la empresa; esta versión en español es una traducción del original en inglés.
Cuando un agente de IA actúa sobre un sistema real, tarde o temprano alguien preguntará qué hizo y por qué. Esta lista es el trabajo que hay que hacer antes de que llegue esa pregunta: qué registrar en cada ejecución, qué firmar para que el registro sea fiable y qué poner delante de la persona que lo revisa. Cada punto nombra un estándar o herramienta abierta de la lista awesome-agent-traceability.
El marco viene de nuestro artículo Red levers: traceable, deterministic agents in production (en inglés), que define un sistema de agentes como seguro en producción cuando una persona puede ver cada decisión que tomó, por qué la tomó, y detenerlo. El registro sirve a lo primero, el motivo registrado a lo segundo y el paso de revisión a lo tercero.
Parte 1. Qué registrar
Paso 1. Da a cada ejecución una identidad
Asigna a cada ejecución un id al empezar y llévalo por cada llamada al modelo, cada llamada a herramienta y cada efecto secundario. Sin él, un log es un montón de eventos que nadie puede agrupar. Usa ids de traza y de span de las convenciones semánticas de OpenTelemetry para IA generativa, que definen nombres comunes para llamadas a modelos, pasos de agentes e invocaciones de herramientas, de modo que las trazas de distintos frameworks se lean igual. Las convenciones para spans de agentes cubren la creación e invocación de agentes.
Paso 2. Registra la petición y la intención, con palabras
Registra qué se le pidió al agente, quién lo pidió y el motivo que se le dio. Después, en cada acto con consecuencias, registra la frase del propio agente sobre por qué lo hace. Un motivo escrito en el momento del acto es evidencia; un motivo reconstruido después es un relato.
Paso 3. Registra el modelo y su configuración
Para cada llamada al modelo: proveedor, nombre y versión del modelo, los parámetros que cambian la salida (temperatura, máximo de tokens, herramientas ofrecidas) y el recuento de tokens. Un comportamiento que no puedes atar a una versión del modelo no se puede reproducir cuando el proveedor lo actualiza.
Paso 4. Registra cada llamada a herramienta con sus entradas y salidas
Anota la herramienta, los argumentos, el resultado y la hora. Elimina los datos personales antes de guardarlos, no después; Presidio es una opción abierta. Una llamada que escribió en algún sitio debe registrar también qué cambió: el diff, el id del registro, el id del mensaje.
Paso 5. Registra cada decisión de política
Si un motor de políticas permitió o rechazó una llamada, registra la decisión y la regla que la tomó. Open Policy Agent guarda logs de decisiones justo para esto. Un rechazo es tan importante de conservar como un permiso: demuestra que el límite se mantuvo.
Paso 6. Registra la identidad y el alcance
Registra qué credencial o token usó la ejecución y a qué podía llegar esa credencial, no su valor secreto. La pregunta de quien revisa suele ser "¿podría haber hecho algo peor?", y la respuesta es el alcance que tenía.
Paso 7. Haz que la ejecución sea reproducible
Guarda lo suficiente para volver a ejecutar el trabajo: las entradas, el estado en cada paso y el orden de los eventos. Los motores de ejecución duradera como Temporal conservan un historial de eventos del workflow que permite reproducirlo de forma determinista.
Parte 2. Qué firmar
Paso 8. Haz el registro de solo anexado y encadenado
Un registro que se puede reescribir después no prueba nada. Escribe los eventos en un almacén de solo anexado y encadena cada entrada a la anterior mediante un hash, de modo que una entrada borrada o editada rompa la cadena. El grupo de trabajo SCITT del IETF define declaraciones firmadas registradas en servicios de transparencia de solo anexado, una forma ya hecha para esto.
Paso 9. Firma lo que produjo el agente
Cuando una ejecución produce un artefacto (un build, un informe, un archivo publicado), adjunta una declaración firmada de cómo se hizo. El in-toto Attestation Framework transporta ese tipo de declaraciones, y SLSA define niveles de procedencia de builds. Para contenido multimedia, la especificación C2PA adjunta manifiestos de procedencia firmados, también para contenido producido o editado por IA.
Paso 10. Firma la aprobación
Si una persona aprobó un acto, registra quién lo aprobó, cuándo y exactamente qué vio. Vincula la aprobación al contenido: si el acto cambia después de aprobarse, la aprobación deja de valer.
Parte 3. Qué mostrar a quien revisa
Paso 11. Muestra el acto, no un resumen
Quien revisa debe ver el correo, el diff o el comando que se va a ejecutar, generado a partir de la propia salida de la ejecución. Un resumen escrito por el mismo modelo que busca la aprobación no es una superficie de revisión.
Paso 12. Muestra el motivo junto al acto
Pon la intención registrada del agente al lado del cambio que hizo. "¿Por qué está esta línea aquí?" debería responderse con la frase escrita cuando la línea entró.
Paso 13. Muestra los límites bajo los que corrió
Muestra la política y el alcance de la credencial junto a la ejecución. Quien ve que el agente solo podía escribir en una rama lee la ejecución de otra manera que quien tiene que suponer que podía llegar a todo.
Paso 14. Dale a quien revisa un botón de parada
Toda pantalla de revisión necesita una forma de rechazar, y el rechazo tiene que mantenerse. El artículo 14 de la Ley de IA de la UE, tal como se cita en Red levers, pide que las personas que supervisan sistemas de alto riesgo puedan "intervene in the operation of the high-risk AI system or interrupt the system" (intervenir en el funcionamiento del sistema o interrumpirlo). Citarlo aquí habla de la forma del control, no es una afirmación de cumplimiento.
Compruébalo tú mismo
Elige una ejecución de la semana pasada e intenta responder solo con los registros: quién lo pidió, qué llamó el agente, qué cambió, bajo qué política, quién lo aprobó y si el registro pudo editarse desde entonces. Cada pregunta que no puedas responder corresponde a uno de los pasos anteriores.
Cómo lo aplicamos
Construimos herramientas para partes de esta lista. AEGIS by 100monkeys.ai, in beta, es un orquestador autoalojado que ejecuta agentes en entornos aislados, con políticas aplicadas y estado duradero; Cómo dar a un orquestador un paso de aprobación muestra su compuerta de aprobación como ejemplo práctico, y esta guía de instalación lo pone en marcha en un servidor. Carbon Forge guarda código y texto en un solo registro donde el blame muestra la intención escrita en el momento de integrar el cambio.