Google Cloud bietet nach eigenen Angaben als erster großer Cloud-Anbieter alle drei derzeit führenden Modellreihen über eine gemeinsame Plattform an: die hauseigene Gemini-Familie, Claude von Anthropic und nun auch die GPT-Modelle von OpenAI. Zum Start stehen GPT-6 Astra, GPT-6.1 Sol und GPT-6 Luna als private Vorschau für Unternehmenskunden bereit, also in einem eingeschränkten Zugang vor der allgemeinen Verfügbarkeit.
Was nach einer reinen Portfolio-Erweiterung klingt, verändert für Unternehmen vor allem eines: die Architekturentscheidung am Anfang eines KI-Projekts. Bisher fiel die Wahl des Modellanbieters oft zusammen mit der Wahl der Cloud-Umgebung. Wer mehrere Modellfamilien nutzen wollte, musste in der Regel mehrere Zugänge verwalten, unterschiedliche Abrechnungsmodelle abbilden und getrennte Sicherheits- und Datenschutzprüfungen durchlaufen.
Warum Modellvielfalt in der Praxis zählt
In realen Projekten gibt es selten ein Modell, das jede Aufgabe gleich gut löst. Ein Sprachmodell, das lange Fachtexte zuverlässig zusammenfasst, ist nicht automatisch die beste Wahl für strukturierte Datenextraktion, für Codegenerierung oder für einen Dialogassistenten im Kundenservice. Hinzu kommen nichtfunktionale Kriterien: Antwortzeiten, Kosten pro Anfrage, Verfügbarkeit in bestimmten Regionen und die Frage, wie gut sich ein Modell in bestehende Freigabeprozesse einfügt.
Wenn mehrere Modellfamilien über dieselbe Plattform erreichbar sind, lassen sich solche Abwägungen pro Anwendungsfall treffen statt einmal pauschal für das gesamte Unternehmen. Ein Produktkonfigurator kann dann ein anderes Modell nutzen als die interne Wissenssuche, ohne dass dafür eine zweite Infrastruktur entsteht.
Abhängigkeit vom Anbieter wird kalkulierbarer
Der zweite Effekt betrifft das, was in der IT als Lock-in bezeichnet wird: die technische und vertragliche Bindung an einen einzelnen Anbieter, die einen späteren Wechsel teuer macht. Diese Bindung verschwindet durch ein breiteres Modellangebot nicht, sie verschiebt sich lediglich. Die Abhängigkeit vom einzelnen Modellanbieter nimmt ab, die Abhängigkeit von der Plattform, über die alles läuft, nimmt tendenziell zu.
Für die Projektplanung ist das trotzdem ein Fortschritt. Ein Modellwechsel innerhalb derselben Plattform betrifft im Idealfall nur die Aufrufschicht der Anwendung und nicht die umgebende Infrastruktur aus Authentifizierung, Protokollierung, Kostenkontrolle und Datenhaltung. Genau diese Umgebung verursacht in der Praxis den größeren Teil des Aufwands.
Was sich daraus für die Architektur ableiten lässt
Unabhängig davon, welche Plattform ein Unternehmen einsetzt, empfiehlt sich ein Aufbau, der das konkrete Modell austauschbar hält. Bewährt haben sich dabei einige Grundsätze:
- Abstraktionsschicht: Die Anwendung spricht nicht direkt mit einem Modellendpunkt, sondern mit einer internen Schnittstelle, hinter der das Modell gewechselt werden kann.
- Prompts als Konfiguration: Anweisungen an das Modell gehören versioniert und außerhalb des Programmcodes verwaltet, damit sie pro Modell angepasst werden können.
- Messbare Qualität: Ein fester Satz von Testfällen mit erwarteten Ergebnissen macht den Vergleich zweier Modelle überprüfbar, statt ihn dem Bauchgefühl zu überlassen.
- Kosten- und Laufzeitdaten: Ohne Protokollierung von Tokenverbrauch und Antwortzeiten bleibt jede Wirtschaftlichkeitsrechnung Schätzung.
- Rückfallebene: Für produktive Prozesse sollte definiert sein, was passiert, wenn ein Modell nicht verfügbar ist oder unbrauchbare Antworten liefert.
Private Vorschau heißt nicht produktionsreif
Dass die GPT-Modelle zunächst nur als private Vorschau für Unternehmenskunden verfügbar sind, verdient Beachtung. In dieser Phase können sich Verfügbarkeit, Konditionen und Funktionsumfang noch ändern. Für Evaluierungen, Prototypen und interne Vergleichstests ist das ein sinnvoller Rahmen. Für geschäftskritische Prozesse mit Zusagen gegenüber Kunden sollte dagegen abgewartet werden, bis klare Betriebs- und Vertragsbedingungen vorliegen.
Sinnvoll ist deshalb ein gestuftes Vorgehen: zuerst ein eng abgegrenzter Anwendungsfall mit überschaubarem Risiko, dann ein belastbarer Vergleich mehrerer Modelle anhand eigener Daten, erst danach die Entscheidung über den produktiven Einsatz. Wer diese Reihenfolge einhält, vermeidet es, eine Architektur um ein Modell herum zu bauen, das in sechs Monaten bereits abgelöst ist.
Datenschutz und Governance bleiben eigene Aufgaben
Ein gemeinsamer Plattformzugang vereinfacht die technische Anbindung, ersetzt aber keine rechtliche Prüfung. Welche Daten an welches Modell übertragen werden dürfen, in welchen Regionen die Verarbeitung stattfindet und wie lange Eingaben gespeichert werden, bleibt pro Anwendungsfall zu klären. Gerade bei Personen- oder Vertragsdaten sollte diese Prüfung vor dem ersten Prototyp stehen und nicht danach.
Hilfreich ist eine interne Freigabeliste, die festhält, welche Modelle für welche Datenklassen zugelassen sind. Das schafft Klarheit für Entwicklungsteams und verhindert, dass Entscheidungen im Einzelfall improvisiert werden.
Einordnung für Web- und Softwareprojekte
Für Web- und Softwareprojekte verschiebt sich die zentrale Frage von „Welchen Anbieter wählen wir?“ hin zu „Wie halten wir die Modellwahl offen?“. Projekte sollten so geschnitten werden, dass ein Modellwechsel eine Konfigurationsänderung bleibt und keinen Umbau der Anwendung auslöst. Wer heute die Abstraktionsschicht, die Testfälle und die Protokollierung sauber aufsetzt, kann neue Modelle später mit geringem Aufwand bewerten, statt jede Marktbewegung als Projektrisiko zu erleben.
