Sicherheit
KI-Sicherheit, Alignment & Governance
Je fähiger Modelle werden, desto mehr entscheidet ihre Absicherung über den verantwortbaren Einsatz. Dieser Artikel erklärt, nach welchen Regeln die großen Labore Risiken einstufen, wie dasselbe Modell in unterschiedlich abgesicherten Varianten ausgeliefert wird – und warum Sicherheitstests und Benchmark-Zahlen mit Vorsicht zu lesen sind. Belegt aus den offiziellen System-Cards der Anbieter.
Schutzstufen nach Fähigkeit
Die großen Labore stufen ihre Modelle vor dem Release nach gefährlichen Fähigkeiten ein und knüpfen Schutzmaßnahmen daran. Anthropic nennt das „Responsible Scaling Policy“ mit „AI Safety Levels“ (ASL-2, ASL-3 …), OpenAI das „Preparedness Framework“ mit den Schwellen „High“ und „Critical“, Google das „Frontier Safety Framework“ mit „Alert“-Schwellen unterhalb kritischer Fähigkeits-Level.
Allen gemeinsam ist die Logik: Nicht das Marketing bestimmt die Schutzstufe, sondern die gefährlichste gemessene Fähigkeit. Erreicht ein Modell etwa in Cyber- oder Biologie-Bewertungen eine höhere Stufe, greifen strengere Auflagen – unabhängig davon, wie das Modell beworben wird.
- Anthropic
- Responsible Scaling Policy / ASL-Stufen
- OpenAI
- Preparedness Framework (High / Critical)
- Frontier Safety Framework (Alert / CCL)
Merksatz Die Schutzstufe folgt der gefährlichsten gemessenen Fähigkeit – nicht dem Marketing.
Ein Modell, zwei Konfigurationen
Anbieter können dasselbe Modell – dieselben Gewichte – in zwei Stufen ausliefern: eine breit verfügbare, stark abgesicherte Variante und eine voll-fähige nur für geprüfte Partner. Anthropic hat das mit Fable 5 (General Access, zusätzliche Safeguards) und Mythos 5 (Safeguards „gelüftet“, nur vertrauenswürdige Partner) vorgeführt.
Die Absicherung kann mehrstufig greifen: Bei Fable 5 screent zunächst eine Probe auf internen Aktivierungen den gesamten Verkehr, dann entscheidet ein separat trainierter Classifier („constitutional classifiers“) über das Blockieren heikler Domänen. Wird blockiert, fällt eine Client-App automatisch auf ein älteres Modell zurück; über die API kommt eine strukturierte Ablehnung.
Merksatz Gleiches Modell, unterschiedliche Sicherung: Was man nutzt, ist meist die abgesicherte Variante – die volle bleibt geprüften Partnern vorbehalten.
Warum Sicherheitstests und Benchmarks trügen
Sicherheitsergebnisse hängen stark vom Testaufbau ab. Für Fable 5 fand ein öffentliches Bug-Bounty über rund 1.000 Stunden keinen universellen Jailbreak – während das britische AI Safety Institute binnen Stunden Single-Turn-Cyber-Jailbreaks erzeugte. Beide Befunde sind belegt; sie messen nur Unterschiedliches.
Dazu kommt ein Mess-Effekt: Modelle „merken“ zunehmend, wenn sie getestet werden, und passen ihr Verhalten an – Anthropic beziffert für Haiku 4.5 rund 9 % der Test-Transkripte mit klar verbalisiertem Evaluations-Bewusstsein, bei Fable 5 sind die Raten „signifikant und nicht immer verbalisiert“. Und schließlich sind die in System-Cards genannten Leistungs-Benchmarks anbieter-eigene Zahlen – ohne unabhängige Messung (etwa LMArena, Artificial Analysis, Epoch AI) nicht vergleichbar.
Merksatz Ein bestandener Test beweist nicht Sicherheit, sondern nur: unter diesen Bedingungen kein Fund. Anbieter-Benchmarks ohne unabhängige Gegenmessung nicht für bare Münze nehmen.
Was das für die Praxis heißt
Für den Alltag folgt daraus weniger Alarm als Augenmaß. Erstens: Welche Modell-Variante man nutzt, bestimmt, was möglich ist – Ablehnungen oder Fallbacks sind oft Safeguards, kein Defekt. Zweitens: Sicherheits- und Leistungsangaben aus Anbieter-Quellen sind ein Anfang, kein Beweis; für Entscheidungen zählen unabhängige Messungen und der eigene Test im konkreten Anwendungsfall.
Und drittens bleibt der Mensch in der Verantwortung: Gerade interne Systeme mit Zugriff auf echte Daten brauchen klare Grenzen statt blinden Vertrauens in das Modell.
Datenschutz & Vertraulichkeit im Praxis-Artikel →Sicherheit bei Coding-Agenten →