Log de auditoria

O log de auditoria da i1n registra cada mutação em uma organização — não como uma linha genérica de 'arquivo de tradução atualizado', mas como um evento estruturado, por chave e por idioma. Quando um usuário do painel altera a tradução para espanhol (es_mx) de errors.insufficient_funds às 14:32 UTC, o log captura o valor exato anterior, o valor exato posterior, a identidade do ator, o timestamp, o endereço IP e o agente do usuário da solicitação que produziu a alteração.

A cobertura abrange toda a área da plataforma: criação, edição e exclusão de traduções; criação, renomeação e remoção de namespaces; alterações nas configurações do projeto e na voz da marca; convites de equipe, alterações de função e remoções; criação, rotação, alterações de escopo e exclusão de chaves de API; alterações no plano de faturamento, eventos de assinatura e ativação do BYOK.

Operações em massa, como o push i1n, produzem um evento por par chave-idioma modificado, em vez de um único resumo geral, com um identificador de lote compartilhado nos metadados. Um push que atualiza 200 chaves em quatro idiomas produz 800 entradas de auditoria individualmente endereçáveis, cada uma com sua própria diferença. Os auditores podem, portanto, responder 'o que mudou em 17 de abril às 14:32' até a string exata.

Eventos são emitidos por gatilhos do PostgreSQL anexados a cada tabela auditada. Não há um caminho de escrita em nível de aplicativo que contorne o log — cada mutação bem-sucedida gera sua linha de auditoria dentro da mesma transação do banco de dados. Uma alteração que é confirmada sem uma linha de auditoria correspondente não é possível por construção.

Cada entrada de auditoria é marcada com um de cinco tipos de ator: user para mutações do painel, cli para operações diretas da linha de comando, mcp para alterações feitas por um agente de IA através do servidor i1n MCP, webhook para eventos originados de sistemas externos como o provedor de faturamento e system para trabalhos internos da plataforma como a poda de retenção.

A atribuição de usuários no painel é criptográfica. O identificador do ator é o ID da conta do usuário autenticado, exibido junto com seu e-mail verificado e nome da lista de membros da organização. Administradores que revisam o log veem identidades humanas reais, não UUIDs opacos.

A atribuição de CLI e MCP está criptograficamente vinculada à chave de API em uso, com o prefixo da chave registrado para correlação forense. Dicas derivadas da configuração git do desenvolvedor — e-mail e nome completo — também são capturadas, mas são explicitamente rotuladas como não verificadas no painel. Essa separação honesta entre identidade criptográfica e metadados autodeclarados é o que os revisores de conformidade esperam de um sistema de auditoria maduro.

A observabilidade de agentes de IA é, até onde sabemos, exclusiva do i1n. Cada alteração de tradução feita pelo Claude Code, Cursor ou qualquer outro cliente conectado ao servidor i1n MCP é marcada com actor_type = 'mcp'. As organizações podem filtrar o log de auditoria para responder 'quais traduções foram modificadas pela última vez por um agente de IA em vez de um revisor humano' — uma pergunta que não tem uma resposta clara em nenhuma outra plataforma de localização.

À medida que os agentes de IA assumem mais do fluxo de trabalho de localização, a capacidade de auditá-los como atores de primeira classe está se tornando um requisito de aquisição. O filtro de tipo de ator está a um clique no painel e a um parâmetro de consulta na exportação CSV.

O log de auditoria é somente de adição no nível do banco de dados. Gatilhos emitem linhas; nenhum caminho de INSERT é exposto aos clientes, e não há políticas de UPDATE ou DELETE na tabela. Membros de uma organização não podem editar seu próprio histórico. A equipe de operações da i1n também não pode editar ou excluir entradas — a tabela é protegida na camada de esquema, não na camada de aplicação.

A retenção é de 365 dias, alinhada com a linha de base de controle SOC 2 para logs de atividades. Registros com mais de 365 dias são removidos por um trabalho agendado que, por sua vez, emite uma entrada de auditoria — cada exclusão é rastreável. Organizações que exigem janelas mais longas para uma revisão regulatória específica podem solicitar uma extensão no nível do contrato.

O log exibe os pontos de dados que os revisores de conformidade normalmente solicitam: quem, o quê, quando, onde (endereço IP), como (agente do usuário) e o que mudou (valores antes e depois, por extenso). Para organizações sujeitas ao registro de acordo com o Artigo 30 do GDPR ou a reguladores fintech que exigem rastreabilidade do conteúdo voltado para o usuário, a exportação é suficiente como evidência primária.

Atualmente, a i1n não publica um relatório SOC 2 Type II no nível da plataforma. O log de auditoria é o controle subjacente que suporta o programa de conformidade SOC 2, GDPR ou fintech do cliente — ele não substitui os controles organizacionais, mas remove o bloqueador mais comum em revisões de conformidade, que é a ausência de um rastro auditável sobre alterações de conteúdo.

O acesso de leitura ao log de auditoria é restrito aos proprietários e administradores da organização. Editores e visualizadores não veem a aba de log de auditoria no painel e não podem consultá-la através da API. Essa separação é imposta pela segurança em nível de linha do PostgreSQL, não por ocultação no lado do cliente — não há como ler o log de uma função não privilegiada.

Editores e visualizadores permanecem totalmente sujeitos ao registro de auditoria. Cada ação que realizam na plataforma — edições de tradução, solicitações de tradução por IA, operações em nível de membro — é registrada com sua identidade e visível para a equipe de administração. As pessoas auditadas não podem se remover da auditoria.

Proprietários e administradores não podem editar entradas históricas. A pergunta 'quem pode ler' e a pergunta 'quem pode modificar' têm respostas deliberadamente diferentes — ler é em nível de administrador, modificar é para ninguém. Isso atende às expectativas de separação de funções que os auditores aplicam ao revisar os controles de acesso internos.

O acesso à API espelha o modelo do painel. O log de auditoria é exposto através das mesmas políticas de segurança de nível de linha que controlam o painel, portanto, qualquer conta de serviço ou token de integração usado para consultar o log herda automaticamente as mesmas restrições.

Os dados do log de auditoria podem ser exportados como CSV do painel com uma ação de um clique. A exportação abrange qualquer intervalo de tempo selecionado e respeita os filtros ativos — tipo de ator, tipo de evento, projeto e termo de pesquisa — para que os revisores recebam uma fatia restrita em vez do histórico completo. O CSV preserva a fidelidade total: timestamp, organização, projeto, identidade do ator, tipo de ator, prefixo da chave da API, tipo de evento, entidade, valor anterior, valor posterior, endereço IP, agente do usuário e metadados.

Cada exportação CSV gera em si uma entrada de auditoria do tipo audit_log.exported, registrando quem realizou a exportação e quais filtros foram aplicados. Isso fecha o ciclo de cadeia de custódia sobre o qual os revisores de conformidade perguntam — o ato de extrair evidências faz parte das próprias evidências.

O log de auditoria fica automaticamente ativo em todas as organizações Enterprise. Não há etapa de configuração, nem alternância de ativação, nem configuração necessária. Clientes Enterprise existentes — incluindo belo, o parceiro de lançamento — têm um log preenchido desde o momento em que o recurso foi lançado, capturando a atividade de cada painel, CLI e cliente MCP conectado à organização.

Organizações nos planos Pro ou Business não têm acesso ao log de auditoria. A atualização para o Enterprise ativa o log imediatamente e começa a capturar eventos a partir do carimbo de data/hora da atualização; a retenção histórica anterior à atualização não é fornecida. Entre em contato com a equipe i1n para discutir os preços do Enterprise para sua organização.