Protokollierung und Aufbewahrung: Praxisleitfaden für SaaS-Teams

Protokollierung und Aufbewahrung sind nach dem EU AI Act Kontrollen für Rückverfolgbarkeit, keine Aufforderung, jeden denkbaren Datenpunkt unbegrenzt zu sammeln. Für Hochrisiko-KI-Systeme verlangt Artikel 12, dass das System während seines gesamten Lebenszyklus technisch eine automatische Aufzeichnung von Ereignissen ermöglicht. Anbieter und Betreiber müssen automatisch erzeugte Protokolle unter ihrer Kontrolle für einen dem Verwendungszweck angemessenen Zeitraum und grundsätzlich mindestens sechs Monate aufbewahren, sofern anderes anwendbares Recht nichts anderes bestimmt.

Diese Pflichten gelten nicht automatisch für jedes KI-Merkmal oder jedes SaaS-Unternehmen. Ein Team muss zuerst das KI-System, seinen Verwendungszweck, die eigene Rolle und die Hochrisiko-Einstufung bestimmen. Es muss außerdem zwischen Protokollen unter Kontrolle des Anbieters und Unterlagen unterscheiden, die ein Kunde oder vorgeschalteter Lieferant kontrolliert. Nach der Abgrenzung besteht das praktische Ziel in einer angemessenen Nachweiskette: Ein berechtigter Prüfer sollte ein wesentliches Ereignis mit Systemversion, Ein- und Ausgabekontext, menschlicher Handlung, Kontrolle und Entscheidung verbinden können.

Auch wenn die Hochrisiko-Vorschriften noch nicht gelten, unterstützt dieselbe Disziplin Vorfalluntersuchungen, Sicherheitsüberwachung, Kundennachweise, Änderungsmanagement und belastbare Produktentscheidungen. Die Lösung ist keine wahllose Überwachung, sondern bewusste Protokollierung mit festgelegten Zwecken, Zugriffsregeln, Prüfauslösern und Aufbewahrungsgrenzen.

Mit dem Geltungsbereich beginnen, nicht mit einer Logging-Plattform

Dokumentieren Sie zuerst die Systemgrenze: Produktfunktion, beteiligte Modelle und Drittdienste, Verwendungszweck, Nutzer, betroffene Personen, Eingaben, Ausgaben, Integrationen, Umgebungen und beeinflusste Entscheidungen. Nur den Aufruf einer Foundation-Model-API zu protokollieren, kann Retrieval-Daten, Geschäftsregeln, Nutzerübersteuerungen oder nachgelagerte Handlungen ausblenden, die den vollständigen SaaS-Ablauf bestimmen.

Bestimmen Sie anschließend die Unternehmensrolle. Ein SaaS-Unternehmen, das ein Hochrisiko-KI-System unter eigenem Namen entwickelt oder vermarktet, kann Anbieter sein. Ein Kunde, der ein System eines anderen Anbieters nutzt, kann Betreiber sein. Rebranding, wesentliche Änderungen oder ein geänderter Verwendungszweck können Anbieterpflichten verlagern. Vertragsbegriffe allein entscheiden die rechtliche Einordnung nicht.

Bewerten Sie danach die Einstufung. Artikel 6 erfasst Hochrisiko-Systeme in Verbindung mit Produkten aus Anhang I und Anwendungsfälle aus Anhang III, jeweils unter den Bedingungen und Ausnahmen der Verordnung. Eine Funktion zur Rangfolge von Bewerbern verlangt eine andere Analyse als ein Werkzeug für interne Marketingtexte. Halten Sie Begründung, Prüfer, Datum, Annahmen und Neubewertungsauslöser fest.

Zum größeren Zusammenhang lesen Sie, wie AI Governance die Compliance-Erwartungen an SaaS-Anbieter verändert.

Was der AI Act für Hochrisiko-Systeme verlangt

