Sichern Sie die für eine KI-Vorfallsuntersuchung benötigten Nachweise, ohne Schutzmaßnahmen zu verzögern. Erproben Sie zwei parallele Abläufe: die betroffene Fähigkeit begrenzen und einen minimalen, integritätsgeprüften Datensatz zu Release, Eingaben, Aufsicht und Reaktionsmaßnahmen sichern. Ein erfolgreicher Export genügt nicht: Eine andere berechtigte Untersuchungsperson muss ihn öffnen, veränderte Artefakte erkennen und fehlende Informationen erklären können.
Dies ist eine technische Übung, keine Rechtsberatung und kein Standard für die gerichtliche Verwertbarkeit. Die Rechtsberatung muss Akteur, Systemklassifikation, anwendbares geändertes Recht, Meldeempfänger und Fristen sowie datenschutz- oder arbeitsrechtliche Grenzen bestimmen. Das folgende Beispiel verwendet ausschließlich synthetische Datensätze. Es belegt weder Rechtskonformität noch die Rekonstruktion eines Produktionsvorfalls.
Das ungeübte Risiko: Die Erklärung wird weggepatcht
Stellen Sie sich vor, ein Serviceassistent zitiert eine zurückgezogene Wartungsanweisung. Eine Bedienperson meldet das Problem; das Team aktualisiert den Retrieval-Index und ändert den Prompt. Die nächste Antwort verbessert sich, aber die alte Dokumentrevision, das Retrieval-Ergebnis und die damalige Prüfansicht sind verschwunden. Die Korrektur reduziert die Gefährdung, schwächt jedoch die Untersuchung.
Die Entscheidung lautet nicht, eine unsichere Funktion zur Beweissicherung weiterzubetreiben. Deaktivieren Sie nötigenfalls den betroffenen Aktionspfad oder nutzen Sie einen freigegebenen Ersatzbetrieb. Protokollieren Sie die Zustandsänderung und sammeln Sie sicher erreichbare Nachweise. Führen Sie einen mutmaßlich unsicheren Werkzeugaufruf nicht nur zur Rekonstruktion seiner Spur erneut aus. Jede Wiederholung gehört in ein separates, isoliertes Experiment ohne Produktionszugänge.
Der vorhandene Beitrag zum Post-Market-Risikofeedback behandelt den übergeordneten Ablauf vom Schadenssignal zur Änderung. Hier geht es um die engere Sicherungsgrenze: Was übersteht die Eindämmung, wer kann es lesen und wie erkennt ein Prüfer Inkonsistenzen? Eine Sicherungsübung klassifiziert den Vorfall nicht und legt keine Rechtsfrist fest.
Was die Quellen tragen – und was nicht
NIST SP 800-61r3, insbesondere RS.AN-06 und RS.AN-07, unterstützt die Aufzeichnung von Untersuchungshandlungen und die Sicherung von Integrität und Herkunft der Vorfallsdaten unter Berücksichtigung von Vertraulichkeit und berechtigtem Zugriff. Es handelt sich um Cybersicherheitsleitlinien: Nutzen Sie sie als technische Analogie, nicht als unionsrechtlichen Maßstab für einen KI-Vorfall.
Die ursprüngliche Amtsblattfassung des AI Act trennt die Meldung schwerwiegender Vorfälle bei Hochrisiko-Systemen in Artikel 73 vom Rahmen für Anbieter von GPAI-Modellen mit systemischem Risiko in Artikel 55. Diese Meldewege sind nicht austauschbar. Die ursprüngliche Veröffentlichung belegt hier diese strukturelle Unterscheidung, nicht aktuelle Anwendungsdaten oder geänderte Pflichten. Dafür muss die Rechtsberatung die aktuell einschlägigen Rechtsakte prüfen.
Die Konsultationsseite der Kommission zu schwerwiegenden KI-Vorfällen bezeichnet die Hochrisiko-Leitlinien und Meldevorlage ausdrücklich als Entwurf. Konsultationsmaterial ist kein verbindliches endgültiges Recht. Übernehmen Sie den historischen Zeitplan nicht in einen operativen Fristenrechner. Keine dieser Quellen macht eine Hash-Liste zu einer vollständigen oder wahrheitsgetreuen Darstellung eines Vorfalls.
Eindämmung und Sicherung getrennt entscheiden
| Situation | Schutzmaßnahme | Sicherungsmaßnahme | Grenze |
|---|---|---|---|
| Möglicher fortdauernder Schaden | Betroffene Fähigkeit deaktivieren oder freigegebenen Ersatz nutzen | Verfügbaren Zustand und Eingriff dokumentieren | Nicht auf den perfekten Export warten |
| Prompt oder Index steht vor einer Änderung | Nicht notwendige Änderungen soweit sicher pausieren | Exakte Revisionen und wirksame Konfiguration sichern | Modellname fixiert nicht das gesamte Release |
| Sensible Beschwerde oder Aufsichtsaufzeichnung | Zugriff beschränken und Verantwortliche einbinden | Notwendige Originale von redigierten Kopien trennen | Keine Rohdaten in allgemeine Chatwerkzeuge geben |
| Interner Anbieterzustand nicht verfügbar | Eigene kontrollierbare Komponenten begrenzen | Anfrage-IDs sichern und Lieferantennachweise anfordern | Fehlende Daten dokumentieren statt erfinden |
| Snapshot würde Störung verschärfen | Sichere Betriebsreaktion priorisieren | Begrenzte Metadaten exportieren und Ausfall dokumentieren | Auch die Erhebung kann den Betrieb beeinflussen |
Benennen Sie vor der Übung eine Einsatzleitung, eine für die Nachweissicherung verantwortliche Person und eine rechtliche Eskalationsstelle. In kleinen Teams können Personen mehrere Rollen übernehmen; die Entscheidungen müssen trotzdem unterscheidbar bleiben. Die Nachweisverantwortlichen dokumentieren Umfang, Erhebungsmethode, Zugriffsfreigaben und Übergaben. Die Einsatzleitung verantwortet Schutzmaßnahmen. Die Rechtsberatung bewertet Melde- und Sicherungsgrenzen, statt die rechtliche Einstufung einem Skript zu überlassen.
Ein minimales Manifest statt eines zweiten Datensees
Beginnen Sie mit dem LLM-Release-Bundle und ergänzen Sie vorfallsbezogene Herkunftsnachweise. Ein Deployment-Manifest allein erklärt weder die tatsächlich angezeigten Retrieval-Belege noch den Eingriff nach der Beschwerde.
Halten Sie pro Artefakt einen relativen Pfad oder eine unveränderliche Objektversion, Bytezahl, SHA-256-Prüfsumme, Quellreferenz, Erhebungsidentität, Methode und Zeitstempel fest. Schützen Sie das Manifest über eine gesondert kontrollierte Integritätsgrenze: einen unabhängig aufbewahrten Hash, eine signierte Bestätigung oder einen geeignet verwalteten unveränderlichen Datensatz. Kann ein Angreifer Artefakt und erwarteten Hash gemeinsam ersetzen, erkennt ein gewöhnlicher lokaler Vergleich den Austausch nicht.
Unser synthetischer Testfall verwendet synthetic-17 und ein Release-Tupel aus Modell local-fixture-v1, Prompt p7, Retrieval index-42, Policy pol3, Werkzeugen t2 und Aufsicht reviewer-policy-4. Die Quelle lautet synthetic://complaint/17. Die Beobachtung lautet „Die Ausgabe zitierte eine zurückgezogene Anweisung“; „Veraltetes Retrieval könnte das Zitat erklären“ bleibt eine getrennte Hypothese. Diese Trennung verhindert, dass eine frühe Erklärung zur vermeintlich bewiesenen Tatsache wird.
Der Datensatz enthält das Freigabeereignis synthetic-review-8, Ereignis-, Beobachtungs- und Erhebungszeit, eine Zeitunsicherheit von 500 Millisekunden, den Erhebungsakteur und einen Fehlvermerk: Der interne Anbieterzustand wird von der gehosteten API nicht offengelegt. Diese Werte sind bewusst erfundene Testdaten, keine Produktionsmessungen. Kennzeichnen Sie unbekannte Zeitunsicherheit als unbekannt, statt eine bequeme Zahl einzusetzen.
Sichern Sie die wirksame Konfiguration, nicht nur eine Git-Referenz: Routing, Feature-Flags, Retrieval-Snapshot, Zugriffsfilter, Promptrevision, Werkzeugschema und Aufsichtseinstellungen können das Verhalten verändern. Bevorzugen Sie begrenzte Exporte. Nehmen Sie niemals aktive Zugangsdaten auf; dokumentieren Sie gegebenenfalls Referenzen auf Secret-Versionen. Minimieren Sie personenbezogene Daten gemeinsam mit der Datenschutzverantwortung, ohne den notwendigen Untersuchungskontext ungeprüft zu entfernen.
Die Erhebungszeitleiste erproben
Bei T0 verweist die synthetische Ausgabe auf die zurückgezogene Anweisung. Bei T1 bemerkt eine Bedienperson dies. Bei T2 deaktiviert die Einsatzleitung den Aktionspfad. Bei T3 sichert die verantwortliche Person verbleibende Nachweise und dokumentiert den Eingriff einschließlich Akteur, Grund und betroffenem Release. Bei T4 prüft ein Verifikator das kopierte Paket. Dies ist eine beispielhafte Abfolge, keine gesetzliche Meldefrist und keine vorgeschriebene Wartezeit zwischen Eindämmung und Sicherung.
Führen Sie Ereigniszeit, Beobachtungszeit und Erhebungszeit getrennt. Bewahren Sie Zeitzone, Zeitquelle und bekannte Unsicherheit der relevanten Systeme auf. Ordnen Sie unsichere Zeitstempel nicht stillschweigend zu einer scheinbar präzisen Kausalkette. Dokumentieren Sie jede Untersuchungshandlung, auch fehlgeschlagene Exporte, Filter, Transformationen und Zugriffsänderungen. Ein fehlendes Artefakt benötigt eine verantwortliche Person und eine Erklärung, kein leeres Feld mit Vollständigkeitswirkung.
Integritätsprüfung: Einen Fehler tatsächlich erkennen
Die lokale Übung erzeugte einen synthetischen JSON-Datensatz und ein Manifest mit Bytezahl und SHA-256. Beide wurden in ein sauberes Prüfverzeichnis kopiert. Der Verifikator verglich zunächst das Manifest mit einer separat aufbewahrten erwarteten Prüfsumme, beschränkte Artefaktpfade auf das Paket, prüfte Existenz, Länge und Hash und las das JSON zur grundlegenden Lesbarkeitskontrolle ein. Die erwartete Prüfsumme lag für diese Übung außerhalb des kopierten Pakets. Das ist kein produktiver Vertrauensdienst.
Die tatsächliche lokale Ausführung lieferte PASS für die unveränderte Kopie, FAIL_ARTIFACT nach Änderung des Datensatzes, FAIL_MANIFEST nach Änderung des Manifests und FAIL_MISSING nach Entfernung des Datensatzes. Eine separat redigierte Arbeitskopie hatte einen anderen Hash; das Originalpaket lieferte weiterhin PASS. Dies sind Ergebnisse von Integritätstests, keine Nachweise einer IAM-, Verschlüsselungs- oder Rechtskontrollprüfung.
Die Demonstration lief unter einem lokalen Betriebssystembenutzer. Eine produktive Abnahmeübung muss zusätzlich zeigen, dass eine berechtigte Untersuchungsperson das Paket in einer sauberen Umgebung entschlüsseln und lesen kann, eine unberechtigte Identität abgewiesen wird und die Wiederherstellung nicht vom Konto ausgeschiedener Beschäftigter abhängt. Prüfen Sie dies gegen Ihre tatsächlichen Speicher-, Identitäts- und Schlüsselverwaltungssysteme. Verzeichnisrechte allein belegen keine Trennung von Administratoren oder anderen Diensten.
Härten Sie einen Prüfer für nicht vertrauenswürdige Pakete: Verwerfen Sie Pfadausbrüche und Symlink-Auswege vor dem Öffnen; lehnen Sie doppelte Pfade, unerwartete Artefakte und nicht unterstützte Schemaversionen ab; begrenzen Sie Dateigrößen und führen Sie nichts aus dem Paket aus. Hashes erkennen Abweichungen von vertrauenswürdig erwarteten Bytes. Sie beweisen weder Vollständigkeit noch die Echtheit der ursprünglichen Beobachtung oder eine informierte menschliche Freigabe.
Geschützte Originale und redigierte Arbeitskopien trennen
Bewahren Sie notwendige Originale in einem zugriffsbeschränkten Nachweisspeicher mit ausdrücklicher Aufbewahrungs- und Sicherungsentscheidung auf. Erstellen Sie für die breitere Untersuchung eine abgeleitete Arbeitskopie. Dokumentieren Sie deren Ursprungsartefakt, Transformationsversion, Redaktionsgrund und eigene Prüfsumme. Redigieren verändert Bytes. Ein Vergleich mit dem Originalhash muss scheitern und ist kein Beleg eines Erhebungsfehlers.
Kopieren Sie das geschützte Manifest nicht vollständig in den Arbeitsbereich, wenn Pfade, Kennungen oder Metadaten die entfernten Informationen offenlegen. Bewahren Sie die Herkunftszuordnung im geschützten Speicher auf und geben Sie nur die zulässige Referenz weiter. Protokollieren Sie die Empfänger jeder Ableitung. Breiter Untersuchungszugriff rechtfertigt nicht automatisch die Offenlegung von Beschwerdetexten oder Beschäftigtendaten.
Der Zielkonflikt bleibt: Enge Exporte reduzieren Datenschutzrisiken, können aber ursächlichen Kontext auslassen. Breite Snapshots kosten Speicher und erhöhen die Folgen eines Datenabflusses. Dokumentieren Sie Auswahlregeln und bekannte Lücken. Bei gehosteten Modellen kann Reproduktion trotz vollständigem lokalem Release-Tupel unmöglich bleiben. Eine Lieferanten-Anfrage-ID und eine klare Grenze sind belastbarer als ein erfundener interner Snapshot.
Übergabe an die Rechtsberatung und Abnahmecheckliste
1. Beschreiben Sie beobachteten oder behaupteten Schaden, betroffenen Prozess und Unsicherheit, ohne eine rechtliche Klassifikation vorwegzunehmen.
2. Erfassen Sie mögliche Organisationsrollen, Lieferantenbeziehungen und Systemumfang. Lassen Sie anwendbare Regime und aktuelle Rechtsakte bestimmen.
3. Dokumentieren Sie Kenntniserlangungsereignisse mit Belegen. Lassen Sie relevante Meldefristen, Empfänger und Weitergabebeschränkungen rechtlich prüfen.
4. Übergeben Sie Release-Tupel, Quellreferenzen, Aufsichtsnachweise, Eingriffshistorie und bekannte Lücken über freigegebene Zugangskanäle.
5. Zeigen Sie die Prüfung des intakten Pakets, die Erkennung absichtlicher Veränderungen, fehlender Artefakte und berechtigte Lesbarkeit. Prüfen Sie verweigerten Zugriff separat.
6. Trennen Sie die Meldeentscheidung vom Abschluss der Ursachenanalyse. Dokumentieren Sie verantwortete Entscheidungen, Einreichungen und Korrekturen, statt frühere Versionen zu überschreiben.
7. Weisen Sie Übungsfehlern Verantwortliche zu: Lieferantenzugriff, abgelaufene Schlüssel, unsichere Uhren und fehlende Dokumentversionen. Wiederholen Sie den fehlgeschlagenen Schritt nach der Korrektur.
Die übergreifende Architektur für NIS2-fähigen KI-Betrieb verbindet diese Kontrollen mit Lieferanten- und Netzwerkgrenzen. Sie macht die Melderegime nicht identisch.
Mit einem rekonstruierbaren Fall beginnen
Wählen Sie einen folgenreichen Workflow und führen Sie die Übung vor der nächsten Modell- oder Retrieval-Änderung mit synthetischen Daten durch. Das nützliche Ergebnis besteht aus einem geprüften Paket, einem ausdrücklichen Lückenregister und benannten Verantwortlichen – nicht aus der Erklärung allgemeiner Vorfallsbereitschaft. Eine fokussierte Architekturprüfung für KI-Vorfallsnachweise kann Sie dabei unterstützen, Erhebungsgrenzen, Release-Abhängigkeiten, Zugriffskontrollen und Abnahmetests des Verifikators auf Ihre konkrete Betriebsumgebung abzustimmen.
