Guia de design de logs de auditoria para IA generativa: as evidências de uso de IA exigidas pelo AI Act da UE, pela ISO/IEC 42001 e pelas diretrizes japonesas para empresas de IA, e como registrá-las

Usar IA generativa internamente, incorporar recursos de IA a um produto, delegar tarefas a agentes de IA. Seja qual for o uso, em breve chegará o momento de explicar "quem usa essa IA, para quê e com que controle". Quem pergunta pode ser um auditor ou o questionário de segurança de um cliente.

Nessa hora, explicações verbais ou documentos de política não bastam: a pergunta é se você consegue demonstrar com registros. Este artigo organiza, passo a passo, o que leis e normas exigem, quais campos registrar, onde registrar e quais condições a evidência precisa atender para que o log de auditoria de IA generativa seja aceito como evidência.

O que é um log de auditoria de IA generativa

Um log de auditoria de IA generativa é o registro, para cada execução da IA, de "quando, quem (ou qual agente), com qual modelo e qual decisão foi tomada", guardado de forma que um terceiro possa verificá-lo depois.

Ele tem um propósito diferente dos logs de operação ou de aplicação do dia a dia.

A maior diferença é que quem lê é alguém de fora. Se você não conseguir mostrar a essa pessoa que "este log não foi alterado depois", por mais detalhado que seja o registro, ele será uma evidência fraca.

Por que as "evidências de IA" estão sendo cobradas agora

Há três motivos principais.

• Avaliações de segurança de clientes: crescem as perguntas sobre o uso de IA generativa — escopo de uso, dados inseridos e retenção de logs
• Auditorias de SOC 2 Type II e de ISMS (ISO/IEC 27001): é preciso mostrar que os controles funcionaram durante todo o período de observação, e o uso de IA também entra no que precisa ser explicado
• Disseminação dos agentes de IA: cada vez mais tarefas são executadas de forma autônoma por IA em vez de pessoas, e é necessário um registro que permita rastrear "quem fez" no nível de cada IA

Tabela de referência: os registros exigidos por leis e normas

Conteúdo confirmado em fontes primárias em 31 de outubro de 2026.

O ponto a reter é que o que o AI Act da UE adiou foram as datas de aplicação, não a exigência de logs em si. Quando a aplicação começar, será preciso já ter acumulado logs de "no mínimo 6 meses". O realista é montar o mecanismo de logs desde já, e não às vésperas da data de aplicação.

Fontes primárias: AI Act da UE, artigo 12 · artigo 19 · artigo 26 · artigo 113 (datas de aplicação) (AI Act Service Desk da Comissão Europeia) / Diretrizes para Empresas de IA (Ministério da Economia, Comércio e Indústria do Japão) / Entrada em vigor da Lei de Promoção da IA (Gabinete do Governo do Japão)

O que registrar

Registrar os campos abaixo para cada execução da IA facilita a prestação de contas.

Vale a pena guardar o texto dos prompts e das saídas?

Na maioria dos casos, não é preciso guardar o texto em si: bastam a impressão digital (hash) e metadados que não incluam o conteúdo.

O texto tende a conter dados pessoais e informações confidenciais de clientes, e quanto mais se acumula, maior o dano em caso de vazamento. Com o hash guardado, se surgir um problema, é possível compará-lo com o texto que você tem em mãos e confirmar que "a entrada e a saída eram essas".

As diretrizes da OWASP para prevenção de prompt injection em LLMs também, na revisão de 4 de outubro de 2026, pedem que os logs mantenham "metadados e decisões relevantes para a segurança" e excluam credenciais e informações sensíveis desnecessárias (OWASP Cheat Sheet).

Onde registrar

O local de registro muda o que pode ser registrado e o grau de confiança.

O mais seguro é combinar código e proxy, em vez de escolher um só. O proxy captura sem falhas "que houve uma chamada", e o motivo de cada decisão é registrado pela camada de código que a tomou.

Outro ponto importante: um log que você mesmo escreve e guarda, por si só, dificilmente convence quem está de fora. É preciso um mecanismo que demonstre que ele não pode ser reescrito depois. A próxima seção explica isso.

Condições para que a evidência seja aceita numa auditoria

Para que um log funcione como "evidência", são necessárias estas cinco condições.

1. Demonstrar que não foi reescrito: encadeando a impressão digital (hash) de cada registro à do registro anterior, alterar um único registro no meio faz o encadeamento a partir dele deixar de bater, e a adulteração é detectada
2. Permitir que um terceiro verifique por conta própria: deixe o log numa forma verificável localmente, sem precisar confiar na empresa ou no serviço que o gerou
3. Cumprir o período de retenção: cubra os "no mínimo 6 meses" do AI Act da UE e o período de observação da auditoria (geralmente de 6 a 12 meses)
4. Mostrar de quem foi cada operação: com contas ou chaves compartilhadas, não há como explicar quem usou. Registre pessoas e agentes separadamente
5. Deixar claro quais campos faltam: declarar explicitamente "o que não é registrado" permite explicar com honestidade o alcance do registro. Um registro em que não se sabe o que ficou de fora acaba perdendo credibilidade

