# Usar os registos de auditoria

Source: https://help.didit.me/pt-PT/account-organization/audit-logs
Updated: 2026-10-29

Todos os pedidos de API da tua organização ficam registados durante 365 dias - quem, o quê, quando, de onde e sob que aplicação. É o primeiro sítio a consultar.

Todos os pedidos de API na tua organização são registados automaticamente e
mantidos durante **365 dias** - a partir da consola, da tua integração, e dos
teus colegas de equipa também. Encontra-os em **Definições → Registo de auditoria**.
Cada decisão que o Investigador toma por si próprio também fica registada aí,
identificada como **O investigador**.

[Video: O registo de auditoria - Didit Academy](https://www.youtube.com/watch?v=MkULotdgz2o&t=31)

## O que é registado

![Os registos de auditoria na consola Didit a mostrar atividade de API com marcas temporais e códigos de estado](https://help.didit.me/screenshots/audit-logs-light.webp)

*Todos os pedidos de API na organização, mantidos durante 365 dias.*

Todos os pedidos feitos à plataforma Didit dentro da tua organização, seja qual for a sua origem. Cada entrada tem:

| Campo | Detalhe |
|---|---|
| **Timestamp** | Quando o pedido foi feito |
| **User** | Quem o fez: o membro que fez o pedido; num pedido feito com chave de API, o nome da chave com uma etiqueta **Chave de API**; **Didit** para o que a Didit faz por si própria; e **O investigador** para uma decisão que toma por si próprio |
| **Method** | GET, POST, PUT, DELETE |
| **Path** | O endpoint que foi chamado |
| **Status** | O código de estado da resposta HTTP |
| **IP address** | De onde veio o pedido |
| **Application** | A que aplicação pertencia |

Os registos são mantidos durante **365 dias** e depois eliminados automaticamente.

Um registo de auditoria redesenhado, que descreve cada alteração por palavras e pode exportar o que estás a ver, está a ser disponibilizado gradualmente. Até chegar à tua organização, a página mostra o registo de pedidos descrito aqui.

## Para que serve na prática

Quatro situações em que é a ferramenta certa:

- **"Quem alterou este fluxo de trabalho?"** Um fluxo a comportar-se de forma diferente de ontem costuma ter uma edição por trás, e o registo diz quem a fez.
- **Investigar um incidente.** Traçar exatamente o que foi acedido, por quem, a partir de que endereço, e por que ordem.
- **Depurar uma integração.** Ver os pedidos que o teu próprio código realmente fez, em vez dos que julgas que fez - incluindo os que devolveram 4xx.
- **Provar o controlo de acesso.** Mostrar a um auditor que o acesso aos dados de verificação é atribuído e revisível.

## Filtrar

Filtra por utilizador (um membro, uma chave de API, Didit ou O investigador), endpoint ou intervalo de datas para reduzir uma lista longa. Quando estás a investigar algo específico, começa pela marca temporal e vai alargando a partir daí - um pedido raramente acontece sozinho, e as chamadas imediatamente à sua volta costumam contar a história.

## Os pedidos com chave de API são atribuídos à chave, não a uma pessoa

Um pedido feito com chave de API não tem uma pessoa a quem ser atribuído, por isso mostra antes o nome da chave. É a representação honesta - a plataforma genuinamente não sabe qual dos teus serviços ou engenheiros fez a chamada.

A consequência prática: uma única chave partilhada entre vários serviços torna um incidente materialmente mais difícil de investigar. Se a atribuição te importa, dá a cada serviço a sua própria chave. Consulta [gerir as tuas chaves de API](https://help.didit.me/pt-PT/account-organization/api-keys).

## As decisões próprias do Investigador são atribuídas ao Investigador

Quando o Investigador decide por si próprio, dentro da autonomia que lhe deste, a entrada indica **O investigador**, e não uma pessoa ou uma chave. Isto abrange cada decisão que toma: aprovar ou recusar uma sessão ou pedir ao utilizador que a volte a enviar, definir o estado de uma transação, e resolver um caso, escalá-lo ou pedir informações sobre ele. Cada uma destas entradas tem uma ligação para o relatório do Investigador por trás da decisão, para que vejas o que encontrou e que regra da tua 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 faça. O registo completo do Investigador, com os seus relatórios, perguntas e regras de segurança, continua no seu próprio registo de **Atividade**. Consulta [Controlar e supervisionar o Investigador](https://help.didit.me/pt-PT/investigations/investigator-automation-and-oversight).

## O que está no registo, e o que não está

O registo regista **atividade** - quem chamou o quê, quando, de onde, e que código de estado voltou. É uma trilha de metadados, não uma cópia dos dados de verificação.

Se precisares de saber se aparecem dados pessoais de clientes nestas entradas - uma pergunta que surge durante as revisões de proteção de dados - obtém a resposta junto do teu contacto Didit e regista-a, em vez de a inferires a partir de uma página de ajuda. É exatamente o tipo de afirmação que a tua própria AIPD (avaliação de impacto sobre a proteção de dados) vai ter de comprovar.

## Quem pode ver isto

O acesso aos registos de auditoria segue a função de cada pessoa. **Responsável de Conformidade** inclui-o; **Leitor** não tem acesso alargado. Os proprietários podem concedê-lo a uma função personalizada. Consulta [convidar membros da equipa e definir funções](https://help.didit.me/pt-PT/account-organization/team-members-and-roles).

Remover um colega de equipa não remove o seu histórico do registo - e é exatamente esse o objetivo. Uma trilha que se pode editar não é uma trilha.

## As exportações e os relatórios também são registados

Gerar um PDF de sessão ou uma exportação CSV é uma chamada de API, por isso aparece aqui com quem a fez. Isso é útil quando precisas de mostrar que o acesso à evidência de verificação é controlado e não livre. Consulta [descarregar um relatório de verificação](https://help.didit.me/pt-PT/verification-sessions/download-verification-report).

## Se precisares de mais do que 365 dias

A retenção está fixada em 365 dias. Se a tua obrigação for mais longa, exporta o que precisares periodicamente e guarda-o no teu próprio sistema - o mesmo padrão que usarias para reteres tu próprio a evidência de sessão. Decidir o período exigido é uma decisão de conformidade da tua equipa; não planeies com base numa suposição.

> **Note:** A retenção dos registos de auditoria e a retenção dos **dados de verificação**
> são definições separadas. Configurar uma janela de retenção curta para os
> dados de sessão não encurta o registo de auditoria, e o inverso também é
> verdade. Consulta
> [como a Didit protege os dados dos teus utilizadores](https://help.didit.me/pt-PT/data-privacy/how-didit-protects-data).