Nach dem AI Act müssen Hochrisiko-KI-Systeme gemäß Artikel 12 die automatische Aufzeichnung von Ereignissen über ihren Lebenszyklus ermöglichen. Die Funktionen müssen eine dem Verwendungszweck angemessene Rückverfolgbarkeit unterstützen. Sie sollen insbesondere Risikosituationen oder wesentliche Änderungen erkennen helfen, die Beobachtung nach dem Inverkehrbringen unterstützen und Betreibern die Überwachung des Betriebs ermöglichen.

Welche Ereignisse erforderlich sind, hängt vom System ab. Für bestimmte biometrische Fernidentifizierungssysteme aus Anhang III nennt Artikel 12 zusätzliche Mindestangaben. Teams sollten dieses Spezial-Schema nicht auf ein sachfremdes Produkt übertragen und Compliance annehmen. Sie sollten Ereignisse aus Verwendungszweck, Risiken, Leistungsgrenzen, menschlicher Aufsicht, Gebrauchsanweisung und Beobachtungsplan ableiten.

Artikel 19 verpflichtet Anbieter, automatisch erzeugte Protokolle unter ihrer Kontrolle für einen angemessenen Zeitraum von mindestens sechs Monaten aufzubewahren, sofern anwendbares Unions- oder nationales Recht, insbesondere Datenschutzrecht, nichts anderes vorsieht. Artikel 26 enthält eine parallele Mindestdauer für Betreiber. „Mindestens sechs Monate“ ist daher keine pauschale Erlaubnis, sämtliche personenbezogenen Protokolldaten unbegrenzt zu speichern. Ein belastbarer Plan muss Rückverfolgbarkeit mit Datenminimierung, Speicherbegrenzung, Sicherheit, Arbeitsrecht, Sektorvorgaben, Verträgen und Vorfallbedarf vereinbaren.

Nach der Verordnung (EU) 2026/1744 gelten diese Hochrisiko-Anforderungen ab 2. Dezember 2027 für Systeme aus Anhang III und ab 2. August 2028 für Hochrisiko-Systeme in regulierten Produkten aus Anhang I. Der Zeitplan der Europäischen Kommission enthält diese geänderten Daten. Teams können die Übergangszeit nutzen, um die Nachweisarchitektur zu testen, statt Unterlagen kurz vor einem Release oder einer Prüfung rückwirkend aufzubauen.

Was aufgezeichnet werden sollte

Ein nützlicher Ereignisdatensatz sollte eine Prüffrage beantworten und nicht nur belegen, dass ein Server lief. Je nach Risiko und Architektur können erforderlich sein:

1. System und Version: stabile Kennung, Modell- oder Komponentenversion, Konfiguration, Umgebung und Release-Kennung.
2. Zeit und Korrelation: verlässlicher Zeitstempel, Anfrage- oder Transaktionskennung sowie Verknüpfungen vor- und nachgelagerter Ereignisse.
3. Betriebskontext: Funktion, vorgesehener Ablauf, Nutzer- oder Servicerolle und wesentliche Einstellungen ohne unnötige Inhalte.
4. Ein- und Ausgabespur: Referenzen, Hashes, strukturierte Zusammenfassungen oder geschützte Momentaufnahmen, soweit eine Rekonstruktion gerechtfertigt ist.
5. Menschliche Aufsicht: Prüfung, Freigabe, Ablehnung, Übersteuerung, Eskalation und Befugnis der handelnden Rolle.
6. Kontrollen und Ergebnisse: Richtlinienprüfungen, Schwellenwerte, Filter, Zugriffsentscheidungen, Fehler, Fallbacks und Erfolg oder Fehlschlag der Kontrolle.
7. Änderung und Überwachung: Deployments, Modell- oder Datenänderungen, Drift-Alarme, Ausnahmen, Vorfälle, Beschwerden und Korrekturen.
8. Nachweisintegrität: Quelle, Zugriffshistorie, Aufbewahrungsstatus sowie Transformation oder Löschung.

