O que entra numa trilha de auditoria

Duas semanas depois

Um agente concedeu um desconto que a política não previa. Ou aprovou uma exceção, ou deu uma informação que a empresa não teria dado. Ninguém percebeu na hora, porque naquele momento foi só mais uma das milhares de execuções do dia.

Duas semanas depois isso vira uma reclamação, e alguém precisa dizer se aconteceu.

É aqui que a maior parte das operações descobre o que tem e o que não tem. A resposta começa numa ferramenta de log: procura-se pelo horário, cruza-se com o identificador da sessão, tenta-se remontar a sequência a partir de linhas escritas para diagnosticar infraestrutura e não para explicar uma decisão.

Quando a resposta chega, ela é uma reconstrução. E reconstrução não é prova.

A diferença entre log e trilha

Um log de aplicação registra eventos que o desenvolvedor achou que valeria registrar, no formato que fez sentido naquele arquivo, com o detalhe que parecia suficiente. Ele é ótimo para descobrir por que um serviço caiu às três da manhã.

Uma trilha de auditoria registra o que foi necessário para explicar uma decisão, de forma completa e no momento em que ela aconteceu. A diferença não é de volume, é de intenção: o log responde "o sistema está saudável", a trilha responde "por que isso foi decidido assim".

A consequência aparece na pergunta que o log não consegue responder: qual versão do prompt estava no ar naquela execução. O log registra que houve uma chamada ao modelo. Ele não registra qual configuração produziu aquele texto, porque quem escreveu a linha de log não estava pensando em prestar contas.

Os oito campos

Para cada execução, a trilha guarda oito coisas. Não é uma lista de recursos: é o conjunto mínimo para responder a uma pergunta sobre um caso.

O agente e o responsável: qual agente executou, em qual ambiente, e quem respondia por ele naquele momento. O responsável é gravado na execução e não lido do cadastro atual, porque a pessoa pode ter mudado de time desde então.

A versão exata: a revisão que rodou, não a que está no ar hoje. Se o agente foi alterado depois, o registro continua apontando para a que produziu aquele resultado. Este é o campo que mais falta nas implementações caseiras, e o mais caro de não ter.

O prompt como foi enviado, com as variáveis já resolvidas, e não o template que o gerou. Um template com três condicionais produz textos diferentes, e é o texto que precisa estar guardado.

O modelo e os parâmetros: qual modelo respondeu, com qual temperatura, qual limite de contexto e por qual provedor, para cada chamada. Modelos são descontinuados e substituídos; a trilha precisa dizer qual estava lá.

As políticas avaliadas: todas as regras consideradas, o resultado de cada uma, e qual bloqueou quando houve bloqueio. É o campo que transforma a trilha de descritiva em explicativa. Sem ele dá para saber o que aconteceu, mas não por que foi permitido.

As ferramentas chamadas: quais saíram, com quais argumentos, e o que voltou. Inclusive as que falharam, porque falha silenciosa é frequentemente a causa do comportamento estranho.

O consumo: tokens e custo por etapa, atribuídos ao agente, ao time e ao ambiente. Está na trilha e não só no relatório de custo porque a pergunta "por que essa execução custou dez vezes mais" é sobre um caso, e caso é onde a trilha vive.

O desfecho: o que aconteceu no fim, e se corresponde ao que foi pedido.

Reproduzir, não reconstituir

Com os oito campos existe uma coisa que reconstrução por log nunca permite: rodar de novo.

O replay parte do checkpoint em que a decisão foi tomada, com a mesma configuração, o mesmo prompt e as mesmas políticas. Não é simulação aproximada do que provavelmente aconteceu. É a execução, outra vez.

Isso muda a natureza da conversa com quem está perguntando. Em vez de "acreditamos que o agente considerou X", a resposta passa a ser "veja: com esta regra e este prompt, o resultado é este".

E muda o que se pode fazer depois. Alterada a política, o replay mostra se o desfecho teria sido outro. A trilha deixa de ser só defesa e vira instrumento de ajuste.

O que a trilha não resolve

Três limites, ditos aqui porque seriam descobertos de qualquer forma.

Ela não explica o modelo. A trilha diz qual modelo respondeu, com quais parâmetros, e o que devolveu. Ela não diz por que aquele modelo produziu aquela saída, porque isso está dentro do modelo e não da plataforma. Quem prometer explicabilidade de decisão de LLM a partir de trilha de execução está prometendo outra coisa.

Ela não substitui política. Uma trilha completa de uma operação mal governada produz um registro excelente de decisões ruins. O registro é o que permite descobrir; ele não é o que impede. É por isso que a avaliação de política acontece antes da chamada, e a trilha depois.

Ela tem custo de armazenamento. Guardar prompt resolvido e retorno de ferramenta para cada execução de uma frota grande não é gratuito, e a política de retenção é uma decisão da organização, com prazo diferente por criticidade de agente.

Por que isso vira infraestrutura

A pergunta razoável é por que isso não fica dentro de cada agente, resolvido por quem o construiu.

A resposta é a mesma de toda decisão de plataforma: porque então existiriam tantos formatos de trilha quantos times, e "o que aconteceu naquela execução" teria uma resposta diferente por departamento. Quando o auditor pergunta, ele não pergunta sobre um time. Ele pergunta sobre a organização.

Trilha de auditoria é o tipo de coisa que só funciona quando é igual em todo lugar. E o que precisa ser igual em todo lugar pertence à camada de baixo.

Governança aplica a regra antes da chamada sair. Audit e Replay guardam o que aconteceu depois. Conheça a Governança.