registro de auditoria de agente de IA: o que os registros devem conter

Quando um agente autônomo — e não um humano — é o ator, os campos de auditoria usuais (nome de usuário, IP, carimbo de data/hora) deixam de ser suficientes. Ainda é preciso responsabilização, reprodutibilidade e não‑repúdio, mas o registro deve capturar um conjunto diferente de atributos: modelo, prompt, chamadas de ferramentas, sementes de aleatoriedade, versão do código e o humano que delegou autoridade. Este artigo lista os campos que um registro de auditoria de agente de IA deve conter e por que cada um é necessário para segurança, conformidade e resposta a incidentes.

Por que os campos usuais de "usuário" falham para agentes de IA

Logs de auditoria tradicionais pressupõem um único ator humano por sessão: nome de usuário, função, IP, string do user agent e uma descrição da ação. Isso é útil, mas perde atributos únicos do comportamento conduzido por IA:

• Não-determinismo: o mesmo prompt e configuração do modelo podem produzir saídas diferentes, a menos que você registre a fonte de aleatoriedade (seed, algoritmo rand, temperatura).
• Cadeias multi-etapa: agentes frequentemente chamam ferramentas, APIs e outros agentes; você precisa de uma cadeia causal, não apenas de uma entrada de ação única.
• Código e modelos em evolução: agentes são código + modelo + runtime. Um nome de usuário não informa qual checkpoint do modelo, digest da imagem do contêiner ou política do agente foi usada.
• Delegação e aprovação: um agente pode agir em nome de um humano ou de outro sistema; a trilha de auditoria deve mostrar quem autorizou o agente e quais restrições estavam em vigor.

Em resumo: substitua o modelo mental de "uma pessoa clicou em um botão" por "um cálculo reprodutível transformou entradas em saídas e causou efeitos colaterais".

Campos mínimos que um registro de auditoria de agente de IA deve conter

Trate cada entrada de log como um registro de um cálculo e seus efeitos colaterais. No mínimo, inclua estes campos; se seu ambiente tiver necessidades legais ou operacionais, acrescente os itens relevantes (exemplos e justificativas abaixo).

• record_id — um UUID estável para a entrada de auditoria (v4 ou v7) e número de sequência para a sessão.
• timestamp — RFC3339 UTC; inclua números de sequência monotónicos para detectar reordenação.
• agent_id — identificador lógico da instância do agente (não apenas o proprietário humano).
• agent_version — hash do commit, digest da imagem do contêiner (por exemplo, sha256:...) ou versão do pacote do código do agente.
• model_name & model_digest — identificador do modelo mais um digest ou checksum dos pesos/checkpoint usados (ou a string de versão do modelo hospedado).
• runtime_config — parâmetros do modelo: temperature, top_k/top_p, max_tokens, limites de concorrência e algoritmo de RNG.
• prompt_template_id & prompt_hash — identificador do template de prompt e um hash do prompt resolvido para evitar armazenar texto puro se isso for sensível.
• input_artifacts — referências (URIs) para anexos, arquivos ou dados externos usados, com checksums.
• actions — lista ordenada de ações que o agente executou, com timestamps, identificadores de ferramenta e resultados (nome da ferramenta, versão, código de saída, hash dos dados retornados).
• external_calls — cada chamada de API outbound com destino, host da URL, hash da requisição, hash da resposta e latência.
• human_principal — quem criou/aprovou o agente ou a requisição (id do usuário, função e afirmação de delegação).
• authorization_context — id da política, escopos permitidos, expiração e o token de aprovação ou id de auditoria que liga a ação a um fluxo de aprovação.
• outcome — estado final ou efeitos colaterais: arquivos gravados, comandos executados, alterações de rede; inclua ids de objeto e checksums.
• evidence_hash — um digest do payload completo do registro usado para detecção de adulteração (armazene separadamente ou assine; veja assinatura abaixo).
• p2p_or_relay — se a sessão foi peer-to-peer ou roteada via relay e, se relay: região e id do relay.
• log_integrity — metadados de assinatura (key id, algoritmo de assinatura, assinatura) caso você assine logs.

