Auditar un agente no es guardar su prompt: es reconstruir la decisión
Por Equipo Quantum Developers
Resumir:
La trazabilidad de un agente es útil solo si un revisor puede reconstruir qué evidencia entró, qué política y versión decidieron, quién autorizó la acción y qué resultado produjo, sin reproducir la conversación completa. Guardar cada prompt puede parecer exhaustivo, pero mezcla contexto irrelevante, secretos y datos personales mientras deja sin responder la pregunta central: por qué una acción empresarial fue permitida.
La unidad auditable es la decisión
Un log técnico dice que una llamada terminó. Un expediente de decisión explica el vínculo entre una necesidad de negocio, la evidencia disponible, la regla aplicable, la autoridad y el efecto. Es la diferencia entre saber que el agente ejecutó una herramienta y saber por qué cambió una cuenta bancaria, bloqueó un pago o recomendó una excepción.
La familia de controles de auditoría y rendición de cuentas de NIST SP 800-53 Rev. 5 trata los registros como evidencia con contenido definido: tipo de evento, momento, lugar, fuente, resultado e identidad asociada. Ese principio es más útil que una transcripción indiscriminada. El registro debe responder preguntas de control, no acumular texto por reflejo.
Un sobre mínimo de evidencia
El sobre acompaña cada decisión material y mantiene referencias verificables. Su contrato puede incluir:
| Campo | Pregunta que responde |
|---|---|
| decision_id y object_ref | ¿qué decisión y objeto de negocio se revisan? |
| input_refs, hash y versión | ¿qué facturas, órdenes, eventos o datos vio? |
| observed_at y effective_at | ¿cuándo se conoció y cuándo era cierto cada dato? |
| policy_id y policy_version | ¿qué regla autorizaba o detenía la acción? |
| model_or_rule_version | ¿qué componente produjo la propuesta? |
| tool_call_refs | ¿qué sistemas se consultaron o modificaron? |
| proposed_action y reason_codes | ¿qué quiso hacer y con qué razones normalizadas? |
| actor, reviewer y approver | ¿quién propuso, revisó y autorizó? |
| timestamps y state_transition | ¿cómo avanzó por el flujo? |
| outcome_ref | ¿qué ocurrió realmente después de autorizar? |
| supersedes y appeal_ref | ¿qué corrección o impugnación cambió el expediente? |
| classification y retention | ¿quién puede verlo y cuánto tiempo se conserva? |
No todos los campos contienen el dato original. input_refs puede apuntar a una versión protegida con hash, control de acceso y política de retención. El revisor comprueba integridad y recupera el documento solo si tiene permiso.
Cuatro clases de evidencia que no deben confundirse
Evidencia de fuente identifica documentos, eventos y versiones que entraron. Evidencia de ejecución registra herramientas, respuestas, errores y reintentos. Evidencia de autoridad muestra permisos, segregación de funciones y aprobación. Evidencia de resultado confirma si el cambio llegó al sistema destino y qué efecto produjo.
Un agente puede razonar correctamente y fallar al escribir; también puede ejecutar una operación técnicamente válida sin autoridad. Un único estado “success” es incapaz de distinguir ambos casos. La línea de tiempo debe conservar cada transición y vincularla con la clase de evidencia correspondiente.
Procedencia sin copiar el universo
La recomendación W3C PROV-O ofrece una gramática práctica: Entity para una factura o versión de política, Activity para una comparación o aprobación y Agent para la persona o software responsable. Relaciones como used, wasGeneratedBy y wasAssociatedWith permiten reconstruir la cadena sin insertar todos los contenidos en el evento.
Por ejemplo, una propuesta de pago es una entidad generada por una actividad de comparación que usó versiones concretas de factura, orden y recepción. La aprobación es otra actividad asociada con una persona habilitada. El pago ejecutado es una entidad posterior derivada de la propuesta aprobada. Esa cadena responde quién hizo qué con qué evidencia.
Ejemplo ilustrativo: cambio de cuenta de proveedor
Este escenario es ilustrativo. Un correo solicita cambiar la cuenta bancaria de un proveedor. El agente extrae el identificador, relaciona el mensaje con el objeto proveedor y propone una actualización. La política exige verificación por un canal registrado y aprobación de una persona distinta al solicitante.
El sobre guarda referencias al correo y al perfil anterior, sus hashes y versiones; registra la política vigente; marca la propuesta como preparada pero no autorizada; y conserva la identidad del verificador y del aprobador. Solo después enlaza el identificador de la actualización en el ERP. Si el banco rechaza una transferencia posterior, outcome_ref conecta ese resultado con la decisión.
Guardar únicamente el prompt “actualiza esta cuenta” no demostraría que se verificó el canal, que hubo separación de funciones ni que el ERP aceptó el cambio. Guardar el correo completo en cada log, en cambio, multiplicaría exposición sin mejorar ese control.
Versione reglas y componentes por separado
policy_version describe la norma empresarial: tolerancia, autoridad, condición de escalamiento. model_or_rule_version identifica el componente que extrajo, clasificó o propuso. Separarlos evita atribuir al modelo una decisión que en realidad tomó una regla, o asumir que cambiar el prompt modificó la política aprobada.
Mantenga un registro desplegable de políticas y componentes con fecha de vigencia, propietario, pruebas y estado. El sobre apunta a identificadores inmutables. Si una política cambia mañana, la auditoría de ayer conserva la versión que realmente gobernó la acción.
Las razones también deben ser códigos estables, acompañados de una explicación legible. “PO_AMOUNT_MISMATCH” puede agregarse y medirse; un párrafo libre no reemplaza el código, aunque ayude al revisor.
Privacidad, seguridad y retención son parte del diseño
La guía de registro de OWASP advierte que tokens de acceso, contraseñas, secretos y datos personales sensibles no deben registrarse directamente; deben excluirse, enmascararse, sanearse o cifrarse según el caso. El sobre necesita clasificación por campo, acceso por rol, cifrado, integridad y una retención con propósito.
La minimización no significa perder evidencia. Significa conservar referencias, huellas, razones y metadatos suficientes; almacenar el contenido sensible en su sistema autorizado; y auditar cada recuperación. Un hash prueba que una referencia no cambió, pero no demuestra que la fuente era correcta. Por eso se conserva también autoridad, procedencia y validación.
Cómo representarlo en Quantum
En Quantum Automation Center, el objeto de negocio puede ser el eje del expediente. Su línea de tiempo enlaza ejecuciones y transiciones; artefactos y logs aportan evidencia protegida; permisos y aprobaciones representan autoridad; y el catálogo identifica versiones de agente, herramienta y política. La ontología de Quantum permite relacionar esos elementos sin reducirlos a una transcripción.
La interfaz de revisión debe mostrar primero decisión, riesgo, razones, fuentes y aprobador. El detalle técnico queda disponible bajo demanda. Así, operación, auditoría y cumplimiento observan el mismo expediente con vistas acordes a sus permisos.
El contrapunto: el sobre también cuesta
Un sobre detallado añade almacenamiento, latencia y carga operativa; la respuesta es graduar la evidencia por riesgo y no aplicar la misma profundidad a una sugerencia reversible y a una acción financiera. Defina niveles: una recomendación informativa puede requerir fuentes y versión; una escritura reversible añade autorización y resultado; una acción sensible exige segregación, evidencia reforzada y revisión.
El costo debe compararse con la pregunta que el control necesita responder. Si un campo nunca será revisado ni sirve para investigar, medir o apelar, probablemente sobra. Si una acción puede afectar dinero, derechos o cumplimiento, “tenemos el chat” probablemente no basta.
Cuándo no crear un expediente adicional
No cree un expediente propio para recomendaciones efímeras de bajo riesgo ya cubiertas por el historial del sistema de registro, ni conserve datos cuya retención esté prohibida o no tenga finalidad definida. Enlace la evidencia existente en vez de duplicarla.
Tampoco confunda el sobre con una política legal de conservación, una firma digital o una certificación automática de cumplimiento. Cada obligación depende del contexto y la jurisdicción. El contrato técnico facilita demostrar controles; no decide por sí solo qué debe conservarse.
La prueba de reconstrucción
Seleccione una decisión material y entréguela a un revisor que no participó. Debe identificar entradas y versiones, reproducir la regla aplicable, verificar autoridad, seguir la transición, localizar el resultado y entender cualquier corrección sin pedir el prompt completo. Si solo puede leer una conversación larga o confiar en una captura, todavía hay actividad registrada, pero no trazabilidad de decisión.
Sources
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls — nist.gov
- W3C PROV-O: The PROV Ontology — w3.org
- OWASP Logging Cheat Sheet — owasp.org
Temas del artículo
