Der September hat zwei Nachrichten gebracht, die auf den ersten Blick wenig miteinander zu tun haben. Am 3. September hat OpenAI GPT-6 Astra veröffentlicht, am 22. September folgten GPT-6 Sol und Luna zu Preisen, die halb so hoch liegen wie bei den Vorgängern. Sol kostet zwei US-Dollar je Million Eingabe-Token und zehn US-Dollar je Million Ausgabe-Token. Und heute, am 24. September, wird die Sora-Schnittstelle für Videogenerierung abgeschaltet, sechs Monate nach der Ankündigung im März. Beide Ereignisse führen zur selben Konsequenz: Die Modellebene bewegt sich schneller als die Business Cases und Architekturen, die auf ihr aufbauen.
Was der Preissturz für Business Cases bedeutet
Viele Business Cases für KI-Anwendungen wurden im Frühjahr mit den damaligen Tokenpreisen gerechnet. Diese Rechnungen sind in einem Teil ihrer Annahmen nun überholt, und zwar in beide Richtungen. Anwendungsfälle, die als zu teuer zurückgestellt wurden, etwa die vollständige Auswertung großer Dokumentenbestände, können inzwischen wirtschaftlich sein. Gleichzeitig verlieren Anwendungen, deren Wert vor allem im günstigen Zugang zu Modellleistung lag, ihren Vorsprung, weil diesen Zugang nun jeder hat.
Wichtig ist dabei die Relation. Die Modellkosten sind in den meisten produktiven Anwendungen nicht der größte Kostenblock. Integration, Prüfung, Betrieb und Befähigung dominieren, und an ihnen ändert eine Preissenkung nichts. Belastbar wird ein Business Case deshalb, wenn er die Modellkosten nicht als feste Größe führt, sondern mit einer Bandbreite rechnet und zeigt, ab welchem Preis sich die Entscheidung umkehren würde. Diese Sensitivität gehört in jede Vorlage, die heute zur Freigabe geht.
Abkündigungen gehören zum Normalbetrieb
Die Einstellung von Sora ist kein Einzelfall, sondern ein besonders sichtbares Beispiel für einen regelmäßigen Vorgang. Anbieter nehmen Modelle, Versionen und Schnittstellen vom Markt, wenn sie sich nicht rechnen oder durch Nachfolger ersetzt werden. Für Sora wurde zuerst die App im April eingestellt, heute folgt die Schnittstelle. Wer ein Produkt oder einen internen Prozess darauf gebaut hat, musste in sechs Monaten migrieren. Das ist eine vergleichsweise großzügige Frist, und trotzdem ist sie für manche Organisationen zu kurz, weil niemand wusste, wo die Schnittstelle überall im Einsatz war.
Daraus folgt eine einfache Anforderung: Für jede produktive Anwendung muss bekannt sein, auf welchem Modell in welcher Version sie läuft und bis wann diese Version zugesichert ist. Dieses Verzeichnis existiert in den wenigsten Unternehmen, weil Modellwahl bisher als technisches Detail der Projektteams galt. Mit wachsender Zahl produktiver Anwendungen wird es zu einer Frage der Betriebssicherheit.
Austauschbarkeit ist eine Architekturentscheidung
Ob ein Modellwechsel Tage oder Monate dauert, entscheidet sich nicht beim Wechsel, sondern beim Bau. Drei Elemente machen den Unterschied. Eine Zwischenschicht zwischen Anwendung und Modell, damit der Wechsel nicht in jeder Anwendung einzeln erfolgen muss. Prompts und Konfigurationen, die nicht auf die Eigenheiten eines Anbieters zugeschnitten sind. Und vor allem ein eigener Satz von Testfällen je Anwendung, mit Eingaben und erwarteten Ergebnissen, gegen den ein neues Modell geprüft werden kann. Dieser Testsatz ist der eigentliche Wert, denn er verwandelt die Frage, ob ein Wechsel möglich ist, von einer Vermutung in eine Messung.
Die neuen Modellfamilien mit mehreren Preisstufen machen zudem eine Arbeitsteilung sinnvoll, die viele Unternehmen noch nicht nutzen. Aufgaben mit hohem Anspruch an das Urteil laufen auf dem leistungsstärksten Modell, Aufgaben mit hohem Volumen und klarer Struktur auf einem günstigen. Diese Aufteilung senkt die Kosten deutlich stärker als jede Preisverhandlung. Sie verlangt allerdings dieselbe Voraussetzung wie der Anbieterwechsel: die Fähigkeit, die Qualität eines Modells für eine konkrete Aufgabe zu messen.
Was Einkauf und Verträge leisten müssen
Die Preisentwicklung stellt langfristige Abnahmeverpflichtungen infrage. Wer im Frühjahr ein mehrjähriges Mindestvolumen zu festen Preisen vereinbart hat, zahlt heute unter Umständen das Doppelte des Marktpreises. Verträge über Modellleistung brauchen deshalb Klauseln zur Preisanpassung oder kurze Laufzeiten für die Preisbindung. Ebenso gehören Mindestfristen für Abkündigungen in den Vertrag, und zwar mit einer Länge, die eine eigene Migration inklusive Test erlaubt.
Ein dritter Punkt wird fast immer übersehen: die Mitnahme dessen, was im Laufe der Nutzung entsteht. Angepasste Modelle, Vektordatenbanken und gespeicherte Konfigurationen sollten in einem Format herausgegeben werden können, das bei einem anderen Anbieter nutzbar ist. Ohne diese Zusage entsteht eine Bindung, die nicht über den Vertrag, sondern über den Aufwand eines Neuaufbaus wirkt, und die ist in der Regel stärker.
Fazit und Empfehlung
Die Modellebene wird billiger und unbeständiger zugleich, und beides spricht für dieselbe Antwort. Für die nächsten neunzig Tage empfehlen wir drei Schritte. Erstens die wichtigsten Business Cases mit aktuellen Preisen und einer Preisbandbreite neu rechnen und zurückgestellte Anwendungsfälle erneut prüfen. Zweitens ein Verzeichnis aller Modellabhängigkeiten mit Version und zugesicherter Laufzeit aufbauen. Drittens für jede produktive Anwendung einen Testsatz anlegen, der einen Modellwechsel messbar macht, und laufende Verträge auf Preisbindung, Abkündigungsfristen und Datenmitnahme prüfen.
ECODYNAMICS begleitet Unternehmen dabei, ihre KI-Landschaft auf diese Beweglichkeit auszurichten. In der AI Executive Advisory bewerten wir Business Cases und Plattformentscheidungen neu, und mit AI Solutions & Engineering bauen wir die Zwischenschicht und die Testsätze, die einen Wechsel planbar machen. Wenn bei Ihnen gerade Verträge über Modellleistung verhandelt oder verlängert werden, sprechen Sie mit uns, bevor die Preise für die nächsten Jahre festgeschrieben sind.