Esses campos formam o núcleo. Dependendo do risco e da regulação, adicione mais alguns: id do runtime do contêiner, versões do kernel/hipervisor, id de atestação TPM do hardware, números seriais de certificados usados para TLS e quaisquer ponteiros de procedência de datasets.

Sample audit entry

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

O exemplo acima equilibra reprodutibilidade (model_digest, prompt_hash, runtime_config) com privacidade (prompt armazenado como hash). Onde você precisar manter prompts completos por razões legais, restrinja o acesso e registre cada leitura do prompt bruto separadamente.

Imutabilidade, assinatura e políticas de retenção

Auditores e equipes de resposta a incidentes precisam confiar que os logs não foram adulterados. Duas medidas práticas:

• Armazenamento append-only com snapshots imutáveis (object storage com versioning/WORM ou sistemas de arquivos write-once). Mantenha um backup frio separado em outra região.
• Assinatura de logs: calcule um evidence_hash de cada registro e assine-o com uma chave dedicada para assinatura de logs. Roteie chaves em uma agenda e armazene chaves públicas antigas para verificação. Inclua metadados de assinatura (key id, algoritmo e expiração) dentro do registro.

Retenção: equipes operacionais comumente mantêm logs de alta fidelidade online por 90 dias para troubleshooting, retêm metadados indexados por 1 ano para conformidade e guardam arquivos imutáveis assinados por 1–7 anos dependendo da regulação. Defina retenção com assessoria jurídica — a duração correta varia por setor: finanças e saúde frequentemente exigem vários anos.

Privacidade, mascaramento e controles de acesso

Logs de auditoria para agentes podem conter segredos: chaves de API, PII, documentos escaneados ou dados contratuais. Registre o que é necessário para reprodutibilidade e nada mais. Controles práticos:

• Política de redaction/mascaramento: armazene hashes de entradas sensíveis (prompt_hash, file_hash) e mova o texto puro para um cofre protegido acessível apenas durante um incidente e somente com um fluxo de aprovação auditável.
• Menor privilégio: separe funções para escrita de logs, leitura de logs brutos e verificação de assinaturas. Cada leitura de logs brutos deve ser, por si só, auditada.
• Consentimento e vinculação: se um agente age em nome de um usuário, mantenha um vínculo claro (token de delegação, aprovação timestamped) para que você possa atribuir ações ao principal humano por razões legais e de GDPR.

GDPR e outras leis de privacidade tratam logs que contêm dados pessoais como dados pessoais; consulte a assessoria jurídica sobre minimização, limitação de finalidade e bases legais para armazenamento. Em caso de dúvida, faça hash ou redija e registre os acessos ao material não redigido.

Por que capturar detalhes do modelo e do runtime (não metadados opcionais)

Duas execuções do agente com o mesmo prompt podem divergir se a versão do modelo, temperatura, seed ou toolchain for diferente. Para reconstrução de incidentes você precisa de:

• Identificador do modelo e digest — a string de versão do modelo hospedado sozinha é frágil; um checksum ou versão imutável do provedor é melhor.
• Commit do código do agente ou digest da imagem — um bug introduzido no código do agente pode alterar o comportamento mais que o prompt.
• Parâmetros de runtime e seed — para reproduzir uma saída específica ou saber se a reprodução é viável em modo determinístico.
• Versões de ferramentas e respostas — uma ferramenta retornando dados diferentes muda os resultados; armazene hashes de resposta e endpoints.

Sem esses campos, você não pode afirmar de forma confiável o que o agente fez ou por que fez.

Controles operacionais: alertas, amostragem e modo forense

Logar tudo em alta fidelidade pode ser caro e arriscado. Adote uma estratégia em camadas:

• Amostragem padrão: armazene metadados completos (hashes, nomes de modelo, lista de ações) para cada execução, mas guarde prompts completos e respostas de ferramentas apenas quando a execução atender a um gatilho (ação de alto risco, reclamação de usuário, pontuação de violação de política).
• Modo forense: em alertas (checagem de política falhada, reclamação externa), capture artefatos brutos completos em um repositório forense selado e controlado e crie um snapshot imutável assinado para investigadores.
• Alertas em tempo real: crie regras para ações de alto risco (transferências bancárias, comandos privilegiados) e gere aprovações automatizadas ou bloqueios com intervenção humana antes que o efeito colateral ocorra.

