OpenAI bremst sein riskantestes Modell und löst zugleich das Sicherheitsteam auf

Dunkler Serverraum mit blau leuchtenden Kabeln als Symbol für Cybersicherheit und KI-Risiken
Photo by Jefferson Santos on Unsplash

OpenAI hat Teile des Trainings an seinem kommenden Spitzenmodell mit dem internen Namen Astra pausiert, weil frühe Tests auf kritische Cyberangriffsfähigkeiten hindeuteten. Das Modell könnte demnach eigenständig schwere Sicherheitslücken in echten Systemen aufspüren und ausnutzen. Bemerkenswert daran: OpenAI hatte kurz zuvor genau das Team aufgelöst, das für die Bewertung solcher Katastrophenrisiken zuständig war.

Das Wichtigste in Kürze

  • OpenAI stufte Astra nach internen Tests erstmals als „kritisch“ im Bereich Cybersicherheit ein, der höchsten Risikostufe des eigenen Preparedness Framework.
  • Als Reaktion pausierte das Unternehmen zwei Wochen lang bestimmtes Reinforcement-Learning-Training; der größte geplante Frontier-RL-Lauf bleibt weiterhin angehalten.
  • Ein neues Überwachungssystem soll verdächtiges Modellverhalten künftig innerhalb von 30 Minuten erkennen und Alarm auslösen.
  • Kurz vor der Astra-Pause hatte OpenAI das Preparedness-Team aufgelöst, das für die Einschätzung genau solcher Katastrophenrisiken zuständig war.
  • CEO Sam Altman betont, das Kerntraining von Astra sei nie gestoppt worden, neue Modelle blieben im Zeitplan.

Was Astra laut OpenAI können soll, und warum das beunruhigt

Das Preparedness Framework von OpenAI stuft ein Modell als „kritisch“ ein, wenn es eigenständig schwere Softwarelücken in realen Systemen finden und ausnutzen kann oder ausgeklügelte Cyberangriffe auf gut gesicherte Ziele ohne menschliche Steuerung durchführen könnte. Genau diese Schwelle erreichte Astra laut ersten internen Tests: Das Modell zeigte demnach fortgeschrittene, eigenständige Programmierfähigkeiten und das Potenzial, bislang unbekannte Sicherheitslücken, so genannte Zero-Day-Schwachstellen, selbstständig zu identifizieren oder auszunutzen. Als Konsequenz verlagert OpenAI Teile der weiteren Entwicklung in abgeschottete Umgebungen mit eingeschränkter Netzwerkanbindung, in denen der Code ausschließlich in einer Sandbox läuft. Das neue Überwachungssystem, das verdächtiges Verhalten binnen 30 Minuten melden soll, überwacht dabei laut Berichten etwa ein Fünftel der eingesetzten Rechenleistung, mit Schwankungen je nach Arbeitslast.

Die unbequeme Parallele zur aufgelösten Preparedness-Abteilung

Die Ironie der Situation liegt im Timing. Wie kabel-salat.info bereits berichtete, hat OpenAI sein eigenes Sicherheitsteam für Katastrophenrisiken aufgelöst und dessen Aufgaben auf bestehende Teams verteilt. Ausgerechnet in dieser Phase liefert das firmeneigene Bewertungssystem den bislang deutlichsten Beleg dafür, warum ein solches Team überhaupt existierte. OpenAI erklärt dazu, man wolle stattdessen stärker in Alignment-Forschung investieren, also in Methoden, die KI-Systeme grundsätzlicher an menschlichen Werten und Zielen ausrichten sollen. Ob verteilte Zuständigkeit in bestehenden Teams dieselbe Aufmerksamkeit auf einzelne Risikoklassen sicherstellt wie eine dedizierte Einheit, bleibt offen und lässt sich von außen kaum überprüfen. Kritiker werten die Auflösung ausgerechnet jetzt als Signal, dass Warnsysteme und die Organisationen, die sie auswerten, zwei verschiedene Dinge sind.

Kein Einzelfall: Auch andere Anbieter arbeiten mit Risikoschwellen

OpenAI ist nicht der einzige Anbieter, der sich formale Risikoschwellen für besonders gefährliche Fähigkeiten auferlegt hat. Anthropic verpflichtet sich mit seiner Responsible Scaling Policy zu ähnlichen Sicherheitsstufen, bevor ein Modell mit potenziell kritischen Fähigkeiten überhaupt breiter eingesetzt werden darf, Google DeepMind verfolgt mit seinem Frontier Safety Framework einen vergleichbaren Ansatz für biologische, chemische und cybernetische Risikoklassen. Der Unterschied liegt weniger im Prinzip als in der Praxis: Alle drei Rahmenwerke leben davon, dass ein internes Team sie unabhängig vom Produktdruck auswertet und im Zweifel gegen den eigenen Zeitplan des Unternehmens durchsetzt. Genau an diesem Punkt setzt die Kritik an OpenAIs Vorgehen an, denn eine Risikoschwelle, die technisch sauber definiert ist, aber organisatorisch niemandem mehr eindeutig zugeordnet ist, verliert einen Teil ihrer Durchsetzungskraft. Wie belastbar die verteilte Zuständigkeit bei OpenAI tatsächlich ist, lässt sich von außen derzeit nicht prüfen, weil die internen Eskalationswege nicht veröffentlicht sind.

Zwischen Vorsicht und Zeitdruck

Sam Altman hat öffentlich betont, dass Astras Kerntraining zu keinem Zeitpunkt vollständig gestoppt wurde und neue Modelle weiterhin planmäßig erscheinen sollen. Das deckt sich mit dem Bild, das aus den Berichten hervorgeht: Nicht das gesamte Projekt liegt auf Eis, sondern gezielt jene Trainingsläufe, die die riskantesten Fähigkeiten weiter verstärken würden. Diese Gratwanderung ist typisch für die aktuelle Phase der Frontier-KI-Entwicklung. Der wirtschaftliche Druck ist hoch, gerade weil Konkurrent Anthropic zuletzt beim Umsatzwachstum an OpenAI vorbeizog. Gleichzeitig zwingen eigene Sicherheitsstandards, deren Überschreitung öffentlich einsehbar dokumentiert ist, zu sichtbaren Bremsmanövern. Wer beides gleichzeitig behauptet, schnelles Tempo und verantwortungsvolle Vorsicht, muss beides auch belegen können, sonst bleibt es eine Behauptung.

Einordnung

Für sich genommen ist eine Trainingspause nach einer kritischen Risikoeinstufung genau das, was ein Preparedness Framework leisten soll: ein technisches Warnsystem, das im Ernstfall tatsächlich greift. Fragwürdig wird es erst im Zusammenspiel mit der Auflösung des zuständigen Teams. Eine Warnschwelle ist nur so viel wert wie die Organisation, die sie ernst nimmt und mit Konsequenzen versieht. Ob die neu verteilten Zuständigkeiten bei OpenAI diese Funktion tatsächlich ersetzen oder ob damit eher Verantwortung diffundiert, wird sich erst zeigen, wenn die nächste kritische Einstufung ansteht, und wenn öffentlich wird, wer dann tatsächlich entscheidet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen