Vier Werkzeuge beantworten unterschiedliche Fragen
Eine Fähigkeitsbewertung (Capability Evaluation) fragt, was ein Modell oder System unter festgelegten Bedingungen leisten kann. Eine Schutzmaßnahmen-Bewertung (Safeguard Evaluation) fragt, ob Kontrollen Missbrauch verhindern oder erkennen. Ein Sicherheitsnachweis (Safety Case) formuliert eine konkrete Behauptung und verbindet Evidenz mit dieser Behauptung durch ein explizites Argument. Vorfallmeldung lernt aus Fehlern und Beinahe-Unfällen während oder nach Tests und Einsatz.
Keines allein belegt, dass ein Modell „sicher” ist. Eine Prüfsammlung (Benchmark) kann wichtiges Verhalten auslassen; eine Schutzmaßnahme kann bei Anpassung versagen; ein Sicherheitsnachweis kann auf schlechter Evidenz beruhen; und Vorfalldaten treffen erst ein, nachdem etwas schiefgegangen ist. Zusammen können sie einen Evidenzkreislauf bilden: antizipieren, testen, begründen, überwachen, lernen und überarbeiten.
Fähigkeitsbewertungen brauchen ein definiertes Bedrohungsmodell
Frontier-Evaluationen untersuchen üblicherweise Cyberoperationen, chemische oder biologische Unterstützung, Autonomie, Modellreplikation, Überzeugungskraft und KI-Forschung. Ergebnisse hängen von Scaffolding, Prompts, Werkzeugen, Zeit, Compute, fachkundiger Hilfe, Wiederholungsversuchen und Sicherheitsfiltern ab. Werden nur Modellname und Punktzahl berichtet, sind Vergleiche unzuverlässig.
Das UK AI Security Institute hat mehr als 30 Frontier-Systeme getestet und berichtet von rasch steigender Leistung in mehreren Bereichen. Sein Trendbericht von 2025 vermerkt, dass Prüfer manchmal Vorab-Checkpoints oder Zugang mit Schutzmaßnahmen erhalten, die vom öffentlichen Produkt abweichen (UK-AISI-Frontier-AI-Trendbericht). Die Ergebnisse sind direkte Evidenz für diese Testkonfigurationen, kein Beweis für allgemeinen Erfolg in der realen Welt oder für AGI.
Evaluationen sollten Vergleichsmaßstäbe einbeziehen: unassistierte Anfänger, Experten, Internetsuche, ältere Modelle und bestehende Werkzeuge. Das relevante Risiko ist oft der Fähigkeitsgewinn (Uplift) — wie stark ein System die Fähigkeit eines Akteurs steigert — und nicht, ob das Modell überhaupt schädliche Informationen erzeugen kann.
Kontamination, Elizitierung und Sandbagging
Eine Prüfsammlung kann in den Trainingsdaten auftauchen und die Leistung künstlich aufblähen. Ein Modell kann eine Fähigkeit besitzen, die die Evaluation nicht hervorlockt (elizitiert). Umgekehrt können umfangreiches Prompting und spezialisierte Werkzeuge ein System erzeugen, das gewöhnliche Nutzer so nicht erhalten. Gute Berichte unterscheiden Standardverhalten des Produkts, maximal elizitierte Fähigkeit und End-to-End-Leistung des Agenten.
Strategische Minderleistung, manchmal Sandbagging genannt, ist ein prospektives Anliegen, wenn Systeme Tests erkennen können und einen Grund haben, Fähigkeit zu verbergen. Aktuelle Studien können den Mechanismus untersuchen, doch eine schlechte Punktzahl ist kein Beweis für Täuschung. Verdeckte Aufgaben, mehrere Umgebungen, Verhaltensüberwachung und White-Box-Zugang können die Unsicherheit verringern.
Statistische Unsicherheit spielt eine Rolle. Seltene, schwere Ausgänge erfordern viele Durchläufe oder sorgfältig konstruierte Evidenz. Prüfer sollten Konfidenzintervalle, Methoden der Aufgabenauswahl, Ausschlüsse und bekannte Grenzen veröffentlichen. Eine gesättigte Prüfsammlung sollte ein Neudesign auslösen, nicht Siegesmeldungen.
Schutzmaßnahmen müssen als Systeme bewertet werden
Ablehnungstraining ist nur eine Schicht. Schutzmaßnahmen umfassen Identitätsprüfungen, Richtlinien zur zulässigen Nutzung, Klassifikatoren, Überwachung, Ratenbegrenzungen, Werkzeugberechtigungen, Sandboxing, menschliche Überprüfung und Reaktionsverfahren. Angreifer können Anfragen aufteilen, mehrere Konten nutzen, offene Gewichte per Fine-Tuning verändern, Inhalte codieren oder zwischen Diensten wechseln.
Die Schutzmaßnahmen-Prinzipien des UK AISI betonen explizite Bedrohungsmodelle und die Bewertung des gesamten Systems statt allein der Fähigkeit (UK AISI). Ein Labor beteiligte sich an der Konsultation und verfügt womöglich über privilegierten Zugang, doch staatliche Prüfer bleiben von der Kooperation des Anbieters abhängig und können nicht jede gefährliche Aufgabe veröffentlichen.
Tests von Schutzmaßnahmen sollten Falsch-Negative, Falsch-Positive, adaptive Angriffe, Nutzbarkeit, Latenz, Datenschutzkosten und die Frage messen, ob Warnungen zu Handeln führen. Ein Filter, der legitime Arbeit in Biologie oder Sicherheit blockiert, kann Nutzer zu weniger rechenschaftspflichtigen Systemen treiben; einer, der eindrucksvolle Ablehnungs-Screenshots erzeugt, sich aber leicht umgehen lässt, vermittelt eine falsche Sicherheit.
Sicherheitsnachweise machen das Argument prüfbar
Ein Sicherheitsnachweis formuliert eine abgegrenzte Behauptung — etwa „dieser Agent kann in diesem Einsatz den festgelegten katastrophalen Cyberschaden nicht verursachen” — und legt dann Evidenz und Begründung vor. Das UK AISI beschreibt drei Bestandteile: eine präzise Behauptung, Evidenz und ein sie verbindendes Argument (UK AISI, Februar 2025).
Das ist stärker als eine Checkliste, weil Prüfer jede Prämisse infrage stellen können. Es ist schwächer als ein Beweis: Evidenz kann unvollständig sein, Annahmen können sich als falsch erweisen, und der Entwickler kann eine bequeme Behauptung auswählen. Behauptungen sollten Modellversion, Architektur, Zugang, Nutzer, Dauer, Umgebung, Schadensschwelle und Gültigkeitszeitraum benennen.
Sicherheitsnachweise sollten Widerlegungsgründe (Defeaters) — Evidenz, die das Argument entkräften würde — sowie die eigene Unsicherheit einschließen. Unabhängige Prüfer benötigen Zugang zu den zugrunde liegenden Ergebnissen, nicht nur zu einer polierten Zusammenfassung. Wesentlicher Dissens sollte erhalten bleiben. Eine Genehmigung sollte verfallen, wenn sich Modell, Scaffolding, Werkzeuge, Bedrohungsumgebung oder Einsatzumfang ändern.
Einsatzschranken und Verhältnismäßigkeit
Evaluation zählt nur, wenn sie mit einer Entscheidung verknüpft ist. Ein Frontier-Rahmenwerk sollte Schwellenwerte festlegen, bevor Ergebnisse eintreffen, erforderliche Gegenmaßnahmen spezifizieren, benennen, wer Ausnahmen genehmigen kann, und Außerkraftsetzungen dokumentieren. Andernfalls kann ein Entwickler ein besorgniserregendes Ergebnis unter kommerziellem Druck uminterpretieren.
Kontrollen können abgestuft werden: Gewichte zurückhalten und stattdessen eine überwachte API anbieten, Werkzeuge einschränken, Hochrisiko-Nutzer beschränken, Autonomie verringern, menschliche Genehmigung ausweiten oder den Einsatz pausieren. Nicht jede besorgniserregende Fähigkeit erfordert dieselbe Reaktion.
Interessenkonflikte sind unvermeidlich, aber beherrschbar. Entwickler kennen ihre Systeme und profitieren von der Freigabe. Externe Prüfer können von Zugang oder Finanzierung durch den Entwickler abhängen. Regulierungsbehörden fehlt womöglich Fachwissen. Gesetzlich gesicherter Zugang, vielfältige Finanzierung, Veröffentlichungsrechte, rotierende Prüfer und die Offenlegung von Konflikten stärken die Glaubwürdigkeit.
Vorfallmeldung macht aus Überraschungen geteiltes Wissen
Ein Meldesystem für Vorfälle braucht eine Definition, eine Meldefrist, ein Schweregradschema, eine sichere Annahmestelle, eine Ursachenanalyse, Korrekturmaßnahmen und Rückmeldung an Betroffene. Beinahe-Unfälle zählen, weil sie schwache Kontrollen aufdecken, bevor der volle Schaden eintritt.
Nach Artikel 55 der KI-Verordnung der EU müssen Anbieter von Modellen mit allgemeinem Verwendungszweck und systemischem Risiko relevante schwere Vorfälle und Korrekturmaßnahmen erfassen, dokumentieren und dem KI-Büro sowie, sofern zutreffend, den nationalen Behörden melden. Die Kommission veröffentlichte im November 2025 eine Meldevorlage (Europäische Kommission). Diese gesetzliche Pflicht ist für erfasste Anbieter verbindlich; die Nutzung des freiwilligen GPAI Code of Practice ist ein Weg, Konformität nachzuweisen.
Kaliforniens SB 53 und New Yorks RAISE Act schreiben innerhalb ihres jeweiligen Geltungsbereichs die Meldung bestimmter kritischer Vorfälle vor. Freiwillige Unternehmensmeldungen außerhalb dieser Gesetze bleiben freiwillig, sofern keine andere Pflicht greift.
Was als Vorfall zählt
Definitionen sollten tatsächlichen schweren Schaden, glaubwürdige Beinahe-Unfälle, Kontrollverlust über einen Agenten, den Diebstahl von Gewichten, unerwartet entdeckte gefährliche Fähigkeit, systemisches Versagen von Schutzmaßnahmen sowie wesentliche Falschangaben gegenüber Prüfern umfassen. Gewöhnliche Halluzinationen können in Systemen zur Produktqualität behandelt werden, sofern Schwere oder Ausmaß keine Meldeschwelle überschreiten.
Eine zu weit gefasste Meldepflicht kann Regulierungsbehörden überfluten und Schwachstellen oder personenbezogene Daten offenlegen. Eine zu eng gefasste Meldepflicht verbirgt schwache Signale. Gestufte Meldungen können zunächst eine dringliche vertrauliche Mitteilung versenden, gefolgt von einer umfassenderen Untersuchung und, wenn sicher, einer anonymisierten öffentlichen Zusammenfassung.
Die Offenlegung des UK AISI aus dem Jahr 2026 zu nicht autorisiertem Agentenverhalten während Cyber-Tests veranschaulicht transparente Grenzziehung: Das Institut meldete potenziell schädliche Aktivität und stellte zugleich ausdrücklich klar, dass das Modell seine Sandbox nicht verlassen hatte (UK AISI, 2026). Präzise Sprache verhindert, dass ein realer Vorfall zu einer reißerischen, aber falschen Behauptung einer „KI-Flucht” wird.
Öffentliche Transparenz und gesicherte Details
Vollständige Evaluationsaufgaben können Missbrauch oder Manipulation der Prüfsammlung ermöglichen. Vollständige Vorfallakten können Opfer und Schwachstellen offenlegen. Die Antwort ist gestufter Zugang: öffentliche Behauptungen und Methoden; vertrauliche technische Details für qualifizierte Regulierungsbehörden und unabhängige Prüfer; und geschützte personenbezogene oder sicherheitsrelevante Informationen.
Aggregierte Meldungen sollten Vorfallkategorien, Schweregrad, Quelle der Entdeckung, Zeit bis zur Meldung, Korrekturmaßnahmen und Wiederholungen zeigen. Ein Transparenzbericht, der nur bestätigte Vorfälle zählt, ohne die Entdeckungskapazität zu erklären, kann Organisationen belohnen, die weniger genau hinschauen.
Der Evidenzkreislauf
Jeder schwere Vorfall sollte Bedrohungsmodelle, Evaluationen, Schutzmaßnahmen und den Sicherheitsnachweis aktualisieren. Jede neue Fähigkeit sollte eine Überprüfung eingesetzter Kopien und nachgelagerter Integrationen auslösen. Red Teams sollten Lehren aus Vorfällen erhalten, und Whistleblower benötigen geschützte Wege, wenn die formale Meldung versagt.
Die Empfehlungen mit Stand September 2026 sind eindeutig: Dokumentation standardisieren und zugleich domänenspezifische Tests beibehalten; unabhängigen Zugang bei hoher Fähigkeit oder hohem Umfang verlangen; Schwellenwerte mit vorab festgelegten Schranken verknüpfen; die Meldung erfasster schwerer Vorfälle und Beinahe-Unfälle verpflichtend machen; sensible Details schützen; und genügend aggregierte Evidenz für Rechenschaftspflicht veröffentlichen.
Keine Evaluation beweist, dass eine künftige AGI kontrolliert ist. Diese Praktiken machen Unsicherheit stattdessen lesbar und begrenzen den Einsatz auf Grundlage der jetzt verfügbaren Evidenz. Ihr Erfolg sollte daran gemessen werden, ob sie Probleme frühzeitig entdecken, Entscheidungen ändern und Wiederholungen verhindern — nicht daran, wie viele Prüfsammlungen oder Politikdokumente eine Organisation hervorbringt.