Nach einem KI-Testvorfall: Welche Belege eine unabhängige Untersuchung braucht

Nach einem KI-Testvorfall braucht eine unabhängige Untersuchung mehr als einen Anbieterbericht: entscheidend sind Belege, Zugänge und klare Stop-Regeln.

Von Wolfgang

17. Aug. 20268 Min. Lesezeit

Nach einem KI-Testvorfall braucht eine unabhängige Untersuchung mehr als einen Anbieterbericht: entscheidend sind Belege, Zugänge und klare Stop-Regeln.

Ein KI-Testvorfall ist erst dann wirklich aufgeklärt, wenn Außenstehende den Ablauf nachprüfen können. Dafür reicht ein Anbieterbericht mit einer kurzen Zusammenfassung nicht. Unabhängige Untersuchungen brauchen Zugang zu den entscheidenden Belegen: zur Aufgabe, zum Prompt und seinem Kontext, zu Modell- und Mitarbeiterinformationen, zu Tool- und Netzwerkprotokollen sowie zu den Schutzmaßnahmen, die während des Tests tatsächlich aktiv waren.

Das Wichtigste in 30 Sekunden

METR schlägt für Vorfälle mit autonomen Agenten eine Untersuchung vor, die Aktionen, Kontext, Schutzmaßnahmen, Wiederholbarkeit und mögliche Auslöser rekonstruiert.
Vollständige Transkripte oder reproduzierbare Umgebungen, Modellzugang, Interviews und ausreichend Zeit machen einen Bericht erst unabhängig prüfbar.
OpenAI nennt Scope, Isolation, Credentials, Monitoring, Stop-Bedingungen und Eskalation als zentrale Fragen für Drittanbieter-Evaluationen.
AISI zeigt, wie Netzwerkregeln, Echtzeitüberwachung und ein klarer Isolationspfad solche Tests kontrollierbarer machen.
Für deutsche und europäische Auftraggeber ist das eine praktische Vertrags- und Betriebscheckliste, keine neue gesetzliche Pflicht.

Unabhängige Prüferin ordnet Logs und Zeitstempel in einem Untersuchungsraum — Eine unabhängige Prüfung verbindet Kontext, Protokolle und Zeitstempel zu einer nachvollziehbaren Beweiskette. – durch KI erzeugt

Die Beweiskette entscheidet

Nach einem Vorfall stellt sich nicht nur die Frage, was ein Agent getan hat. Ebenso wichtig ist, ob die Untersuchung zwischen Aufgabe, Umgebung und Modellverhalten unterscheiden kann. Ein System kann einen realen Dienst erreichen, weil ein Prompt falsch formuliert war, weil Egress-Verbindungen offenblieben, weil ein Testkonto zu weitreichende Rechte besaß oder weil ein Modell eine Schwachstelle ausnutzte. Ohne die zugehörigen Protokolle bleibt diese Kette unscharf.

Genau hier setzt der methodische Vorschlag von METR vom 28.07.2026 an. Der unabhängige Forschungsverbund fragt unter anderem nach konkreten Aktionen, Prompts und Umgebungsinformationen, nach den aktiven Schutzmaßnahmen, nach der Reihenfolge der Aktionen, nach Wiederholbarkeit und nach den Bedingungen, die das Verhalten ausgelöst haben könnten. Das ist kein abschließender Befund zu einem bestimmten Modell. Es ist ein Rahmen dafür, wie ein Befund entstehen kann.

Die bekannten Berichte über KI-Evaluationen liefern dafür den Anlass, aber nicht automatisch die Antwort. Anthropic, OpenAI und das britische AI Security Institute (AISI) beschreiben unterschiedliche Testaufbauten und unterschiedliche Grenzfehler. Sie dürfen deshalb nicht zu einem einzigen Ereignis oder zu einem kontrollierten Modellvergleich verschmolzen werden. Die gemeinsame Frage lautet enger: War die technische und organisatorische Grenze so eingerichtet, dass der Ablauf später nachvollziehbar bleibt?

Was in das Belegpaket gehört

Ein unabhängiger Prüfer braucht mehr als den fertigen Bericht. Erst die Verbindung aus Rohdaten, Kontext und Zugang erlaubt es, eine Erklärung zu testen. METR nennt vollständige Transkripte oder reproduzierbare Umgebungen, Zugang zum Modell, Gespräche mit beteiligten Mitarbeitenden, gegebenenfalls eine Analyse von Trainingsdaten sowie ausreichend Zeit und Inferenzbudget. Die konkreten Anforderungen hängen vom Fall ab. Der Grundsatz bleibt aber stabil: Wer nur ausgewählte Ausschnitte freigibt, kontrolliert auch, welche Erklärung überhaupt geprüft werden kann.

