# Usando os registros de auditoria Source: https://help.didit.me/pt-BR/account-organization/audit-logs Updated: 2026-10-29 Toda requisição de API da sua organização fica registrada por 365 dias, com quem, o quê, quando, de onde e sob qual aplicação. É o primeiro lugar a olhar. Toda requisição de API na sua organização é registrada automaticamente e mantida por **365 dias** - do console, da sua integração e dos seus colegas de equipe. Encontre em **Configurações → Registro de auditoria**. Cada decisão que o Investigador toma por conta própria também fica registrada ali, identificada como **O investigador**. [Video: O log de auditoria - Didit Academy](https://www.youtube.com/watch?v=MkULotdgz2o&t=31) ## O que é registrado ![Registros de auditoria no console da Didit mostrando a atividade da API com carimbos de data/hora e códigos de status](https://help.didit.me/screenshots/audit-logs-light.webp) *Toda requisição de API da organização, mantida por 365 dias.* Toda requisição feita à plataforma Didit dentro da sua organização, seja qual for a origem. Cada entrada traz: | Campo | Detalhe | |---|---| | **Carimbo de data/hora** | Quando a requisição foi feita | | **User** | Quem fez: o membro que fez a requisição; para uma requisição com chave de API, o nome da chave com uma tag **Chave de API**; **Didit** para o que a Didit faz por conta própria; e **O investigador** para uma decisão que ele toma por conta própria | | **Method** | GET, POST, PUT, DELETE | | **Path** | O endpoint chamado | | **Status** | O código de status HTTP da resposta | | **Endereço IP** | De onde veio a requisição | | **Application** | A qual aplicação ela pertencia | Os registros são mantidos por **365 dias** e depois excluídos automaticamente. Um registro de auditoria redesenhado, que descreve cada alteração em palavras e pode exportar o que você está vendo, está sendo liberado aos poucos. Até ele chegar à sua organização, a página mostra o registro de requisições descrito aqui. ## Para que ele realmente serve Quatro situações em que é a ferramenta certa: - **"Quem alterou este fluxo de trabalho?"** Um fluxo se comportando de forma diferente de ontem geralmente tem uma edição por trás, e o registro mostra quem a fez. - **Investigando um incidente.** Rastrear exatamente o que foi acessado, por quem, a partir de qual endereço, em qual ordem. - **Depurando uma integração.** Ver as requisições que o seu próprio código realmente fez, em vez das que você acredita que fez - inclusive as que retornaram 4xx. - **Evidenciando o controle de acesso.** Mostrar a um auditor que o acesso a dados de verificação é atribuído e revisável. ## Filtrando Filtre por usuário (um membro, uma chave de API, Didit ou O investigador), endpoint ou intervalo de datas para reduzir uma lista longa. Ao investigar algo específico, comece pelo carimbo de data/hora e vá se afastando dali - uma requisição raramente acontece sozinha, e as chamadas ao redor dela geralmente contam a história. ## Requisições com chave de API são atribuídas à chave, não a uma pessoa Uma requisição com chave de API não tem uma pessoa a quem atribuí-la, então ela mostra o nome da chave. Essa é a representação honesta - a plataforma genuinamente não sabe qual dos seus serviços ou engenheiros fez a chamada. A consequência prática: uma única chave compartilhada entre vários serviços torna um incidente consideravelmente mais difícil de investigar. Se a atribuição importa para você, dê a cada serviço sua própria chave. Veja [como gerenciar suas chaves de API](https://help.didit.me/pt-BR/account-organization/api-keys). ## As decisões próprias do Investigador são atribuídas ao Investigador Quando o Investigador decide por conta própria, dentro da autonomia que você deu a ele, a entrada mostra **O investigador**, e não uma pessoa ou uma chave. Isso vale para cada decisão que ele toma: aprovar ou recusar uma sessão ou pedir ao usuário que a reenvie, definir o status de uma transação e resolver um caso, encaminhá-lo ou pedir informações sobre ele. Cada uma dessas entradas leva ao relatório do Investigador por trás da decisão, para que você veja o que ele encontrou e qual regra da sua política aplicou. Quando uma pessoa decide sobre um relatório do Investigador, aceitando a recomendação ou alterando-a, a entrada é atribuída a essa pessoa, como qualquer outra alteração que ela faça. A trilha completa do Investigador, com seus relatórios, perguntas e regras de segurança, continua no próprio registro de **Atividade** dele. Veja [Controlar e supervisionar o Investigador](https://help.didit.me/pt-BR/investigations/investigator-automation-and-oversight). ## O que está no registro, e o que não está O registro guarda **atividade** - quem chamou o quê, quando, de onde e qual status voltou. É uma trilha de metadados, não uma cópia dos dados de verificação. Se você precisa saber se dados pessoais de clientes aparecem nessas entradas - uma pergunta comum durante revisões de proteção de dados - obtenha a resposta com o seu contato na Didit e registre-a, em vez de deduzi-la de uma página de ajuda. É exatamente o tipo de afirmação que a sua própria AIPD (avaliação de impacto à proteção de dados) vai precisar comprovar. ## Quem pode ver O acesso aos registros de auditoria segue a função de cada pessoa. **Responsável pela Conformidade** inclui esse acesso; **Leitor** não tem acesso amplo. Proprietários podem concedê-lo a uma função personalizada. Veja [como convidar membros da equipe e definir funções](https://help.didit.me/pt-BR/account-organization/team-members-and-roles). Remover um colega não remove o histórico dele do registro - e esse é o objetivo. Uma trilha que você pode editar não é uma trilha. ## Exportações e relatórios também são registrados Gerar um PDF de sessão ou uma exportação CSV é uma chamada de API, então ela aparece aqui com quem a fez. Isso é útil quando você precisa mostrar que o acesso a evidências de verificação é controlado, e não livre. Veja [como baixar um relatório de verificação](https://help.didit.me/pt-BR/verification-sessions/download-verification-report). ## Se você precisa de mais de 365 dias A retenção é fixa em 365 dias. Se a sua obrigação exige um período maior, exporte o que você precisa periodicamente e guarde no seu próprio sistema - o mesmo padrão de reter evidências de sessão por conta própria. Decidir o período exigido é uma decisão de conformidade da sua equipe; não planeje em cima de uma suposição. > **Note:** A retenção dos registros de auditoria e a retenção dos **dados de verificação** > são configurações separadas. Definir uma janela de retenção curta para os dados > de sessão não encurta o registro de auditoria, e o contrário também é verdade. > Veja [como a Didit protege os dados dos seus usuários](https://help.didit.me/pt-BR/data-privacy/how-didit-protects-data).