//
Busque em todas as páginas da documentação
Cada espaço de trabalho executado no Claude acumula um registro silencioso e contínuo de quem fez o quê.
Esse registro é o log de auditoria, e é uma das ferramentas menos glamorosas, mas mais úteis que um administrador possui para responder "o que realmente aconteceu aqui" após o fato.
Saber o que ele captura - e, igualmente importante, o que ele não captura - é o que separa uma equipe que pode investigar um incidente com calma de uma que está adivinhando.
Um log de auditoria é um registro cronológico de ações significativas tomadas dentro de um sistema.
No Console Claude, isso significa ações administrativas - coisas como alterar uma configuração do espaço de trabalho, adicionar ou remover um usuário, ajustar permissões - e eventos de acesso, como quem fez login e quando.
Cada entrada normalmente vincula uma ação a um ator (quem a fez) e um timestamp (quando aconteceu), que juntos permitem que alguém reconstrua uma linha do tempo após o fato.
Pense nisso como o registro de segurança de um prédio: ele não diz o que foi dito em nenhuma reunião específica, mas diz quem passou o crachá, quando e quais portas abriu.
Essa distinção é importante - o log de auditoria trata de atividade administrativa e de acesso, não de uma transcrição do conteúdo da conversa.
O valor do log de auditoria vem de ser abrangente e, em espírito, somente de adição (append-only): ele acumula um registro ao longo do tempo em vez de ser algo que os administradores curam ou preenchem seletivamente.
É isso que o torna útil como evidência - um log que um administrador poderia editar após o fato não seria confiável como um mecanismo de responsabilidade.
Na prática, os tipos de eventos que entram no log incluem alterações de configurações (como ajustar uma janela de retenção ou um opt-out de treinamento), gerenciamento de usuários e permissões (adicionar um usuário, alterar a função de alguém, remover acesso) e atividade de login ou acesso em nível de administrador.
O log interage com o restante da postura de governança de uma organização de maneira direta: é a trilha de evidências que permite a uma equipe de segurança verificar se as configurações que eles acreditam estar configuradas realmente permaneceram configuradas, e é o primeiro lugar a procurar quando algo muda inesperadamente - uma permissão que foi escalada, uma configuração que reverteu ou um usuário que não deveria mais ter acesso.
Como ele está restrito a ações administrativas e eventos de acesso em vez de conteúdo de conversa, o log de auditoria responde "alguém mudou esta configuração e quando" - não "o que alguém colou em uma conversa".
Para essa segunda pergunta, uma organização precisa de práticas de DLP separadas e orientação interna, não do log de auditoria.
Em escala, os logs de auditoria tornam-se mais valiosos quando são revisados em uma cadência, em vez de apenas depois que algo já deu errado.
Uma equipe que verifica o log trimestralmente - ou após qualquer evento importante, como a integração de uma nova unidade de negócios - detecta desvios precocemente: uma permissão que foi concedida para um projeto único e nunca revogada, uma configuração que foi alterada e ninguém se lembra por quê.
Os logs de auditoria também desempenham um papel específico na documentação de conformidade.
Quando uma organização precisa demonstrar a um auditor ou cliente que seu espaço de trabalho Claude é governado de forma responsável, o log de auditoria é evidência direta de que as ações administrativas são rastreadas e atribuíveis - o que apoia tanto a revisão de controles operacionais no estilo SOC2 quanto a responsabilidade que o GDPR espera em relação às decisões de processamento de dados.
| Caso de Uso | O que o Log de Auditoria Fornece | O que Ele Não Fornece |
|---|---|---|
| Investigação de incidentes | Linha do tempo de ações administrativas e eventos de acesso em torno da janela do incidente | Conteúdo do que foi colado em qualquer conversa |
| Evidência de conformidade | Prova de que a atividade administrativa é rastreada e atribuível | Um substituto para um programa de conformidade completo |
| Revisão de segurança de rotina | Uma maneira de capturar desvios de permissão ou configuração ao longo do tempo | Alerta em tempo real - geralmente é revisado, não monitorado ao vivo por padrão |
Uma lacuna comum nas primeiras implementações é que o log de auditoria existe, mas ninguém atribuiu a responsabilidade de revisá-lo - ele acumula dados silenciosamente e nunca é aberto até que um incidente force a questão.
Atribuir uma pessoa ou equipe específica para revisá-lo em um cronograma fixo, mesmo que brevemente, transforma-o de um registro passivo em uma ferramenta de governança ativa.
Não.
Ele captura ações administrativas e eventos de acesso - não é uma transcrição ou arquivo do que foi dito dentro das conversas.
Normalmente um administrador designado ou proprietário de segurança, em uma cadência recorrente, como trimestralmente, mais uma revisão ad hoc sempre que algo inesperado mudar no espaço de trabalho.
O valor de um log de auditoria vem de ser um registro confiável e somente de adição de atividade - se as entradas pudessem ser livremente editadas após o fato, isso minaria sua utilidade como um mecanismo de responsabilidade.
Ele fornece evidências de que a atividade administrativa é rastreada e atribuível, que é exatamente o tipo de evidência de controle operacional que uma revisão de segurança no estilo SOC2 procura.
Trate-a como algo que vale a pena investigar - confirme se a mudança foi intencional, quem a fez e se ela precisa ser revertida ou documentada como uma exceção aprovada.
Não - o log de auditoria rastreia a atividade administrativa e de acesso, enquanto as preocupações com DLP são sobre o que os funcionários colam nas conversas; são partes complementares, mas distintas, de um programa de governança.
Não por si só - é uma peça de evidência que apoia a responsabilidade, mas a conformidade com o GDPR depende de um conjunto mais amplo de práticas em torno do manuseio de dados, retenção e direitos individuais.
Abra-o, escaneie o último trimestre de entradas em busca de algo desconhecido e atribua a alguém a responsabilidade de revisá-lo daqui para frente em um cronograma fixo.
Ele se concentra em ações administrativas e eventos de acesso - as atividades que afetam a configuração e o acesso do espaço de trabalho, em vez de cada ação que um usuário regular realiza dentro de uma conversa.
Reconstruir uma linha do tempo de incidentes depende de saber exatamente quando uma mudança ocorreu em relação a outros eventos, portanto, timestamps precisos são o que tornam o log utilizável como evidência investigativa, em vez de apenas uma lista de atividades aproximada.
Nunca atribuir a responsabilidade de revisá-los, de modo que o log exista e acumule dados, mas só seja aberto reativamente, após um incidente já ter ocorrido.
Versões da Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5. Nomes de modelos, preços e recursos do produto mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.