Trilha de auditoria de agente de IA: campos que cada ação precisa ter

Uma trilha de auditoria de agente de IA é um registro estruturado e somente de acréscimo de cada ação que o agente executa, escrito de modo que um revisor consiga ver o que disparou a ação, quais informações e ferramentas foram usadas, o que foi alterado, quem aprovou e o que aconteceu depois. Os campos mínimos de cada ação são um identificador de execução, um identificador de etapa, o gatilho, a identidade que agiu, as entradas e suas fontes, cada chamada de ferramenta com seus parâmetros e resultado, as versões do modelo e da configuração, a saída, o estado da aprovação e o desfecho. Sem esses campos, um revisor posterior até percebe que algo aconteceu, mas não consegue explicar por que nem reconstruir a etapa.

Principais pontos

• Dê a cada execução e a cada etapa um identificador próprio, com referência à etapa pai quando uma etapa iniciar uma subtarefa, para que a sequência possa ser reconstruída.
• Registre o gatilho, a identidade que agiu, as entradas por referência, cada chamada de ferramenta e o desfecho de cada ação, sem exceção.
• Anote as versões do modelo, das instruções, das definições de ferramentas e das políticas que estavam em vigor no momento da ação.
• Guarde o estado da aprovação e o motivo pelo qual um limite de permissão foi respeitado, ultrapassado ou escalonado.
• Mantenha a trilha somente de acréscimo, com controle de acesso e revisões periódicas, e não apenas consultas depois de um incidente.

Por que um log de aplicação genérico não basta

Logs de aplicação costumam registrar que uma requisição chegou, que uma função rodou e que um erro ocorreu. Para um agente, a pergunta importante é qual decisão levou a qual ação. Uma única execução pode chamar um modelo várias vezes, buscar documentos, acionar duas ferramentas, aguardar uma pessoa e depois tentar de novo com outras entradas. Se o registro guardar apenas carimbos de data e a mensagem final, a cadeia de raciocínio de que o revisor precisa desaparece.

A documentação de observabilidade do OpenTelemetry explica por que isso importa. O trabalho é entendido por meio de etapas ligadas entre si, que compartilham identificadores, e não por linhas isoladas. As ações de um agente precisam da mesma estrutura. Antes de escrever qualquer esquema, defina que cada ação é um registro ligado à sua execução, à etapa pai e ao contexto do qual dependeu. Para uma visão mais ampla do que capturar na operação, o texto sobre o que registrar na observabilidade de agentes de IA cobre os sinais que sustentam essa trilha.

Quais campos cada ação precisa ter

Cada ação deve gerar um registro que contenha, no mínimo, os campos abaixo. Marque cada campo como obrigatório ou opcional antes de o primeiro agente entrar em produção, porque um campo que às vezes falta costuma faltar justamente quando mais se precisa dele.

• Identificadores de execução e de etapa: liguem a ação a uma execução da tarefa e à sua posição na sequência, com referência à etapa pai nas subtarefas.
• Gatilho: a mensagem do cliente, o agendamento, o evento ou a etapa anterior que iniciou a ação, com referência à origem.
• Identidade que agiu: o papel do agente, a conta de serviço usada e a pessoa que delegou a autoridade, se houver.
• Entradas de contexto: os documentos, registros ou entradas de memória que o agente usou, guardados como identificadores ou resumos criptográficos quando o conteúdo for sensível.
• Chamada de ferramenta: o nome da ferramenta, a versão da sua definição, os parâmetros enviados e o status e o resumo do resultado tal como foi recebido.
• Versões em vigor: o identificador do modelo, a versão das instruções ou do prompt, a versão da política e a versão do índice de busca, se houver.
• Saída: o texto, o arquivo ou a alteração produzida, ou a referência ao local onde ela está guardada.
• Estado da aprovação: se a ação estava dentro do limite permitido, se exigia aprovação, quem a deu e quando.
• Desfecho e correção: sucesso, falha, rejeição ou reversão, além da etapa de acompanhamento, se alguma foi tomada.

Torne cada etapa reproduzível e explicável

Reproduzir não significa que o modelo vá repetir exatamente as mesmas palavras. Significa que um revisor pode pegar as mesmas entradas, executá-las com as mesmas versões e verificar se o resultado coincide ou descobrir exatamente o que mudou. Isso exige fixar versões, manter os identificadores de contexto usados na época e guardar as respostas das ferramentas como foram recebidas. Se uma etapa depender de dados ao vivo, registre a consulta e o horário da leitura, porque a mesma pergunta feita depois pode devolver registros diferentes. Guarde o suficiente para comparar e depois decida se a diferença importa para o negócio.

A explicação é um campo à parte. Registre uma declaração curta e estruturada sobre por que o agente escolheu a ação: a instrução ou regra que aplicou, as evidências em que se apoiou e qualquer incerteza que tenha declarado. Mantenha o texto breve e factual. Justificativas longas em texto livre são difíceis de auditar e podem ser escritas depois do fato. Se o sistema produzir algum sinal de confiança, guarde-o com a ressalva de que um valor de confiança só é útil depois de conferido contra os desfechos, como discutido no texto sobre o que o nível de confiança da IA realmente mostra. O NIST AI Risk Management Framework trata documentação e monitoramento como parte da gestão de riscos de IA, e esse é o motivo para escrever a trilha de modo que a governança consiga usá-la, e não apenas a equipe técnica.

