Häufige Fehler bei Protokollierung und Aufbewahrung in SaaS-Teams

Die häufigsten Fehler bei Protokollierung und Aufbewahrung entstehen nicht durch zu wenige Daten. Sie entstehen, wenn SaaS-Teams nicht erklären können, was sie erfassen, warum sie es erfassen, wer die Daten kontrolliert, wie lange sie gespeichert werden oder welche konkrete Prüffrage sie beantworten. So entsteht teure Telemetrie, die Datenschutz- und Sicherheitsrisiken erhöht, ohne einen belastbaren KI-Prüfpfad zu liefern.

Für Hochrisiko-KI-Systeme verlangt Artikel 12 des EU AI Act technische Funktionen zur automatischen Aufzeichnung von Ereignissen über den Lebenszyklus. Nach den Artikeln 19 und 26 müssen Anbieter und Betreiber automatisch erzeugte Protokolle unter ihrer Kontrolle für einen dem Verwendungszweck angemessenen Zeitraum und grundsätzlich mindestens sechs Monate aufbewahren, sofern anderes Recht nichts anderes bestimmt. Daraus folgt weder, dass jede SaaS-Funktion hochriskant ist, noch dass jeder Prompt und jede Antwort gespeichert werden sollte.

Fehler 1: Mit der Plattform statt mit dem Geltungsbereich beginnen

Ein Logging-Produkt oder alle verfügbaren Ereignisse schaffen noch keinen klaren Geltungsbereich. Ein KI-gestützter SaaS-Ablauf kann Oberfläche, Retrieval, Geschäftsregeln, Drittmodell, menschliche Freigabe und nachgelagerte Automatisierung umfassen. Nur den Modell-API-Aufruf zu erfassen, lässt oft genau die Ereignisse aus, die das Ergebnis erklären.

Dokumentieren Sie Verwendungszweck, Nutzer, betroffene Personen, Ein- und Ausgaben, Integrationen, Versionen, Umgebungen und beeinflusste Entscheidungen. Bestimmen Sie dann Rolle und Einstufung des Unternehmens sowie Annahmen und Auslöser einer Neubewertung. Der EU-AI-Act-Leitfaden für SaaS-Anbieter erläutert den größeren Zusammenhang.

Fehler 2: Standardmäßig alles protokollieren

Vollständige Prompts, Dokumente, Ausgaben und Identitätsdaten können personenbezogene Daten, Kundengeheimnisse oder Zugangsdaten enthalten. Wahllose Erfassung vergrößert Zugriffs-, Vorfall- und Löschrisiken und erschwert zugleich die Suche nach relevanten Ereignissen.

Ordnen Sie jedes Feld einer Frage zu. Für die Zuordnung einer Ausgabe braucht es eine stabile System- und Release-Kennung. Für menschliche Aufsicht sind Anforderung, Handlung, Rollenbezug, Zeitpunkt und Ergebnis wichtig. Manchmal ist ein geschützter Inhaltsausschnitt erforderlich; häufig reichen Referenz, Hash, Kategorie oder strukturierte Zusammenfassung. Wenn niemand sagen kann, was ein Feld beweist, sollte es nicht allein wegen seiner Verfügbarkeit erfasst werden.

Fehler 3: Gewöhnliche Telemetrie als KI-Prüfpfad behandeln

Anwendungsprotokolle zeigen meist Verfügbarkeit, Latenz, Fehler und Serviceaktivität. Sie verbinden ein wesentliches Ergebnis aber nicht zwingend mit Modell, Konfiguration, Retrieval-Quelle, Kontrollresultat, menschlicher Handlung oder Release.

Ein nützlicher Prüfpfad korreliert Ereignisse über den gesamten Ablauf. Je nach Risiko gehören dazu System- und Komponentenversion, Zeitstempel, Transaktionskennung, Betriebskontext, Ein- und Ausgabereferenz, angewandte Kontrollen, Warnungen, menschliche Prüfung, nachgelagerte Handlung und Vorfallstatus. Auch Schemadokumentation, konsistente Uhren und eindeutige Kennungen sind nötig. Ein unabhängiger Prüfer sollte ein ausgewähltes Ereignis rekonstruieren können.

Fehler 4: Sechs Monate auf alle Datensätze anwenden

Die Sechsmonatsvorgabe betrifft automatisch erzeugte Protokolle von Hochrisiko-Systemen unter Kontrolle des jeweiligen Anbieters oder Betreibers. Sie ist weder eine allgemeine Aufbewahrungsfrist noch eine pauschale Erlaubnis zur unbegrenzten Speicherung personenbezogener Protokolldaten.

Ein Plan sollte Datensatzklasse, Startzeitpunkt, Löschdatum, Zweck, Ausnahmen, Freigabestelle sowie Replikate, Exporte und Backups abdecken. Stimmen Sie Rückverfolgbarkeit mit Datenminimierung, Speicherbegrenzung, Sicherheit, Branchenrecht, Arbeitsrecht und Verträgen ab. Testen Sie die tatsächliche Löschung auch außerhalb des primären Dashboards.

Fehler 5: Kontrollgrenzen ignorieren

Anbieter, Betreiber, Kunden und vorgelagerte Lieferanten können unterschiedliche Teile der Nachweiskette kontrollieren. Ein Anbieter kann keine Kundendaten aufbewahren, die er nie erhält; ein Betreiber darf nicht annehmen, dass der Modellanbieter Anwendungskontext oder menschliche Entscheidungen speichert.

