Registro di controllo

Il registro di audit di i1n registra ogni mutazione in un'organizzazione, non come una generica riga 'file di traduzione aggiornato', ma come un evento strutturato, per chiave e per lingua. Quando un utente della dashboard modifica la traduzione spagnola (es_mx) di errors.insufficient_funds alle 14:32 UTC, il log cattura il valore esatto precedente, il valore esatto successivo, l'identità dell'attore, il timestamp, l'indirizzo IP e l'user agent della richiesta che ha prodotto la modifica.

La copertura si estende all'intera superficie della piattaforma: creazione, modifica ed eliminazione delle traduzioni; creazione, ridenominazione ed eliminazione dei namespace; modifiche alle impostazioni del progetto e alla brand voice; inviti del team, modifiche dei ruoli ed eliminazioni; creazione, rotazione, modifiche dell'ambito ed eliminazione delle chiavi API; modifiche ai piani di fatturazione, eventi di sottoscrizione e attivazione BYOK.

Le operazioni in blocco, come il push i1n, producono un evento per ogni coppia chiave-lingua modificata anziché un singolo riepilogo generico, con un identificatore di batch condiviso nei metadati. Un push che aggiorna 200 chiavi in quattro lingue produce 800 voci di audit indirizzabili individualmente, ognuna con la propria differenza. I revisori possono quindi rispondere 'cosa è cambiato il 17 aprile alle 14:32' fino alla stringa esatta.

Gli eventi vengono emessi da trigger PostgreSQL collegati a ogni tabella sottoposta ad audit. Non esiste un percorso di scrittura a livello di applicazione che aggiri il log: ogni mutazione riuscita genera la sua riga di audit all'interno della stessa transazione del database. Una modifica che viene confermata senza una riga di audit corrispondente non è possibile per costruzione.

Ogni voce di audit è contrassegnata con uno dei cinque tipi di attore: 'user' per le mutazioni della dashboard, 'cli' per le operazioni dirette da riga di comando, 'mcp' per le modifiche apportate da un agente AI tramite il server MCP di i1n, 'webhook' per eventi originati da sistemi esterni come il provider di fatturazione e 'system' per processi interni alla piattaforma come la potatura della conservazione.

L'attribuzione dell'utente della dashboard è crittografica. L'identificatore dell'attore è l'ID dell'account dell'utente autenticato, visualizzato insieme alla sua email verificata e al nome dall'elenco dei membri dell'organizzazione. Gli amministratori che esaminano il log vedono identità umane reali, non UUID opachi.

L'attribuzione CLI e MCP è crittograficamente legata alla chiave API in uso, con il prefisso della chiave registrato per la correlazione forense. Vengono inoltre acquisiti suggerimenti derivati dalla configurazione git dello sviluppatore —email e nome completo— ma sono esplicitamente etichettati come non verificati nella dashboard. Questa onesta separazione tra identità crittografica e metadati auto-segnalati è ciò che i revisori di conformità si aspettano da un sistema di audit maturo.

L'osservabilità dell'agente AI è, per quanto ne sappiamo, unica di i1n. Ogni modifica di traduzione apportata da Claude Code, Cursor o qualsiasi altro client connesso al server i1n MCP viene contrassegnata con actor_type = 'mcp'. Le organizzazioni possono filtrare il registro di audit per rispondere a 'quali traduzioni sono state modificate l'ultima volta da un agente AI rispetto a un revisore umano', una domanda che non ha una risposta chiara su nessun'altra piattaforma di localizzazione.

Man mano che gli agenti AI assumono una maggiore parte del flusso di lavoro di localizzazione, la capacità di controllarli come attori di prima classe sta diventando un requisito di approvvigionamento. Il filtro del tipo di attore è a un clic nella dashboard e un parametro di query nell'esportazione CSV.

Il registro di controllo è di sola aggiunta a livello di database. I trigger emettono righe; nessun percorso INSERT è esposto ai client e non ci sono criteri UPDATE o DELETE sulla tabella. I membri di un'organizzazione non possono modificare la propria cronologia. Anche il personale operativo di i1n non può modificare o eliminare voci: la tabella è protetta a livello di schema, non a livello di applicazione.