Proteja a trilha e limite quem pode lê-la

A própria trilha é sensível. Ela pode conter dados de clientes, preços internos, condições de fornecedores e, se o desenho for descuidado, credenciais que uma ferramenta devolveu. Grave os registros como entradas somente de acréscimo, de modo que uma correção seja um novo registro que aponta para o antigo, e não uma edição. Defina um prazo de retenção com os responsáveis pela conformidade, remova dados pessoais quando a revisão não precisar deles e mantenha a trilha em um armazenamento que o próprio agente não consiga reescrever.

O acesso de leitura deve seguir as mesmas regras de qualquer outro sistema da empresa. O Authorization Cheat Sheet da OWASP oferece orientações práticas sobre como decidir quem pode ver quais registros e em que condições. Mantenha ao lado da trilha um runbook curto que diga quem a revisa, com que frequência e o que acontece quando um registro mostra que um limite foi ultrapassado. As orientações do runbook de operação para agentes de IA ajudam a tornar essa rotina repetível.

Monte a trilha em seis passos

Este plano funciona para um único papel de agente e pode ser ampliado depois de testado com trabalho real.

• Passo 1: Dê nome ao papel, liste cada ação que ele pode executar e cada ferramenta que pode acionar, e escreva o limite de cada ação.
• Passo 2: Atribua um identificador de execução quando a tarefa começar e passe-o para cada chamada de ferramenta, busca e subtarefa.
• Passo 3: Escreva o esquema do registro a partir da lista de campos acima, marcando cada campo como obrigatório, opcional ou guardado por referência.
• Passo 4: Fixe as versões do modelo, das instruções, das definições de ferramentas e das políticas, e grave-as em cada registro.
• Passo 5: Escolha uma execução concluída e reconstrua-a usando apenas a trilha. Se a reconstrução falhar, o campo que faltou é a correção, e o esquema ainda não está pronto.
• Passo 6: Defina um calendário de revisão para acesso, retenção, remoção de dados pessoais e uma amostra de registros, e nomeie um responsável por cada revisão.

Cenário ilustrativo: um agente que reagenda entregas para um pequeno atacadista move uma entrega depois de uma mensagem do cliente. Dois dias depois, o cliente contesta a nova janela. O log genérico mostra apenas que um agendamento foi atualizado. A trilha completa mostra a mensagem de gatilho e sua referência, o papel de agendamento como identidade que agiu, a chamada à ferramenta de calendário com seus parâmetros e a versão do calendário registrada na época. Mostra também que o estado da aprovação estava dentro do limite, porque a própria ferramenta ofereceu a janela. A revisão descobre que o calendário havia sido alterado na tarde anterior. A correção é uma checagem de sincronização entre o calendário e o contexto do agente, e não uma busca por quem errou.

Como a Be Human trata a trilha de auditoria

No modelo gerenciado da Be Human, a trilha de auditoria é desenhada já no primeiro projeto, junto com a memória do papel, as ferramentas, os limites de aprovação e o critério de sucesso, para que os campos do registro correspondam às decisões que a empresa realmente precisa explicar. A operação gerenciada mantém a trilha funcionando ao longo do tempo: o monitoramento verifica se os registros estão completos, as revisões de permissão confirmam quem pode lê-los e avaliações recorrentes comparam ações reais com o esquema. Quando ocorre um incidente, os mesmos registros alimentam a resposta, seguindo um guia prático de resposta a incidentes com agentes de IA. Se a sua equipe está avaliando qual processo deve ser a primeira tarefa de um agente, o diagnóstico gratuito de IA da Be Human pode ajudar a identificar a primeira tarefa que vale a pena entregar a um agente.

Perguntas frequentes

O que é uma trilha de auditoria de agente de IA? É um registro estruturado e somente de acréscimo de cada ação que um agente executa, ligado à execução, ao gatilho, às entradas, às ferramentas, às versões, ao estado da aprovação e ao desfecho. Seu objetivo é permitir que um revisor veja, explique e, quando possível, reproduza qualquer etapa. Um histórico de conversa simples ou um log de aplicação geralmente não oferece detalhes ligados o suficiente para isso.

Por quanto tempo a trilha deve ser guardada? O prazo depende do negócio, das regras que se aplicam aos dados da empresa e do risco das ações do agente. Defina o período com a participação da área de conformidade ou do jurídico, e determine quando os registros são apagados, agregados ou anonimizados. Mantenha o esquema consistente durante todo o período de retenção, para que registros antigos continuem legíveis quando alguém precisar deles.

Registrar todos os prompts e respostas cria um problema de privacidade? Pode criar. Guarde o conteúdo completo somente quando a revisão realmente precisar dele, remova dados pessoais, restrinja o acesso de leitura por papel e use referências ou resumos criptográficos para todo o resto. Confirme suas obrigações com profissionais qualificados, incluindo as regras de proteção de dados de cada mercado em que a empresa atua.

O raciocínio do modelo pode ser registrado como explicação? Não como relato completo e confiável do seu processo interno. Registre, de forma curta e estruturada, a instrução ou regra aplicada, as evidências citadas, os resultados das ferramentas e qualquer incerteza declarada. Trate isso como uma explicação do caminho de decisão que pode ser conferida contra o registro, e não como uma transcrição de como o modelo raciocinou.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.