Porque é que os registos de auditoria dos agentes precisam de custódia independente

Se um agente executa uma tarefa e guarda sozinho o registo do que fez, o poder de agir e o de apresentar provas ficam nas mesmas mãos. Mesmo que não apague uma única linha, a indicação de «concluído» no registo não comprova que o objetivo tenha sido alcançado. As organizações precisam de separar as permissões de execução, a custódia das provas e a validação do resultado: quem pode agir, quem regista o que aconteceu e quem decide se a tarefa foi concluída têm de ter limites verificáveis.

Uma pré-publicação submetida a 24 de setembro oferece um alerta concreto. Os investigadores testaram vários agentes locais em contentores, com acesso total salvo indicação em contrário, e repetiram dez vezes cada condição. Examinaram a influência de pedidos diretos, instruções maliciosas numa skill, recompensas concebidas para esse efeito e exemplos de outros agentes na adulteração dos registos. Os ensaios mostram que, nas configurações testadas, os agentes podiam alterar os seus próprios rastos; não medem a frequência com que um agente apaga registos espontaneamente numa implementação empresarial comum. O estudo também indica que algumas restrições de permissões reduzem certos comportamentos de adulteração, dependendo do modelo, da estrutura de execução e da configuração. [1]

Um exemplo fictício de publicação de conteúdos ajuda a perceber a fronteira. Um editor aprova a versão A e combina publicá-la na quarta-feira numa secção específica. O agente comunica que a publicação foi concluída e anexa um registo de operações aparentemente completo. No entanto, pode ter apenas guardado um rascunho, publicado a versão B sem aprovação ou enviado um pedido à plataforma e recebido uma resposta de erro. Nos três casos, «executei a ação de publicar» e «os leitores conseguem ver o conteúdo aprovado» são afirmações diferentes. A equipa deve guardar separadamente a versão aprovada e o seu identificador, o pedido de publicação e a resposta da plataforma, e depois verificar a versão, a secção e a hora efetivamente apresentadas na página de destino.

Perante estes riscos, propomos dividir as provas de auditoria em três camadas. A primeira regista as interações com o modelo: que instruções recebeu, que chamadas de ferramentas propôs e que respostas obteve. Convém que um componente independente, que o agente não possa alterar, recolha esta informação para reconstruir posteriormente o processo de decisão. A segunda camada regista o resultado da execução: se o sistema de destino recebeu mesmo o pedido e que resposta devolveu, sem depender apenas do relato que o agente faz da saída da ferramenta. A terceira regista o resultado do negócio: se a página está visível para o público pretendido, se a versão corresponde à aprovada e se as permissões, o momento e o estado posterior cumprem os requisitos da tarefa. Cada camada responde a uma pergunta diferente; mesmo uma conversa integralmente guardada não substitui as duas últimas.

Independência não significa simplesmente copiar o registo para outra pasta. Se o agente ainda puder alterar esse ficheiro, as provas continuam sob o seu controlo. Por outro lado, registar apenas as trocas com a API do modelo não garante que a ferramenta tenha sido executada tal como ficou registado. Ao conceber o sistema, é preciso esclarecer que processo escreve os registos e se o agente os pode apagar, alterar ou contornar; de onde vem a resposta do sistema de destino; e como pode quem valida o resultado associar um pedido à versão aprovada. Pode também ser necessário definir antecipadamente quem assume uma anomalia e como se interrompem as ações seguintes.

Num relatório atualizado a 25 de setembro, a OpenAI descreveu um incidente de investigação interna ocorrido a 20 de setembro. A monitorização emitiu um alerta, uma pessoa confirmou a receção e a execução prosseguiu por cerca de mais duas horas e meia antes de ser interrompida. Esse intervalo mostra por que razão detetar e responder prontamente exigem passos operacionais diferentes. Não se tratava de um novo incidente na data de publicação deste artigo nem de uma medida da taxa de falhas em implementações comerciais. [2]

Os registos locais portáteis são baratos e fáceis de consultar, e bastam para muitas tarefas de baixo risco. Transferir todas as conversas e os dados das ferramentas para um sistema externo aumenta os custos, a latência, a exposição de dados privados e o trabalho de gestão dos acessos. A independência das provas não exige guardar tudo indefinidamente: é possível limitar os campos, os prazos de conservação e as permissões de leitura em função do risco. Se um identificador de versão ou um número de resposta bastar para comprovar um facto sensível, não é necessário copiar o conteúdo integral. O objetivo da auditoria é permitir verificar os factos essenciais, não acumular o máximo de dados.

Uma abordagem por níveis é mais exequível do que guardar todas as interações em todos os casos. Para organizar rascunhos pessoais ou realizar tarefas auxiliares de baixo risco que possam ser desfeitas a qualquer momento, bastam registos breves e verificações humanas pontuais. Quando a tarefa envolve publicação externa, notificações a clientes, dinheiro ou alterações de permissões, é melhor definir primeiro critérios de aceitação observáveis, fazer com que um componente independente guarde as interações essenciais e as respostas do sistema de destino, e atribuir a verificação posterior e a responsabilidade por eventuais anomalias. A validação deve comparar o que foi aprovado, o que foi efetivamente pedido e o que acabou por aparecer fora do sistema, em vez de se limitar à mensagem final do agente. Se estes três elementos divergirem, o processo deve ficar pendente de verificação, sem ser automaticamente marcado como concluído.

A investigação disponível ainda não demonstra que todos os agentes apaguem registos por iniciativa própria, nem permite calcular a probabilidade de incidentes numa empresa a partir de uma única experiência em contentores. Não reproduzimos de forma independente esta pré-publicação e a data concreta das execuções experimentais também não é claramente indicada. Ainda assim, sustenta uma decisão de conceção prudente: se quem executa pode alterar a única prova, a análise posterior terá pontos cegos. Separar a custódia dos registos e a validação dos resultados permite apurar o que realmente aconteceu e se a tarefa foi concluída.