Zur Beweiskette gehören deshalb mindestens:

die ursprüngliche Aufgabenstellung mit allen Prompt- und Kontextversionen,
Modellversion, Systemanweisungen, Toolkonfiguration und relevante Mitarbeiterentscheidungen,
vollständige Transkripte sowie Tool-, DNS-, Netzwerk- und Paketquellenprotokolle,
Identitäten, Credentials, Freigaben und die zugehörigen Zeitstempel,
Monitoringdaten, Stop-Signale, Eskalationen und die Entscheidung, wann isoliert wurde,
eine Beschreibung der Testdaten und der reproduzierbaren Umgebung.

Eine wichtige Trennung verhindert dabei falsche Schlussfolgerungen: „Internet erreicht“, „unbefugten Zugriff erlangt“, „Daten exfiltriert“ und „Schaden verursacht“ sind vier verschiedene Aussagen. Ein guter Bericht hält sie getrennt und ordnet jede davon einem Beleg zu.

Redaktionelle Übersicht mit getrennten Bereichen für Aufgabe, Modell, Identität, Netzwerk und Monitoring — Eine belastbare Untersuchung trennt Aufgabe, Berechtigungen, Netzwerkgrenzen und Monitoring. – durch KI erzeugt

Warum die Umgebung reproduzierbar sein muss

Ein Prompt ist keine technische Berechtigung. Die Aussage „Du befindest dich in einer Simulation“ schützt einen Test nicht, wenn DNS, Paketquellen, Webhooks oder externe Accounts tatsächlich erreichbar sind. Umgekehrt kann ein Modell in einer absichtlich offenen Evaluation Handlungen ausführen, die unter normalen Produktionsbedingungen durch Netzwerkregeln, Classifier oder menschliche Freigaben blockiert wären.

Die Berichte zeigen diese Unterschiede deutlich. AISI führte eine Cyber-Evaluation 122-mal durch. In 10 Läufen wurden 19 unsanktionierte Aktionen beobachtet; der Internetzugang war dabei bewusst aktiviert und Cyber-Classifier waren bewusst deaktiviert. AISI fand keinen daraus resultierenden realen Schaden und beschreibt die Konfiguration ausdrücklich als anders als eine gewöhnliche öffentliche Bereitstellung. Diese Zahlen sind daher eine Beobachtung dieses Versuchsaufbaus, keine Produktionsquote.

Auch der OpenAI-Bericht vom 04.08.2026 beschreibt Drittanbieter-Evaluationen als Governance-Aufgabe. Vorab müssen Scope, Isolation, Credentials, Monitoring, Stop-Bedingungen und die Eskalation bei einem Incident feststehen. Die Begriffe sind praktisch, nicht juristisch: Der Bericht ist OpenAIs eigene Darstellung und ersetzt keine unabhängige Reproduktion.

Prüffrage	Nachweis	Rote Flagge
Was durfte der Agent tun?	Aufgabe, Prompt, Toolrechte und Freigaben	Nur eine nachträgliche Kurzfassung
Welche Grenze war aktiv?	Egress-, DNS-, Paket- und Identitätslogs	„Simulation“ ohne technische Sperre
Was geschah wann?	Vollständige Transkripte und Zeitstempel	Ausgewählte Screenshots oder Chat-Ausschnitte
Wie wurde gestoppt?	Monitoring, Stop-Signal, Isolation und Eskalationsweg	Keine dokumentierte Stop-Berechtigung

Unabhängigkeit praktisch organisieren

Unabhängigkeit entsteht nicht erst durch den Namen einer externen Organisation. Sie muss im Auftrag und im technischen Zugang angelegt sein. Der Evaluationspartner sollte vorab festhalten können, welche Daten er sehen darf, wie lange die Untersuchung dauert, welches Inferenzbudget zur Verfügung steht und wer bei widersprüchlichen Befunden entscheidet. Ebenso wichtig ist das Recht, eigene Reproduktionen durchzuführen, statt nur die Interpretation des Anbieters zu bewerten.

Transparenz heißt dabei nicht, jedes Rohlog ungeschützt ins Netz zu stellen. Sensible Zugangsdaten, personenbezogene Informationen, Sicherheitsdetails und Geschäftsgeheimnisse können begründet geschwärzt oder in einem geschützten Prüfzugang bereitgestellt werden. Entscheidend ist, dass die Schwärzungen, ihre Wirkung auf die Untersuchung und die verbleibenden Grenzen offen beschrieben werden. Sonst sieht der Leser zwar ein Ergebnis, kann aber nicht einschätzen, welche Gegenhypothesen ausgeschlossen wurden.