La conservazione è di 365 giorni, in linea con la base di controllo SOC 2 per i log delle attività. I record più vecchi di 365 giorni vengono rimossi da un processo pianificato che a sua volta emette una voce di audit — ogni eliminazione è tracciabile. Le organizzazioni che richiedono periodi più lunghi per una specifica revisione normativa possono richiedere un'estensione a livello di contratto.

Il registro espone i punti dati che i revisori di conformità solitamente richiedono: chi, cosa, quando, dove (indirizzo IP), come (user agent) e cosa è cambiato (valori prima e dopo, per intero). Per le organizzazioni soggette ai requisiti di tenuta dei registri dell'Articolo 30 del GDPR o ai regolatori fintech che richiedono la tracciabilità dei contenuti rivolti agli utenti, l'esportazione è sufficiente come prova primaria.

i1n non pubblica attualmente un report SOC 2 Type II a livello di piattaforma. Il registro di controllo è il controllo sottostante che supporta il programma di conformità SOC 2, GDPR o fintech del cliente: non sostituisce i controlli organizzativi, ma rimuove il blocco più comune nelle revisioni di conformità, ovvero l'assenza di una traccia verificabile delle modifiche ai contenuti.

L'accesso in lettura al registro di audit è limitato ai proprietari e agli amministratori dell'organizzazione. Editor e visualizzatori non vedono la scheda del registro di audit nella dashboard e non possono interrogarla tramite API. Questa separazione è applicata dalla sicurezza a livello di riga di PostgreSQL, non dall'occultamento lato client: non esiste alcun modo per leggere il log da un ruolo non privilegiato.

Editor e visualizzatori rimangono pienamente soggetti al registro di controllo. Ogni azione intrapresa sulla piattaforma — modifiche alle traduzioni, richieste di traduzioni AI, operazioni a livello di membro — viene registrata con la loro identità e visibile al team di amministrazione. Le persone sottoposte a controllo non possono rimuovere sé stesse dal registro.

Proprietari e amministratori non possono modificare le voci storiche. La domanda 'chi può leggere' e la domanda 'chi può modificare' hanno volutamente risposte diverse: la lettura è a livello di amministratore, la modifica è per nessuno. Questo soddisfa le aspettative di separazione dei compiti che i revisori applicano durante la revisione dei controlli di accesso interni.

L'accesso all'API rispecchia il modello della dashboard. Il log di controllo è esposto attraverso le stesse policy di sicurezza a livello di riga che controllano la dashboard, quindi qualsiasi account di servizio o token di integrazione utilizzato per interrogare il log eredita automaticamente le stesse restrizioni.

I dati del registro di controllo possono essere esportati come CSV dalla dashboard con un'azione con un clic. L'esportazione copre qualsiasi intervallo di tempo selezionato e rispetta i filtri attivi —tipo di attore, tipo di evento, progetto e termine di ricerca— in modo che ai revisori possa essere consegnata una porzione ristretta anziché la cronologia completa. Il CSV conserva la piena fedeltà: timestamp, organizzazione, progetto, identità dell'attore, tipo di attore, prefisso della chiave API, tipo di evento, entità, valore precedente, valore successivo, indirizzo IP, user agent e metadati.

Ogni esportazione CSV genera essa stessa una voce di audit di tipo audit_log.exported, registrando chi ha eseguito l'esportazione e quali filtri sono stati applicati. Questo chiude il ciclo di catena di custodia di cui i revisori della conformità chiedono conto: l'atto di estrarre le prove fa esso stesso parte delle prove.

Il registro di controllo è automaticamente attivo su tutte le organizzazioni Enterprise. Non è necessario alcun passaggio di configurazione, interruttore di attivazione o impostazione. I clienti Enterprise esistenti, incluso belo, il partner di lancio, dispongono di un registro popolato dal momento in cui la funzionalità è stata rilasciata, catturando l'attività da ogni dashboard, CLI e client MCP connesso all'organizzazione.

Le organizzazioni con il piano Pro o Business non hanno accesso al registro di controllo. L'aggiornamento a Enterprise attiva immediatamente il registro e inizia a catturare gli eventi dal momento dell'aggiornamento in poi; la conservazione storica precedente all'aggiornamento non è fornita. Contattare il team i1n per discutere i prezzi Enterprise per la vostra organizzazione.