Por que "uma pessoa aprova todo e-mail" não é uma afirmação auditável

Frases como essa aparecem em documentação de sistema, em resposta a questionário de fornecedor e em relatório de incidente. Um pré-print publicado no arXiv em 5 de outubro argumenta que, escritas desse jeito, elas não podem ser checadas por ninguém — e propõe o que precisa vir antes.

A cena que abre o artigo Auditable Claims about AI Agents é deliberadamente banal. Uma empresa opera um agente que lê uma pasta de processo, resume o conteúdo e envia documentos por e-mail. A empresa declara que "uma pessoa aprova todo e-mail externo". O agente então envia uma mensagem com anexo para um endereço externo depois de uma confirmação feita na própria interface de chat. O gateway de e-mail registra a entrega. O servidor de autorização não tem nenhuma concessão que cubra aquele envio.

A pergunta que os autores — Yue Zhao, Jiate Li, Li Li e Yi Nian, da University of Southern California, e Jinbo Liu, Xiaolin Zhou e Xiyang Hu, da Arizona State University — colocam não é se houve violação. É mais básica: a frase original cobre esse envio? Qual registro resolveria a dúvida? Quem escreve esse registro?

Nenhuma das três respostas estava definida antes.

A inversão: nomear a afirmação antes de derivar o registro

O diagnóstico do pré-print é que a discussão sobre registro de agentes está na ordem errada. Pergunta-se primeiro o que um sistema deve registrar, e só depois se tenta usar o que foi registrado para responder a alguma pergunta. O resultado é um acervo de logs que não resolve afirmação nenhuma.

O Artigo 12 do Regulamento (UE) 2024/1689, o AI Act europeu, é o exemplo que os autores usam: ele exige que sistemas de IA de alto risco permitam tecnicamente o registro automático de eventos ao longo do ciclo de vida, mas não diz quais registros resolvem uma afirmação específica. Essas obrigações, com a atualização trazida pelo Regulamento (UE) 2026/1744, passam a valer em 2 de dezembro de 2027 para os usos do Anexo III e em 2 de agosto de 2028 para os produtos do Anexo I.

A tese do artigo tem uma frase só: para ser checada, uma afirmação sobre um agente precisa primeiro nomear sua política, seu escopo, os registros que a resolveriam e quem os escreve. Disso sai a definição formal — uma afirmação é auditável quando quatro coisas estão fixadas antes de qualquer veredito:

• Política e versão: o texto da regra testada, com o número de versão em vigor no período.

• Ações e período: quais ações entram no escopo, entre quais datas.

• Registros e quem os escreve: quais registros resolveriam a questão, e se podem ser obtidos de autores identificados.

• Regra de decisão: o critério que transforma os registros em veredito.

Por essa definição, "nosso agente é seguro" falha antes de qualquer registro ser lido. A estrutura é emprestada da auditoria tradicional: antes de aceitar um trabalho de asseguração, o profissional sob a norma ISAE 3000 pergunta se os critérios são adequados e se a evidência necessária pode ser obtida. Os autores são explícitos quanto a emprestarem só a estrutura — seus vereditos não são opiniões de asseguração, e materialidade, amostragem e independência do auditor ficam de fora.

Os vereditos possíveis são três, e o terceiro é o que mais aparece na prática: sustentada, contradita ou indecidível. Indecidível é o que acontece quando um registro exigido não existe ou foi perdido. O artigo insiste que esse caso seja reportado junto com o nome do registro que teria resolvido a questão, em vez de virar silêncio — e que um log perdido seja tratado como um achado próprio de guarda de registros, separado do veredito.

Três condições que o agente acrescenta

É aqui que a prática de auditoria conhecida deixa de bastar. Agentes mudam de onde vem a evidência: a ação pode não deixar registro algum fora do log do próprio agente, o agente auditado costuma registrar suas próprias aprovações, e logs assinados são oferecidos como trilha de auditoria. Os autores derivam três condições e provam, sob um modelo explícito, que o veredito de "sustentada" é impossível sem cada uma delas.

1. Cobertura por um registro independente. O log de um agente, por padrão, não tem contrapartida: quem o escreve é o próprio agente, e nada mais registra cada ação. Se uma ação violadora pudesse ser acrescentada sem alterar nenhum dos registros independentes que a regra lê, a regra nunca pode responder "sustentada".