Speichern Sie nicht automatisch vollständige Prompts, hochgeladene Dokumente, Modellantworten oder Identitätsdaten. Manchmal ist Inhalt zur Untersuchung eines schädlichen Ergebnisses nötig; andernfalls reichen eine pseudonyme Kennung, ein Hash, eine Kategorie, eine Kennzahl oder ein kurzes geschütztes Beispiel. Entscheiden Sie feldweise anhand dokumentierter Zwecke und Risiken.

Praktischer Betriebsablauf

1. Protokollierungsentscheidung erstellen

Halten Sie je System Grenze, Zweck, Rolle, Einstufung, Pflichten, Überwachungsziele, Datenkategorien und Nachweisverantwortliche fest. Identifizieren Sie eigene sowie von Lieferanten oder Kunden abhängige Protokolle. Dokumentieren Sie offene Annahmen und Prüfauslöser.

2. Fragen auf Ereignisse abbilden

Beginnen Sie mit Fragen: Welche Version erzeugte dieses Ergebnis? War eine menschliche Prüfung nötig und abgeschlossen? Wurde eine Kontrolle ausgelöst? Entsprach die Nutzung dem Zweck? Was änderte sich vor einer Leistungsverschlechterung? Ordnen Sie jeder Frage die kleinsten verlässlichen Felder und deren Quelle zu.

3. Verantwortung über den Lebenszyklus verteilen

Engineering verantwortet meist Instrumentierung und Ereignisqualität, Security Zugriff, Integrität, Alarmierung und Beweissicherung, Product den vorgesehenen Ablauf und Releases, Daten- oder ML-Teams Modell-, Datensatz- und Evaluationskennungen, Privacy die rechtmäßige und sparsame Verarbeitung und Compliance die Anforderungszuordnung. Eine accountable Person koordiniert, ohne Fakten anderer Teams zu erfinden.

4. Zugriff und Aufbewahrung festlegen

Trennen Sie betrieblichen von Untersuchungszugriff. Nutzen Sie Minimalrechte, Authentifizierung, Zugriffsprotokolle, Verschlüsselung und Exportkontrollen. Definieren Sie Fristbeginn, reguläre Löschung, Ausnahmen, Freigaben für Holds und die Behandlung von Backups. Weichen Anbieter- und Betreiberunterlagen voneinander ab, müssen Zuständigkeiten und rechtmäßige Anfragen geregelt sein.

5. Prüfung mit Betriebsauslösern verbinden

Warten Sie nicht auf den nächsten Compliance-Termin. Prüfen Sie nach wesentlichen Änderungen an Modell, Prompt, Retrieval, Schwellenwert, Datenquelle, Integration, Zweck oder Aufsicht. Vorfälle, Beschwerden, unerwartete Leistung, unbefugte Nutzung und Lieferantenhinweise sollten Entscheidungen ebenfalls neu öffnen. Verknüpfen Sie das Ergebnis mit der produktiven Version.

6. Rekonstruktion und Löschung testen

Lassen Sie einen unabhängigen Prüfer bei einem wesentlichen Ereignis Version, Kontrollresultate, menschliche Handlungen und Folgemaßnahmen rekonstruieren. Testen Sie anschließend, ob abgelaufene Datensätze tatsächlich aus Primärspeicher, Analytikkopie, Exporten und Backups entfernt werden. Rückverfolgbarkeit und Löschung benötigen beide Nachweise.

Häufige Fehler

Alles standardmäßig protokollieren. Mehr Daten können Datenschutz-, Sicherheits-, Verfahrens- und Kostenrisiken schaffen, ohne die Rückverfolgbarkeit zu verbessern.

Anwendungstelemetrie mit einem KI-Audit-Trail verwechseln. Verfügbarkeit und Fehlerraten identifizieren selten Modell, Konfiguration, Aufsicht und Nachweis hinter einem wesentlichen Ergebnis.

Sechs Monate auf jeden Datensatz anwenden. Die Mindestdauer betrifft automatisch erzeugte Hochrisiko-Protokolle unter Kontrolle des Operators und bleibt anderem Recht unterworfen.