Questões específicas dos agentes de IA

Os agentes de IA chamam ferramentas e avançam no trabalho de forma autônoma, no lugar das pessoas. Por isso surgem questões diferentes das da IA generativa usada por pessoas.

• Identificar cada agente: registre separadamente qual agente fez o quê. Se tudo rodar com uma única chave de API, não há como distinguir
• Registrar as chamadas de ferramentas: o risco é completamente diferente se o agente apenas gerou texto ou se operou um sistema externo
• Registrar se houve revisão humana: se uma pessoa revisou uma operação importante antes de ela acontecer está diretamente ligado à explicação de quem é o responsável
• Incluir também os agentes de código: os agentes de código que os engenheiros usam no dia a dia também são, em termos de tráfego, chamadas de IA. Costumam ser esquecidos, mas devem entrar no escopo do registro

O que o SPHIOR faz

A governança de IA do SPHIOR é um mecanismo para manter registros que atendam às condições descritas até aqui.

Formas de registrar (4 opções)

IAs e ferramentas compatíveis

Se a API de destino for de um fornecedor conhecido, o proxy registra o nome dele; nos demais casos (modelos hospedados pela própria empresa, gateways internos etc.), registra o nome de host de destino tal como está. O destino nunca é preenchido com suposições arbitrárias. As instruções de configuração estão na documentação.

Como os registros são tratados

• O conteúdo não é enviado: por padrão, o texto dos prompts e das saídas não é enviado; registram-se apenas a impressão digital (hash) e metadados
• Guardados de forma que a adulteração seja detectável: cada registro é normalizado e convertido em hash, encadeado ao anterior, e os registros são carimbados externamente no tempo em lote
• Verificáveis por terceiros: com a ferramenta de verificação pública, é possível conferir localmente sem precisar confiar no SPHIOR
• As decisões continuam nos seus mecanismos: quem decide permitir ou bloquear são os guardrails da sua empresa; o SPHIOR registra o resultado
• Os campos não registrados também são declarados: por exemplo, no proxy o custo não é registrado a menos que você configure os preços unitários (os preços reais variam conforme descontos e contratos, por isso não são estimados). Além disso, como o proxy não enxerga as decisões dos guardrails da sua empresa, parte-se do princípio de que essas decisões sejam registradas pela camada de código

O que você pode mostrar ao auditor

• A lista de execuções (com filtros por agente, modelo, decisão e período)
• O número de execuções por combinação agente × modelo e a distribuição das decisões (permitir, bloquear etc.)
• As informações de verificação de cada registro
• Um pacote de verificação para o período escolhido (até 1.000 registros por exportação; se houver mais, exporte em períodos menores)

Preços

Não cobramos por volume de registros. Com cobrança por volume, "registrar menos sairia mais barato", o que contradiz o objetivo de registrar tudo sem falhas. Os planos pagos não interrompem o registro ao ultrapassar o limite, e o plano gratuito nunca vira pago sem você decidir. Veja mais em preços.

Perguntas frequentes

Basta guardar os logs por 6 meses?

O que os artigos 19 e 26 do AI Act da UE estabelecem é "no mínimo 6 meses". Dependendo da finalidade, pode ser exigido um período mais longo, e auditorias como o SOC 2 Type II exigem cobrir o período de observação (geralmente de 6 a 12 meses). Se outras leis tiverem regras diferentes, elas também devem ser seguidas.

Sem guardar o texto dos prompts, não fica impossível investigar quando surgir um problema?

Com a impressão digital (hash) guardada, é possível compará-la com o texto que você ainda tem ou com os logs do fornecedor e confirmar se a entrada e a saída eram aquelas. Quanto mais texto se acumula, maior o dano em caso de vazamento; por isso, o realista é decidir se guarda o texto comparando a necessidade de investigação com o risco de vazamento.

Isso substitui a certificação ISO/IEC 42001?

Não. A certificação é obtida após a avaliação de um organismo de certificação. O log de auditoria é um dos materiais usados nessa avaliação e na prestação de contas interna e externa.

Um log criado pela própria empresa não serve?

Serve. Porém, ao apresentá-lo a pessoas de fora, é preciso conseguir explicar que "ele não foi reescrito depois". Deixá-lo numa forma que demonstre isso — com encadeamento de hashes ou carimbo de tempo externo, por exemplo — encurta a explicação.

Resumo

• O log de auditoria de IA generativa é um registro para prestar contas a pessoas de fora. Mais do que o nível de detalhe, importa que não tenha sido reescrito e que mostre de quem foi cada operação
• O AI Act da UE adiou as datas de aplicação, mas a exigência de registro automático de logs e de retenção mínima de 6 meses continua de pé
• O básico é não guardar o texto e registrar impressão digital e metadados. Declare também os campos que não são registrados
• Combine proxy e camada de código, e inclua no escopo do registro os agentes de IA e os agentes de código

Relacionado: Como apresentar a gestão de mudanças no GitHub como evidência para ISO/IEC 27001 (ISMS) e SOC 2