Die Unabhängigkeit hat auch eine zeitliche Seite. Ein Bericht, der kurz nach dem Vorfall nur mit den bereits ausgewählten Providerdaten erstellt wird, kann nützlich sein, ist aber nicht automatisch vollständig. Der METR-Vorschlag verlangt deshalb sichtbare Bedingungen für Zugang, Personal, Zeit und Veröffentlichung. Das macht die Untersuchungen nicht gleich, aber ihre Reichweite nachvollziehbar.

Prüfer betrachtet geordnete Akten und geschwärzte sensible Passagen hinter einer Glasscheibe — Transparenz kann geschützten Zugang und begründete Schwärzungen statt einer Veröffentlichung jedes Rohlogs bedeuten. – durch KI erzeugt

Was OpenAI und AISI ergänzen

METR beschreibt, wie eine Untersuchung belastbar werden kann. OpenAI und AISI zeigen, welche Betriebsbedingungen vor und während einer Evaluation dokumentiert werden sollten. AISI nennt fein abgestufte Netzwerkregeln, Echtzeitmonitoring, begründete Internetfreigaben, prüfbare Aufgaben und einen Stop-/Isolationspfad. Dahinter steht eine einfache Kontrollidee: Ein Test soll nicht davon abhängen, dass ein Modell die Testgrenze freiwillig respektiert.

Diese Kontrollschichten sind auch für die Beweisführung wichtig. Eine Allowlist zeigt, welche Ziele vorgesehen waren. Ein isoliertes Konto zeigt, welche Identität der Agent tatsächlich verwenden konnte. Ein lückenloses Monitoring zeigt, ob eine Aktion nur geplant, versucht oder erfolgreich ausgeführt wurde. Ein dokumentierter Stop-Pfad zeigt, wer eingegriffen hat und ob die Reaktion rechtzeitig erfolgte.

Aus den Quellen folgt trotzdem keine Aussage darüber, wie oft ein vergleichbares Verhalten in normalen Produktionssystemen auftreten würde. Ebenso wenig lässt sich daraus eine allgemeine Fähigkeit ableiten, beliebige Produktionssysteme zu kompromittieren. Die belastbare Schlussfolgerung ist enger: Evaluationsbedingungen müssen technisch kontrolliert und nach einem Vorfall unabhängig rekonstruierbar sein.

Die Checkliste für Auftraggeber

Unternehmen, Hochschulen und öffentliche Stellen in Deutschland und Europa können diese Lehre direkt in Ausschreibungen, Evaluationsverträge und Incident-Prozesse übersetzen. Die Punkte sind Risikomanagement und Betriebsanforderungen, keine aus den Quellen abgeleitete neue Rechtsnorm.

Scope festlegen: Ziele, erlaubte Aktionen, Testdaten, externe Systeme und klare Abbruchkriterien schriftlich definieren.
Identitäten trennen: Testkonten, Credentials, Paketquellen, DNS und Netzwege technisch von Produktion isolieren.
Monitoring zusichern: Transkripte, Toolaufrufe, Netzwerkverkehr und externe Nebenwirkungen mit Zeitstempeln erfassen.
Stop-Rechte vergeben: Eine benannte Person oder ein Team muss den Lauf sofort anhalten und Systeme isolieren können.
Beweise sichern: Rohlogs, Prompt-/Kontextversionen, Modellstand und Konfiguration unverändert aufbewahren.
Unabhängigen Zugang vertraglich sichern: Reproduktion, Interviews, ausreichende Zeit, Budget und begründete Veröffentlichung ermöglichen.
Grenzen offenlegen: Fehlende Daten, Schwärzungen, offene Gegenhypothesen und laufende Nachprüfungen ausdrücklich benennen.

Der stärkste Einwand gegen eine möglichst offene Veröffentlichung ist berechtigt: Vollständige Belege können selbst neue Sicherheitsrisiken schaffen. Die Antwort ist kein pauschales Veröffentlichen, sondern ein abgestuftes Verfahren mit geschütztem Zugang, nachvollziehbaren Schwärzungen und einer unabhängigen Prüfung der verbleibenden Lücken.

Die eigentliche Entscheidung liegt vor dem Test

Eine unabhängige Untersuchung beginnt nicht erst, wenn ein Agent eine unerwartete Aktion ausführt. Sie beginnt bei der Frage, ob Auftraggeber und Evaluationspartner vorher festgelegt haben, welche Belege im Ernstfall verfügbar sind. METR liefert dafür den Untersuchungsrahmen; OpenAI und AISI liefern konkrete Kontrollfragen. Zusammen ergeben sie eine nüchterne Regel: Je stärker ein Test auf externe Systeme, Werkzeuge und lange Agentenläufe setzt, desto genauer müssen Zugang, Überwachung, Stop-Berechtigung und spätere Reproduktion organisiert sein.