Ordnen Sie jedes benötigte Ereignis der kontrollierenden Partei und dem System zu. Verträge und technische Dokumentation sollten Erstellung, Zugriff, Nachweisanfragen, Aufbewahrung und Vertragsende regeln. Prüfen Sie die tatsächliche Konfiguration. Nutzen Sie dazu die Fragen vor Einführung interner KI-Tools und stimmen Sie Kundenantworten mit den von Käufern erwarteten KI-Kontrollen ab.

Fehler 6: Verantwortung nur voraussetzen

Produkt, Engineering, Security, Datenschutz, Recht, Compliance und Operations tragen verschiedene Fakten und Kontrollen bei. Benennen Sie einen verantwortlichen Owner für den Gesamtprozess und klare Mitwirkende. Produkt verantwortet Zweck und Ablauf, Engineering Instrumentierung und Schemaqualität, Security Zugriff und Integrität, Datenschutz die angemessene Datenverarbeitung und Compliance Anforderungszuordnung sowie Prüfstandard.

Regeln Sie auch den Betrieb: Wer prüft Ausnahmen, genehmigt Zugriffe, beantwortet Nachweisanfragen, verlängert Aufbewahrung, ordnet Holds an, testet Löschung und behebt Lücken?

Fehler 7: Den Prüfpfad unzureichend schützen

Protokolle können Nutzeraktivität, interne Entscheidungen, Kundendaten und Systemschwächen offenlegen. Breiter Entwicklerzugriff, gemeinsame Konten und unkontrollierte Exporte gefährden Vertraulichkeit und Beweiswert.

Nutzen Sie geringstmögliche Rechte, starke Authentifizierung, Verschlüsselung, Zugriffsprotokolle, getrennte Umgebungen und Exportkontrollen. Schützen Sie Integrität durch kontrollierte Schemata, zuverlässige Zeitstempel, nachvollziehbare Transformationen und geregelte Beweissicherung. Trennen Sie Routinezugriff von privilegiertem Untersuchungszugriff.

Fehler 8: Rekonstruktion nie testen

Wählen Sie ein wesentliches Ereignis und lassen Sie einen unabhängigen Prüfer Systemversion, Ein- und Ausgabekontext, Kontrollen, menschliche Handlung, Folgeergebnis und Nachbearbeitung ermitteln. Dokumentieren Sie Lücken und weisen Sie Maßnahmen zu.

Wiederholen Sie den Test nach Änderungen an Modell, Prompt, Retrieval, Schwellenwert, Integration, Aufsicht oder Verwendungszweck sowie nach Beschwerden und Vorfällen. Damit unterstützen Sie die Entwicklung, die im Beitrag über veränderte AI-Governance-Erwartungen beschrieben wird: Prüfer wollen operative Nachweise, nicht nur Richtlinien.

Praktischer Korrekturprozess

Beginnen Sie mit einem wichtigen KI-Ablauf. Dokumentieren Sie Grenze, Zweck, Rolle, Einstufung, Ereignisquellen, Anbieter und Owner. Listen Sie wahrscheinliche Fragen von Kunden, Prüfern oder Incident Response auf und ordnen Sie ihnen minimale zuverlässige Ereignisse zu. Prüfen Sie jedes Feld auf Notwendigkeit, Sensitivität, Zugriff, Integrität, Aufbewahrung und Löschung. Führen Sie anschließend einen Rekonstruktions- und einen Löschtest durch und speichern Sie Ergebnisse, Lücken, Verantwortliche und Fristen zusammen.

Nach dem aktuellen Zeitplan der Europäischen Kommission gelten die Hochrisiko-Regeln für Systeme aus Anhang III ab 2. Dezember 2027 und für KI in regulierten Produkten aus Anhang I ab 2. August 2028. Teams sollten diese Vorbereitungszeit nutzen, um ihre Nachweisarchitektur zu testen.

FAQ

Was ist der größte Logging-Fehler?

Ereignisse ohne definierte Systemgrenze und Prüffragen zu sammeln. Das erzeugt Volumen ohne zuverlässige Rückverfolgbarkeit.

Benötigen alle SaaS-KI-Funktionen AI-Act-Protokolle?

Nein. Die hier behandelten Artikel 12, 19 und 26 betreffen Hochrisiko-KI-Systeme und hängen von Rolle und Kontrolle ab. Andere Gesetze, Verträge oder interne Kontrollen können trotzdem Aufzeichnungen erfordern.

Muss jeder Prompt gespeichert werden?

Nein. Wählen Sie angemessene Felder für definierte Überwachungs- und Untersuchungszwecke. Referenzen, Hashes, Kategorien oder geschützte Ausschnitte können genügen.

Was sollte zuerst dokumentiert werden?

Systemgrenze, Zweck, Rolle, Einstufung, kontrollierte Quellen, Prüffragen, minimales Schema, Owner, Zugriffsregeln und Aufbewahrungsplan.

Wie lässt sich die Nutzbarkeit prüfen?

Lassen Sie ein wesentliches Ereignis unabhängig rekonstruieren und testen Sie die Löschung abgelaufener Datensätze in allen Kopien.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 6, 12, 19 und 26.
• Verordnung (EU) 2026/1744 zu den geänderten Anwendungsdaten.
• Europäische Kommission, „AI Act“, zum aktuellen Umsetzungszeitplan.