OpenAI veröffentlicht gpt-oss unter Apache 2.0 und bezeichnet es als Model Card, nicht als System Card

Was OpenAI tatsächlich veröffentlicht hat

OpenAI hat zwei offene Reasoning-Modelle veröffentlicht, gpt-oss-120b und gpt-oss-20b, unter der Apache-2.0-Lizenz sowie einer gpt-oss-Nutzungsrichtlinie. Beide Modelle sind reine Textmodelle und kompatibel mit der Responses API von OpenAI.

Der Rahmen ist agentisch angelegt. Die Modelle sind für das Befolgen von Anweisungen, den Einsatz von Tools wie Websuche und die Ausführung von Python-Code sowie für Reasoning konzipiert. Ein bemerkenswertes Detail: Entwickler können den Reasoning-Aufwand anpassen und ihn für Aufgaben, die kein tiefes Reasoning benötigen, herunterregeln. Die Modelle sind anpassbar, zeigen die vollständige Chain-of-Thought und unterstützen Structured Outputs.

Für Teams, die bereits gegen die Responses API mit Closed-Source-Modellen integriert haben, ist diese Kompatibilität entscheidend. Sie bedeutet, dass sich gpt-oss in einen bestehenden Workflow für Tool-Calling und strukturierte Ausgaben einfügen lässt, statt eine neue Integrationsfläche zu erfordern.

Die Chain-of-Thought ist vollständig sichtbar

OpenAI gibt an, dass die Modelle die vollständige Chain-of-Thought bereitstellen. Für Teams in der Praxis ist eine sichtbare Reasoning-Spur nützlich, um das Verhalten von Agenten zu debuggen, Tool-Aufrufe zu prüfen und Evaluierungsumgebungen aufzubauen, die Zwischenschritte statt nur Endantworten untersuchen.

Diese Transparenz ist eine direkte Folge offener Gewichte: Es gibt keine serverseitige Ebene, die das Reasoning verbirgt. Das wirkt in beide Richtungen – Entwickler erhalten mehr Einblick, aber ebenso erhält jeder andere den gleichen Einblick, wie das Modell zu seinen Ausgaben kommt.

Warum von einer Model Card, nicht einer System Card gesprochen wird

OpenAI macht die Wahl der Bezeichnung ausdrücklich klar. Da gpt-oss in Systeme eingebettet wird, die von vielen unterschiedlichen Akteuren gebaut und betrieben werden, beschreibt das Dokument das Modell und nicht ein System. Die Sicherheit eines eingesetzten Systems liegt bei demjenigen, der es baut.

Die Modelle sind zwar standardmäßig darauf ausgelegt, die Sicherheitsrichtlinien von OpenAI zu befolgen, doch auch andere Akteure werden eigene Entscheidungen treffen und umsetzen, wie sie diese Systeme sicher halten.Montana Labs

Das Unternehmen weist außerdem darauf hin, dass sich das Risikoprofil von proprietären Modellen unterscheidet: Nach der Veröffentlichung können entschlossene Angreifer die Gewichte per Fine-Tuning so anpassen, dass Verweigerungen umgangen oder auf Schadwirkung optimiert wird – ohne dass OpenAI danach noch Schutzmaßnahmen nachrüsten oder den Zugriff entziehen kann. Entwicklern und Unternehmen wird mitgeteilt, dass sie zusätzliche Schutzmaßnahmen benötigen könnten, um die systemseitigen Schutzmechanismen nachzubilden, die bei über die API bereitgestellten Modellen mitgeliefert werden.

Der adversarielle Fine-Tuning-Test und seine erklärte Grenze

OpenAI hat skalierbare Fähigkeitsbewertungen für gpt-oss-120b durchgeführt und berichtet, dass das Standardmodell in keiner der drei überwachten Kategorien seines Preparedness Framework – Biologie und Chemie, Cyber sowie KI-Selbstverbesserung – die jeweiligen indikativen Schwellenwerte für hohe Fähigkeiten erreicht.

Anschließend simulierte man einen Angreifer, indem das Modell für die Kategorien Biologie/Chemie und Cyber adversariell feinabgestimmt wurde, unter Einsatz des eigenen, nach eigener Aussage führenden Trainings-Stacks. Die Safety Advisory Group prüfte die Ergebnisse und kam zu dem Schluss, dass das Modell in keinem der beiden Bereiche eine hohe Fähigkeitsstufe erreichte.

Zur Frage, ob die Veröffentlichung die Grenze offener Modelle voranbringt, sagt OpenAI: nein. Bei den meisten Bewertungen liegen ein oder mehrere bestehende offene Modelle in ihrem Standardzustand nahe an dem adversariell feinabgestimmten gpt-oss-120b. Mit anderen Worten: Das Argument für die Veröffentlichung stützt sich teilweise darauf, dass die Fähigkeit bereits anderswo verfügbar ist.

Die konkrete Konsequenz: Sicherheit wandert zum Integrator

Die konkrete Verschiebung besteht darin, dass die Verantwortung für Verweigerungsverhalten und systemseitigen Schutz von den Servern OpenAIs auf denjenigen übergeht, der die Gewichte einsetzt. Die Model Card dokumentiert Tests vor der Veröffentlichung; sie kann nicht festlegen, was nach einem Fine-Tuning geschieht.

Für Teams, die gpt-oss einsetzen, bedeutet das: Die Schutzmaßnahmen, die die API von OpenAI still bereitgestellt hat, werden nun zu Posten, die selbst aufgebaut und verantwortet werden müssen. Die Apache-2.0-Lizenz und die Kompatibilität mit der Responses API senken die Einstiegskosten; die Model Card macht deutlich, dass die sicherheitstechnische Umsetzung dabei nicht automatisch mitgeliefert wird.