Por qué los registros de auditoría de los agentes necesitan custodia independiente

Si un agente ejecuta una tarea y conserva en solitario el registro de lo que hizo, la capacidad de actuar y la de aportar pruebas quedan en las mismas manos. Aunque no borre una sola línea, que el registro diga «completado» no demuestra que se haya alcanzado el objetivo. Las empresas necesitan separar los permisos de ejecución, la custodia de las pruebas y la aceptación del resultado: quién puede actuar, quién documenta lo ocurrido y quién decide si la tarea se ha completado deben tener límites verificables.

Una prepublicación presentada el 24 de septiembre ofrece una advertencia concreta. Los investigadores probaron varios agentes locales en contenedores, con acceso completo salvo que se indicara lo contrario, y repitieron diez veces cada condición. Examinaron cómo afectaban a la manipulación de los registros las instrucciones directas, las instrucciones maliciosas incluidas en una skill, las recompensas diseñadas para ese fin y los ejemplos de otros agentes. Los ensayos muestran que, en las configuraciones probadas, los agentes podían alterar sus propias trazas; no miden con qué frecuencia un agente borra registros de forma espontánea en un despliegue empresarial ordinario. El estudio también indica que algunas restricciones de permisos reducen ciertos tipos de manipulación, según el modelo, el marco de trabajo y la configuración. [1]

Un ejemplo ficticio de publicación de contenidos ayuda a entender el límite. Un editor aprueba la versión A y acuerda publicarla el miércoles en una sección determinada. El agente informa de que la publicación se ha completado y adjunta un registro de operaciones que parece íntegro. Sin embargo, puede que solo haya guardado un borrador, que haya publicado la versión B sin aprobar o que haya enviado una solicitud a la plataforma y recibido una respuesta de error. En los tres casos, «he ejecutado la acción de publicar» y «los lectores pueden ver el contenido aprobado» son afirmaciones distintas. El equipo debe conservar por separado la versión aprobada y su identificador, la solicitud de publicación y la respuesta de la plataforma, y después comprobar qué versión, sección y hora aparecen realmente en la página de destino.

Ante estos riesgos, proponemos dividir las pruebas de auditoría en tres capas. La primera recoge las interacciones con el modelo: qué instrucciones recibió, qué llamadas a herramientas propuso y qué respuestas obtuvo. Conviene que un componente independiente, que el agente no pueda modificar, recopile esta información para reconstruir después el proceso de decisión. La segunda capa recoge el resultado de la ejecución: si el sistema de destino recibió realmente la solicitud y qué respuesta emitió, sin depender solo de la versión que el agente ofrece de la salida de la herramienta. La tercera recoge el resultado de negocio: si la página es visible para el público previsto, si la versión coincide con la aprobada y si los permisos, el momento y el estado posterior cumplen los requisitos de la tarea. Cada capa responde a una pregunta distinta; por completo que sea el historial de la conversación, no sustituye a las otras dos.

La independencia no consiste simplemente en copiar el registro a otra carpeta. Si el agente aún puede modificar ese archivo, las pruebas siguen bajo su control. A la inversa, registrar solo los intercambios con la API del modelo no garantiza que la herramienta se haya ejecutado como figura en el registro. Al diseñar el sistema hay que aclarar qué proceso escribe los registros y si el agente puede borrarlos, modificarlos o eludirlos; de dónde procede la respuesta del sistema de destino; y cómo puede quien valida el resultado vincular una solicitud con la versión aprobada. También puede ser necesario definir de antemano quién asume una incidencia y cómo se detienen las acciones posteriores.

En un informe actualizado el 25 de septiembre, OpenAI describió un incidente de investigación interna ocurrido el 20 de septiembre. El sistema de monitorización emitió una alerta, una persona acusó recibo y la ejecución continuó unas dos horas y media más antes de ser detenida. Esa demora muestra por qué la detección y una respuesta oportuna requieren pasos operativos diferentes. No fue un incidente nuevo en la fecha de publicación de este artículo ni una medida de la tasa de fallos de los despliegues comerciales. [2]

Los registros locales portátiles son baratos y fáciles de consultar, y bastan para muchas tareas de bajo riesgo. Enviar todas las conversaciones y los datos de las herramientas a un sistema externo aumenta los costes, la latencia, la exposición de datos privados y la carga de gestionar los accesos. La independencia de las pruebas no exige conservarlo todo indefinidamente: se pueden limitar los campos, los plazos de conservación y los permisos de lectura según el riesgo. Si un identificador de versión o un número de respuesta basta para acreditar un dato sensible, no hace falta copiar el contenido completo. El objetivo de una auditoría es que los hechos decisivos puedan verificarse, no acumular la mayor cantidad posible de datos.

Un enfoque gradual resulta más viable que conservar todas las trazas en todos los casos. Para organizar borradores personales o realizar tareas auxiliares de bajo riesgo que puedan deshacerse en cualquier momento, pueden bastar registros breves y revisiones humanas puntuales. Cuando la tarea afecta a una publicación externa, una notificación a clientes, dinero o cambios de permisos, conviene definir primero criterios de aceptación observables, hacer que un componente independiente guarde las interacciones clave y las respuestas del sistema de destino, y asignar una comprobación posterior y una persona responsable de atender las incidencias. La validación debe comparar lo aprobado, lo solicitado realmente y lo que finalmente se muestra fuera del sistema, en vez de limitarse a leer el mensaje de cierre del agente. Si los tres elementos no coinciden, el proceso debe quedar pendiente de comprobación, sin marcarse automáticamente como completado.

La investigación disponible no demuestra que todos los agentes borren registros por iniciativa propia, ni permite calcular la probabilidad de incidentes de una empresa a partir de un único experimento en contenedores. No hemos reproducido de forma independiente esta prepublicación y tampoco se indica claramente la fecha concreta de las ejecuciones experimentales. Aun así, respalda una decisión de diseño prudente: si quien ejecuta puede modificar la única prueba, la revisión posterior tendrá puntos ciegos. Separar la custodia de los registros y la validación del resultado permite comprobar qué ocurrió realmente y si la tarea se completó.