2. Autorização vinculada aos argumentos da ação. Uma confirmação clicada na interface do agente registra um evento de interface atribuído a uma conta — não é uma concessão. O rascunho do IETF draft-ietf-wimse-aims-00 afirma que confirmações "não constituem, por si, autorização". A condição vai além: a aprovação tem de cobrir os argumentos que definem o efeito da ação — destinatário, hash do anexo — e não apenas o nome da ferramenta chamada.

3. Completude separada de integridade. Log assinado e encadeado por hash é frequentemente apresentado como trilha de auditoria. A assinatura autentica as entradas entregues; ela não mostra o evento que nunca foi escrito. Os autores citam o pré-print Hearsay, em que uma cadeia de hash sobre o log que o próprio ambiente de execução do agente mantém sobre si mesmo não sinalizou nenhuma das 28 omissões e fabricações injetadas no teste; um log mantido fora desse ambiente sinalizou todas as 28.

Daí vem a assimetria mais útil para quem negocia contrato. Contradizer uma afirmação pode exigir uma única exceção autenticada, desde que o registro de concessões esteja completo para o período. Sustentá-la exige registros independentes que mostrariam qualquer ação violadora, para todas as ações no escopo. Derrubar uma afirmação é muito mais barato do que comprová-la.

O caso trabalhado no artigo percorre cinco estados de evidência. No melhor deles, três registros escritos por três partes diferentes concordam e o e-mail cumpre a política. Em outro, há confirmação de interface e entrega registrada pelo gateway, mas o servidor — completo para o período — não tem concessão alguma: uma exceção autenticada contradiz a afirmação do mês inteiro. Em um terceiro, o log do servidor foi perdido numa migração de armazenamento, e o veredito fica indecidível, porque a ausência está no registro e pode não estar no mundo. Os autores informam que esses registros foram construídos para fins didáticos e que nenhum agente foi executado.

Seis afirmações comuns, lidas como afirmações

O pré-print aplica o método a seis frases que operadores costumam escrever, ancorando cada uma em orientação vigente — o OWASP Top 10 for Agentic Applications 2026, os rascunhos públicos iniciais NIST AI 300-1 e NIST AI 200-2, e o rascunho do IETF. As âncoras, registram os autores, são um retrato de setembro de 2026, e a regra não depende delas.

• "O agente em produção é o que documentamos": exige que identificadores de modelo, esquemas de ferramenta co-versionados e cada controle versionado do sistema coincidam, no registro de execução, com os que estão em vigor.

• "Toda ação externa é registrada": exige reconciliação nos dois sentidos com um registro independente pelo qual toda ação relevante tenha de passar. Fica fora do alcance garantir que nenhuma ação contornou todos os caminhos registrados.

• "Uma pessoa aprova toda transmissão externa": exige concessão aprovada por pessoa, emitida pelo servidor de autorização, cujo escopo cubra a ação e seus argumentos e que estivesse válida na execução. Fica fora do alcance o que o aprovador entendeu, e a responsabilidade legal.

• "O agente segue a política P": exige texto e versão da política em vigor, avaliados sobre os registros das duas afirmações anteriores. Regras semânticas, do tipo "não divulga informação identificável", ficam fora do que um esquema de registro decide.

• "Nossos logs são completos e invioláveis": exige assinatura e cadeia verificadas contra um ponto de verificação mantido por outra parte, com completude testada contra um registro que o agente não escreve.

• "Nossa avaliação mostra que o agente detecta excesso de privilégio": exige objeto avaliado e versão nomeados, cada fonte de dados comparada com uma linha de base trivial e reexecução fixada. Fica fora do alcance transferir o resultado para outra implantação.

Duas lacunas se repetem na tabela. Nenhum campo revela um evento que nunca foi escrito. E os sete campos mínimos de auditoria do rascunho do IETF pedem a ação requisitada sem os argumentos que definem seu efeito — o destinatário, por exemplo, que a orientação do OWASP pede para registrar.

O que muda para quem vende e para quem compra

