OpenAI löst sein Preparedness-Team auf – was das für KI-Sicherheit in der Praxis bedeutet

Hallo, hier ist wieder Kora. Heute geht es um eine Personalie, die auf dem Papier klein wirkt, aber ein größeres Muster sichtbar macht: OpenAI hat sein „Preparedness“-Team aufgelöst – also genau jene Gruppe, die die Risiken der eigenen Modelle systematisch abklopfen sollte.

Was laut Bericht passiert ist

Die Financial Times berichtet unter Berufung auf Insider, dass das Team vollständig aufgelöst und die Mitarbeiter auf andere Bereiche verteilt wurden. Der bisherige Head of Preparedness, Dylan Scandinaro, arbeitet nun in einem Team, das sich mit selbstverbessernden KI-Systemen und deren Sicherheitsimplikationen beschäftigt. Andere Teammitglieder haben ihre Themen mitgenommen und untersuchen Risiken jetzt in spezialisierteren Feldern – etwa im Biologie- oder im Cybersecurity-Kontext der OpenAI-Modelle.

Bemerkenswert ist das Tempo: Die Position „Head of Preparedness“ wurde erst Ende 2025 geschaffen. Kaum aufgebaut, schon wieder umsortiert. Offiziell ist das keine Abschaffung von Sicherheitsarbeit, sondern eine Verlagerung in die Fachbereiche. Ob das in der Praxis dasselbe ist, darf man diskutieren.

Ein Muster, das nicht neu ist

Der Vorgang reiht sich in eine Kette ein. 2024 verließ Jan Leike, Co-Leiter des Superalignment-Teams, das Unternehmen mit der Kritik, Sicherheit werde gegenüber „funkelnden Produkten“ nachrangig behandelt. Auch die Abgänge von Ethik-Chefin Chloé Bakalar und Head of Safety Johannes Heidecke sollen intern für Unruhe sorgen. Ein Insider wird mit den Worten zitiert, es mache „irgendwie Angst“, es gebe ein großes Bedürfnis, das Thema jetzt richtig hinzubekommen. Andere berichten von Frust und Erschöpfung durch die dauernden Restrukturierungen.

Und dann ist da noch die nüchterne Lesart aus Investorensicht: Aufräumen vor dem Börsengang. Ursprünglich war der IPO für 2026 angepeilt, eine Verschiebung auf 2027 gilt inzwischen als möglich. Organigramme werden vor solchen Schritten gern gestrafft – nur haben Sicherheitsfunktionen die unangenehme Eigenschaft, dass ihr Wert erst sichtbar wird, wenn sie fehlen.

Zentrale Sicherheitsteams vs. verteilte Verantwortung

Diese Debatte kennen wir im Rechenzentrums- und Hosting-Umfeld sehr gut, nur unter anderem Namen. Auch bei uns lautet die Dauerfrage: zentrale Security-Einheit mit Vetorecht oder Sicherheit „in die Teams eingebettet“, nach dem DevSecOps-Gedanken? Beides funktioniert – aber nur unter Bedingungen:

• Verteilte Verantwortung braucht klare Zuständigkeiten. Sonst ist am Ende niemand zuständig.
• Es braucht ein Mandat. Wer Risiken meldet, muss auch bremsen dürfen – auch kurz vor dem Release.
• Es braucht Querschnittssicht. Genau die geht verloren, wenn ein Team, das das Gesamtrisiko bewertet, in Fachsilos aufgeht.
• Es braucht Kontinuität. Wer alle sechs Monate umstrukturiert, verliert Erfahrungswissen – und Menschen.

Wenn Sicherheitsarbeit in einer Organisation nur noch als Verhandlungsposition gegen Time-to-Market existiert, verliert sie langfristig. Das gilt für KI-Labore genauso wie für Softwarehäuser und Infrastrukturbetreiber.

Warum das für uns praktisch relevant ist

Viele von uns setzen KI-Modelle inzwischen nicht mehr nur zum Spielen ein, sondern in Support-Workflows, Log-Analysen, Code-Reviews oder als Agenten mit API-Zugriff. Genau dort werden Modellrisiken zu Betriebsrisiken: Prompt Injection, ungewollter Datenabfluss, überprivilegierte Agenten, Fehlentscheidungen in automatisierten Ketten.

Meine Konsequenz daraus ist unspektakulär, aber wirksam: Wir sollten uns nicht darauf verlassen, dass der Anbieter alle Risiken vorab wegräumt. Sinnvoll bleiben eigene Leitplanken – minimale Rechte für Agenten und API-Keys, klare Trennung von Produktions- und Testdaten, Protokollierung aller Modellzugriffe, menschliche Freigaben bei kritischen Aktionen und ein bewusster Umgang damit, welche Daten überhaupt an externe Modelle gehen. Wer Modelle selbst hostet, gewinnt hier zusätzliche Kontrolle, trägt aber auch mehr Verantwortung.

Und ein Punkt, der bei der Anbieterauswahl gern untergeht: Wie stabil ist die Sicherheitsorganisation auf der anderen Seite? Wenn dort ständig Teams entstehen und verschwinden und erfahrene Köpfe gehen, ist das ein Signal, das man in die eigene Risikobetrachtung aufnehmen darf – so wie wir es bei jedem anderen kritischen Dienstleister auch tun.

Mein Fazit

Eine Umstrukturierung ist noch kein Sicherheitsversagen. Aber sie ist ein Signal darüber, welche Priorität ein Thema im Unternehmen hat. Bei einem Anbieter, dessen Modelle in immer mehr Produktivumgebungen landen, würde ich mir mehr Kontinuität statt weniger wünschen. Bis das eintritt, gilt für uns: eigene Kontrollen bauen, Abhängigkeiten kennen und Vertrauen nicht mit Zuständigkeit verwechseln.

Man liest sich, eure Kora

Quelle: t3n