Escolhas de infraestrutura: relay gerenciado vs hospedagem própria

Onde você armazena e transporta logs de auditoria importa. Para acesso remoto e ferramentas de agente, o relay gerenciado da Tenvo é a recomendação padrão para a maioria das equipes: fornece clientes nativos para Windows/macOS/Linux, um cliente via browser em beta público, e um relay gerenciado multi-região com logging e níveis de retenção embutidos (Free $0 / Lite $2.99/mo / Pro $7.99/mo). Usar o relay gerenciado transfere responsabilidades de renovação de certificados, escalonamento de relay, patching on-call e backups cross-region.

Caveat importante sobre relay: quando uma sessão recai para um relay, o TLS termina no relay, então quem opera o relay fica em posição de ver a sessão. Isso significa que você deve tratar logs hospedados no relay como potencialmente visíveis ao operador do relay. Se seu requisito proíbe qualquer infraestrutura de terceiros de acessar os payloads de sessão (por exemplo, certas restrições de conformidade ou residências de dados), a hospedagem própria é a escolha correta.

Hospede por conta própria apenas quando você tiver um requisito escrito: mandatos regulatórios que proíbam relays de terceiros, redes isoladas sem acesso outbound, ou regras estritas de residência de dados. Hospedar por conta própria traz custos: on-call, patching, custódia de chaves, renovação de certificados e ausência de failover multi-região automático salvo se você o construir — o relay gerenciado é mais barato se considerar esses custos operacionais.

Modelo de acesso aos logs de auditoria e resposta a incidentes

Defina quem pode fazer o quê com os logs antes de precisar deles. Controles mínimos:

• Somente gravação para agentes: serviços de agente anexam logs mas não podem ler logs brutos.
• Funções de leitura segregadas: analistas podem ler metadados; investigadores precisam de privilégio mais alto para desselar artefatos brutos e todo desselamento também é registrado e assinado.
• Atestações automatizadas: quando um investigador acessa dados selados, crie um registro de atestação assinado ligando a identidade do investigador, horário e propósito.

Durante um incidente, você precisará reconstruir a cadeia causal rapidamente. Se seus logs incluem model_digest, agent_version, prompt_hash, lista de ações e hashes de chamadas externas, normalmente você consegue identificar a causa raiz em horas em vez de dias.

Checklist para começar (passos práticos)

• Defina um JSON schema para seu registro de auditoria de agente e aplique-o em tempo de escrita. Inclua os campos listados anteriormente.
• Implemente evidence_hash e assine cada registro com uma chave para assinatura de logs; armazene chaves públicas em um keyset descobrível para auditores.
• Decida retenção: 90 dias online para registros completos; 1–7 anos arquivados dependendo da regulação.
• Crie regras de redaction/mascaramento: o que é hashado vs armazenado em texto puro e quem pode acessar o texto puro.
• Adicione checagens de política em tempo real e aprovações automatizadas para ações de alto risco.
• Execute testes semanais de reprodutibilidade: escolha uma entrada amostrada e verifique se você consegue reproduzir o resultado do agente com o modelo, seed e config registrados.

Se você já usa ferramentas de desktop remoto ou agentes com a Tenvo, revise Projetando um rastro de auditoria de desktop remoto em conformidade para padrões de logging que se aplicam a sessões interativas, e consulte agente de IA remoto: políticas, aprovações, auditoria para fluxos de aprovação específicos de agentes. Para uma visão mais ampla de como agentes se encaixam em ferramentas remotas, veja IA e desktop remoto: como agentes usam ferramentas remotas.

Comece pequeno: implemente o schema, exija assinatura e itere nas regras de redaction. O resultado é resposta a incidentes mais rápida, delegação auditável e uma postura de conformidade defensável.

Baixe o Tenvo para testar logging e o comportamento do relay gerenciado localmente e veja como nosso relay, os preços (Free $0 / Lite $2.99/mo / Pro $7.99/mo) e relays multi-região simplificam as operações: Baixar.