A seção de recomendações é a parte diretamente aplicável. Para operadores, o artigo sugere escrever cada afirmação pública na forma da definição antes de publicá-la, rotear ações consequentes por um componente que o agente não controla — um gateway, por exemplo — e fazer esse componente escrever o registro de contrapartida. E pedir que uma pessoa aprove um lote de ações com escopo definido no servidor de autorização, em vez de confirmar cada ação na interface do agente.

Para áreas de compras, a lista é mais curta e mais utilizável: pedir que o fornecedor declare suas afirmações nessa forma e nomeie o autor de cada registro; perguntar se o comprador, ou um auditor que ele indique, consegue obter esses registros; ler "logs invioláveis" como a quinta afirmação da lista e perguntar qual é o registro que o agente não escreve.

No Brasil, a pressão de curto prazo para um fornecedor de serviço não é regulatória — é contratual. O marco legal da IA, o PL 2338/2023, foi aprovado pelo plenário do Senado e remetido à Câmara dos Deputados em março de 2025, onde segue em tramitação. A leitura mais plausível é que o rigor chegue antes pela cadeia de fornecimento, via questionário de fornecedor e cláusula de contrato, do que por fiscalização.

Há um risco de mão contrária, e ele aparece em outro pré-print publicado um dia depois. The Amplifier Effect, de Nikolaos Kekatos, Michael Ioannou, Marina Korgiala-Karyda, Alexios Lekidis e Tom Nianios, aceito na conferência IEEE CSR 2026, descreve o que acontece quando plataformas de governança, risco e conformidade correlacionam perguntas de autoavaliação por IA e propagam respostas automaticamente entre frameworks. Um controle avaliado com otimismo, uma atestação assinada sem leitura ou uma resposta redigida por IA pode ser replicada silenciosamente como evidência de conformidade com várias obrigações. Os autores chamam isso de efeito amplificador e tratam como propriedade de projeto da plataforma, não falha do usuário; a comparação de treze ferramentas que apresentam é, segundo o próprio artigo, uma avaliação estruturada de projeto, não medição empírica de comportamento.

Os dois trabalhos se encaixam de forma incômoda: um propõe nomear o registro que resolve a afirmação, o outro mostra como a resposta a um questionário pode se multiplicar sem que ninguém tenha olhado registro algum.

Limites

O pré-print é uma contribuição conceitual, não empírica, e os próprios autores delimitam isso com rigor incomum. Não houve revisão por pares. As provas são de condições necessárias, não suficientes — sustentar uma afirmação exige mais, como um gateway que nenhuma ação consiga contornar. Na seção de limitações, os autores escrevem que não testaram o método, e descrevem o teste que faria sentido: semear violações conhecidas com registros de referência completos, apagar campos e registros, reassinar um log aparado e medir vereditos corretos, indecidíveis corretos, falsas contradições e tempo por verificação.

As âncoras normativas também se movem. Os documentos do NIST são rascunhos públicos iniciais, o do IETF é um Internet-Draft em progresso que não cria obrigação legal, e os autores informam que não conseguiram ler a ISO/IEC FDIS 24970 nem a prEN 18229-1, ambas em estágio final. Ficam fora do escopo privacidade e minimização de dados, responsabilidade em cadeias de agentes que delegam a outros agentes, e políticas semânticas. Os autores declaram que discutem o próprio benchmark e os próprios artigos, além de comentários que o primeiro autor submeteu ao NIST em setembro de 2026.

Há também um contraponto de custo, que o artigo trata de frente. Rotear toda ação consequente por um componente independente e vincular cada aprovação aos argumentos da ação é trabalho de engenharia e de operação, não ajuste de configuração. À objeção de que uma pessoa deveria aprovar cada ação individualmente, os autores respondem que aprovação ação por ação pode convidar justamente o viés de automação de que o Artigo 14 do AI Act exige que o supervisor se mantenha consciente, e que uma concessão para um lote com escopo definido continua checável.

O que sobra de aproveitável independe de o método ser testado algum dia. É um teste barato, disponível hoje: reler a frase que a empresa já escreveu sobre supervisão humana do seu agente e verificar se ela nomeia a política, o período, o registro e quem o escreve. Quando falta um desses quatro, a frase não está errada. Ela só não é verificável — e, em uma negociação, isso tende a ser pior.