Kontrollgrenzen ignorieren. Ein Anbieter kann nie empfangene Betreiberprotokolle nicht aufbewahren; ein Betreiber darf nicht annehmen, dass ein Lieferant seinen Überwachungskontext sichert.

Sensible Inhalte ohne Schutz sammeln. Prompts und Ausgaben können personenbezogene, vertrauliche oder kundeneigene Daten enthalten. Minimieren, trennen, verschlüsseln und überwachen Sie den Zugriff.

Nicht interpretierbare Datensätze behalten. Ein Ereigniscode ohne Schema, Zeitsynchronisierung, Version oder Korrelationskennung kann im Review wertlos sein.

Beispiel: KI-gestützte Bewerberauswahl

Ein SaaS-Anbieter bietet eine Funktion, die Bewerbungen für Recruiter sortiert. Das Team dokumentiert Verwendungszweck, Systemgrenze, Anbieterrolle und Hochrisiko-Einstufung. Das Ereignisdesign verbindet das produktive Modell und seine Konfiguration mit jedem Ranking-Lauf, maßgeblichen Eingabereferenzen, Ergebnis und Konfidenzkontext, Schwellenwerten, Warnungen, menschlicher Prüfung, Übersteuerung und abschließender Aktion.

Zugriff auf inhaltliche Datensätze ist auf berechtigte Untersuchungen begrenzt. Die Routineüberwachung nutzt möglichst aggregierte Leistungs- und Ausnahmedaten. Die Aufbewahrungsentscheidung erläutert Artikel 19, Datenschutzgrenzen, Kundenpflichten und gegebenenfalls längere sektorale Fristen. Änderungen an Modell, Ranking-Schwelle oder Prüfablauf lösen eine Folgenbewertung aus und erhalten die Verbindung zwischen alten und neuen Nachweisen.

Das Design garantiert allein keine Compliance. Es ermöglicht aber zu prüfen, ob das System wie dokumentiert arbeitete, Menschen die vorgesehene Aufsicht ausübten und Änderungen oder Vorfälle verantwortet behandelt wurden.

FAQ

Was ist der praktische Zweck von Protokollierung und Aufbewahrung?

Wesentliche Aktivitäten sollen rückverfolgbar sein. Ein sinnvoller Datensatz verbindet ein Ereignis mit Systemversion, Betriebskontext, Kontrollen, menschlichen Handlungen und Folgemaßnahmen, ohne sachfremde Daten zu sammeln.

Wann gelten die Protokollierungspflichten für SaaS-Teams?

Artikel 12, 19 und 26 betreffen Hochrisiko-KI-Systeme und ordnen Anforderungen nach Rolle und Kontrolle zu. Klären Sie System, Zweck, Einstufung und Anbieter- oder Betreiberrolle.

Müssen jeder Prompt und jede Antwort gespeichert werden?

Nein. Gefordert ist angemessene Rückverfolgbarkeit, keine wahllose Inhaltsspeicherung. Wählen Sie Felder für definierte Überwachungs- und Untersuchungszwecke und wenden Sie Datenschutz- und Sicherheitskontrollen an.

Wie lange sind Protokolle aufzubewahren?

Automatisch erzeugte Protokolle von Hochrisiko-Systemen unter Kontrolle von Anbieter oder Betreiber sind grundsätzlich für einen angemessenen Zeitraum von mindestens sechs Monaten aufzubewahren. Anderes Recht kann eine andere Dauer verlangen oder begrenzen.

Was sollte ein Team zuerst tun?

Erfassen Sie System, Rolle, Einstufung, kontrollierte Quellen und Prüffragen. Definieren Sie dann minimales Ereignisschema, Zuständigkeit, Zugriff, Aufbewahrung, Änderungsauslöser und Rekonstruktionstest.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 6, 12, 19 und 26.
• Verordnung (EU) 2026/1744 mit den geänderten Anwendungsdaten für Hochrisiko-Anforderungen.
• Europäische Kommission, „AI Act“, zum aktuellen Zeitplan und Überblick über Hochrisiko-Pflichten.