Audit-Protokoll

Das Audit-Protokoll von i1n erfasst jede Mutation in einer Organisation – nicht als grobe Zeile „Übersetzungsdatei aktualisiert“, sondern als strukturiertes Ereignis pro Schlüssel und pro Sprache. Wenn ein Dashboard-Benutzer die spanische (es_mx) Übersetzung von errors.insufficient_funds um 14:32 UTC ändert, erfasst das Protokoll den genauen Wert davor, den genauen Wert danach, die Identität des Akteurs, den Zeitstempel, die IP-Adresse und den User-Agent der Anfrage, die die Änderung vorgenommen hat.

Die Abdeckung erstreckt sich über die gesamte Plattform: Erstellung, Bearbeitung und Löschung von Übersetzungen; Erstellung, Umbenennung und Entfernung von Namespaces; Projekt-Einstellungen und Änderungen der Markenstimme; Einladungen, Rollenänderungen und Entfernungen von Teams; Erstellung, Rotation, Bereichsänderungen und Löschung von API-Schlüsseln; Änderungen des Abrechnungsplans, Abonnement-Ereignisse und BYOK-Aktivierung.

Massenoperationen wie i1n-Push erzeugen für jedes geänderte Schlüssel-Sprache-Paar ein Ereignis anstelle einer einzigen groben Zusammenfassung, mit einer gemeinsamen Batch-Kennung in den Metadaten. Ein Push, der 200 Schlüssel in vier Sprachen aktualisiert, erzeugt 800 einzeln adressierbare Audit-Einträge, jeder mit seinem eigenen Diff. Prüfer können daher bis auf die exakte Zeichenfolge antworten: 'Was hat sich am 17. April um 14:32 Uhr geändert?'.

Ereignisse werden von PostgreSQL-Triggern ausgelöst, die an jede geprüfte Tabelle angehängt sind. Es gibt keinen Schreibpfad auf Anwendungsebene, der das Protokoll umgeht — jede erfolgreiche Mutation generiert ihre Audit-Zeile innerhalb derselben Datenbanktransaktion. Eine Änderung, die ohne eine entsprechende Audit-Zeile committet wird, ist konstruktionsbedingt nicht möglich.

Jeder Audit-Eintrag wird einem von fünf Akteurtypen zugeordnet: user für Dashboard-Mutationen, cli für direkte Befehlszeilenoperationen, mcp für Änderungen, die von einem KI-Agenten über den i1n MCP-Server vorgenommen wurden, webhook für Ereignisse, die von externen Systemen wie dem Abrechnungsanbieter stammen, und system für plattforminterne Aufgaben wie die Bereinigung der Aufbewahrung.

Die Zuordnung von Dashboard-Benutzern ist kryptografisch. Der Akteur-Identifikator ist die Konto-ID des authentifizierten Benutzers, zusammen mit seiner verifizierten E-Mail-Adresse und seinem Namen aus der Liste der Organisationsmitglieder. Administratoren, die das Protokoll überprüfen, sehen echte menschliche Identitäten, keine undurchsichtigen UUIDs.

Die CLI- und MCP-Zuordnung ist kryptografisch an den verwendeten API-Schlüssel gebunden, wobei das Schlüsselpräfix für forensische Korrelationen aufgezeichnet wird. Hinweise aus der Git-Konfiguration des Entwicklers – E-Mail und vollständiger Name – werden ebenfalls erfasst, aber im Dashboard explizit als „nicht verifiziert“ gekennzeichnet. Diese ehrliche Trennung zwischen kryptografischer Identität und selbst gemeldeten Metadaten ist das, was Compliance-Prüfer von einem ausgereiften Auditsystem erwarten.

Die Beobachtbarkeit von KI-Agenten ist unseres Wissens nach einzigartig für i1n. Jede von Claude Code, Cursor oder einem anderen mit dem i1n MCP-Server verbundenen Client vorgenommene Übersetzungsänderung wird mit actor_type = 'mcp' gekennzeichnet. Organisationen können das Audit-Protokoll filtern, um die Frage zu beantworten: „Welche Übersetzungen wurden zuletzt von einem KI-Agenten im Gegensatz zu einem menschlichen Prüfer geändert?“ – eine Frage, die auf keiner anderen Lokalisierungsplattform eine klare Antwort hat.

Da KI-Agenten mehr vom Lokalisierungsworkflow übernehmen, wird die Fähigkeit, sie als Akteure erster Klasse zu auditieren, zu einer Beschaffungsanforderung. Der Filter für den Akteurtyp ist ein Klick im Dashboard und ein Abfrageparameter im CSV-Export.

Das Auditprotokoll ist auf Datenbankebene nur zum Anhängen bestimmt. Trigger geben Zeilen aus; es wird kein INSERT-Pfad für Clients bereitgestellt, und es gibt keine UPDATE- oder DELETE-Richtlinien für die Tabelle. Mitglieder einer Organisation können ihre eigene Historie nicht bearbeiten. i1n-Betriebspersonal kann ebenfalls keine Einträge bearbeiten oder löschen – die Tabelle ist auf Schemaebene geschützt, nicht auf Anwendungsebene.

Die Aufbewahrungsfrist beträgt 365 Tage und entspricht der SOC 2-Kontrollbasislinie für Aktivitätsprotokolle. Datensätze, die älter als 365 Tage sind, werden durch einen geplanten Job entfernt, der selbst einen Audit-Eintrag ausgibt – jede Löschung ist nachvollziehbar. Organisationen, die für eine spezifische behördliche Überprüfung längere Zeiträume benötigen, können eine Verlängerung auf Vertragsebene beantragen.

Das Protokoll zeigt die Datenpunkte an, die Compliance-Prüfer typischerweise anfordern: wer, was, wann, wo (IP-Adresse), wie (Benutzer-Agent) und was sich geändert hat (vorherige und nachfolgende Werte, vollständig). Für Organisationen, die der DSGVO-Artikel 30 zur Aufzeichnungspflicht unterliegen, oder für Fintech-Regulierungsbehörden, die eine Nachverfolgbarkeit von benutzerorientierten Inhalten verlangen, ist der Export als primärer Nachweis ausreichend.

i1n veröffentlicht derzeit keinen SOC 2 Type II-Bericht auf Plattformebene. Das Audit-Protokoll ist die zugrunde liegende Kontrolle, die das eigene SOC 2-, GDPR- oder Fintech-Compliance-Programm eines Kunden unterstützt – es ersetzt keine organisatorischen Kontrollen, aber es beseitigt die häufigste Hürde bei Compliance-Prüfungen, nämlich das Fehlen einer nachprüfbaren Spur von Inhaltsänderungen.

Lesezugriff auf das Audit-Protokoll ist auf Organisationsinhaber und Administratoren beschränkt. Redakteure und Betrachter sehen den Audit-Protokoll-Tab im Dashboard nicht und können ihn nicht über die API abfragen. Diese Trennung wird durch die PostgreSQL Row-Level Security erzwungen, nicht durch clientseitiges Ausblenden – es gibt keinen Weg, das Protokoll von einer nicht privilegierten Rolle aus zu lesen.

Editoren und Betrachter unterliegen weiterhin vollständig dem Audit-Log. Jede Aktion, die sie auf der Plattform ausführen – Übersetzungsbearbeitungen, Anfragen für KI-Übersetzungen, Vorgänge auf Mitgliederebene – wird mit ihrer Identität aufgezeichnet und ist für das Admin-Team sichtbar. Die auditierten Personen können sich nicht aus dem Audit entfernen.

Besitzer und Administratoren können keine historischen Einträge bearbeiten. Die Frage „Wer darf lesen?“ und die Frage „Wer darf ändern?“ haben bewusst unterschiedliche Antworten – Lesen ist auf Administratorenebene, Ändern ist für niemanden. Dies erfüllt die Erwartungen an die Aufgabentrennung, die Prüfer bei der Überprüfung interner Zugriffskontrollen anwenden.

Der API-Zugriff spiegelt das Dashboard-Modell wider. Das Audit-Protokoll wird über dieselben zeilenbasierten Sicherheitsrichtlinien bereitgestellt, die auch das Dashboard steuern. Daher erbt jedes Dienstkonto oder Integrationstoken, das zum Abfragen des Protokolls verwendet wird, automatisch dieselben Einschränkungen.

Auditprotokolldaten können vom Dashboard mit einer Ein-Klick-Aktion als CSV exportiert werden. Der Export umfasst jeden ausgewählten Zeitraum und berücksichtigt die aktiven Filter — Akteurtyp, Ereignistyp, Projekt und Suchbegriff —, sodass Prüfern ein enger Ausschnitt anstelle der gesamten Historie übergeben werden kann. Die CSV behält die volle Detailtreue bei: Zeitstempel, Organisation, Projekt, Akteuridentität, Akteurtyp, API-Schlüsselpräfix, Ereignistyp, Entität, vorheriger Wert, nachfolgender Wert, IP-Adresse, User-Agent und Metadaten.

Jeder CSV-Export generiert selbst einen Audit-Eintrag vom Typ audit_log.exported, der aufzeichnet, wer den Export durchgeführt hat und welche Filter angewendet wurden. Dies schließt den Chain-of-Custody-Kreislauf, nach dem Compliance-Prüfer fragen – die Handlung des Ziehens von Beweismitteln ist selbst Teil der Beweismittel.

Das Audit-Protokoll ist in allen Enterprise-Organisationen automatisch aktiv. Es gibt keinen Konfigurationsschritt, keinen Opt-in-Schalter und keine Einrichtung ist erforderlich. Bestehende Enterprise-Kunden, einschließlich belo, dem Launch-Partner, haben ab dem Zeitpunkt, an dem die Funktion ausgeliefert wurde, ein gefülltes Protokoll, das die Aktivität von jedem Dashboard, CLI und MCP-Client, der mit der Organisation verbunden ist, erfasst.

Organisationen mit einem Pro- oder Business-Tarif haben keinen Zugriff auf das Audit-Protokoll. Ein Upgrade auf Enterprise aktiviert das Protokoll sofort und beginnt mit der Erfassung von Ereignissen ab dem Zeitpunkt des Upgrades; eine historische Aufbewahrung vor dem Upgrade wird nicht bereitgestellt. Kontaktieren Sie das i1n-Team, um die Enterprise-Preise für Ihre Organisation zu besprechen.