Gemini 3.5 Pro: Routing-Governance für Juni

Gemini 3.5 Pro ist der bestätigte Druckpunkt der Juni-Welle. Entscheidend sind Routing-Regeln, Kosten, Fallbacks und Evals.

Gemini 3.5 Pro: Routing-Governance für Juni

Gemini 3.5 Pro: Routing-Governance für Juni

Gemini 3.5 Pro ist der erste bestätigte Druckpunkt der KI-Modellwelle im Juni. Google sagt, dass Gemini 3.5 Pro intern bereits genutzt wird und im Folgemonat ausgerollt werden soll. Das ist genug Signal zur Vorbereitung, aber kein Grund, Produktionsrouten ungeprüft umzubauen. Der eigentliche Test ist KI-Modell-Routing-Governance.

Rund um Juni 2026 entsteht eine neue Modellwelle. Die öffentlichen Fakten sind unterschiedlich belastbar. Google hat offiziell erklärt, dass Gemini 3.5 Pro intern bereits genutzt wird und im Folgemonat ausgerollt werden soll. OpenAI hat GPT-5.5 bereits in den Markt gebracht, während die Vorabgerüchte schon über GPT-5.6 sprechen. Bei Anthropic sind die öffentlichen Claude-Listen von Google Cloud die sicherere Basis; Claude-4.8-Signale bleiben unbestätigt, solange Anthropic oder ein Cloud-Partner sie nicht veröffentlicht.

Für Unternehmen ist diese Trennung entscheidend. Die wichtigste Frage lautet nicht, welcher Anbieter die lauteste Demo liefert. Entscheidend ist, ob Routing-Regeln, Evaluationen, Budgetgrenzen, Audit-Logs und Rollback-Pfade stehen, bevor die nächste Release Note erscheint.

Was bestätigt ist, was nicht, und warum das zählt

Der bestätigte Teil reicht aus, um zu handeln. Google hat Gemini 3.5 Flash auf der I/O 2026 vorgestellt und als Modellfamilie für "frontier intelligence with action" positioniert. Googles eigene Zusammenfassung nennt 76,2 % auf Terminal-Bench 2.1, 1656 Elo auf GDPval-AA und 83,6 % auf MCP Atlas. Derselbe Beitrag sagt, dass Gemini 3.5 Pro intern läuft und für den Folgemonat geplant ist.

Schon diese eine bestätigte Bewegung erzeugt Druck. Wenn Flash die schnelle agentische Arbeitsschicht ist und Pro mit tieferem Reasoning folgt, müssen Teams entscheiden, welche Workloads wechseln, welche bleiben und welche ein Zwei-Modell-Muster brauchen. Support-Bot, Code-Review-Agent und Finanzworkflow dürfen nicht alle nach dem Prinzip "neuestes Modell gewinnt" geroutet werden.

Der unbestätigte Teil ist ebenfalls nützlich, solange er ehrlich behandelt wird. GPT-5.6 und Claude 4.8 sind Beobachtungssignale, keine Migrationsgrundlage. OpenAIs öffentliche Basis ist GPT-5.5, das für agentisches Coding, Computer Use, Recherche, Analyse, Dokumentenarbeit und mehrstufige Ausführung positioniert ist. Bei Anthropic sollten öffentliche Cloud-Listings die Produktionsbasis bleiben. Alles darüber gehört auf eine Watchlist, nicht in einen Produktivplan.

Diese Disziplin steckt auch in Anthropics nächste Welle: Unbestätigte Modellsignale können strategisch nützlich sein, solange Unternehmen "vorbereiten" und "versprechen" sauber trennen. KI-Modell-Routing-Governance macht diese Trennung operativ.

KI-Modell-Routing-Governance schlägt Benchmark-Jagd

Benchmarks sind gut, um Hypothesen einzugrenzen. Sie sind schlecht als Produktionspolitik. Ein Juni-Release kann ein Coding-Benchmark gewinnen und trotzdem euren Invoice-Parser verschlechtern, weil sich JSON-Disziplin oder Tool-Verhalten geändert haben. Ein Modell kann pro Token günstiger sein und pro erledigter Aufgabe teurer, weil es mehr Wiederholungen braucht.

KI-Modell-Routing-Governance beginnt mit einer einfachen Frage: Welche Entscheidung trifft der Router, und welche Evidenz darf diese Entscheidung beeinflussen? Die Antwort muss explizit sein. Routet nach Aufgabenklasse, Latenzbudget, Datenschutzstufe, Tool-Zugriff, gewünschtem Ausgabeformat, Eval-Score und Kostenobergrenze. Nicht nach Hype, Anbieterliebe oder dem letzten Keynote-Clip.

Eine praktische Policy kann festlegen: rechtliche Zusammenfassungen mit hohem Risiko bleiben beim intern bestbewerteten Modell mit Logging; UI-Generierung darf ein schnelleres Frontier-Modell nutzen, wenn visuelle QA Regressionen fängt; Langläufer-Agenten brauchen Checkpoints und Fallback; Klassifikation geht an das günstigste Modell, das die Präzisionsziele erfüllt.

Damit wird Agentisches Engineering ist kein Vibe Coding konkret. Agentisches Engineering behandelt Modellwahl als Infrastruktur. Das Modell ist eine Komponente in einem System aus Tests, Wiederholungen, Berechtigungen, Observability und Eskalation. Routing-Governance hält dieses System stabil, wenn Anbieter neue Versionen ankündigen.

Kostentelemetrie ist der Kontrollraum für Juni

Die Modellwelle ist auch eine Kostenwelle. Google positioniert Gemini 3.5 Flash als schnellen agentischen Motor. OpenAI beschreibt GPT-5.5 als Werkzeug für breitere autonome Arbeit über Tools hinweg. Anthropic steht weiterhin für hochwertige Reasoning- und Coding-Workflows. Gleichzeitig drücken günstigere Wettbewerber den Preisboden nach unten. Diese Mischung wird zur Routing-Frage, die Finance oft früher erkennt als Engineering.

Der Tokenpreis allein ist nicht die entscheidende Zahl. Wichtiger ist der Preis pro akzeptiertem Ergebnis. Bei Coding-Agenten bedeutet das Kosten pro gemergter Änderung, die Review besteht. Bei Research-Workflows sind es Kosten pro belegtem Briefing, das Fact-Checking übersteht. Im Support sind es Kosten pro gelöstem Fall ohne Eskalation.

Genau deshalb ist die ökonomische Perspektive aus Alibaba Qwen 3.7 Max lässt Opus teuer aussehen wichtig. Die Lehre lautet nicht "immer das billigste Modell wählen". Die Lehre lautet: Instrumentiert den Router so, dass jedes Modell seinen Platz rechtfertigen muss.

Mindest-Telemetrie umfasst Modellname und Version, Routing-Grund, Aufgabenklasse, Tokenzahlen, Tool Calls, Latenz, Retry-Zahl, Review-Ergebnis, finale Akzeptanz und Kostenschätzung. Besser wird es mit Drift-Alerts: Wenn die akzeptierte Ergebnisrate nach einem Anbieterupdate um 10 % fällt, sollte der Router warnen, bevor Rechnung oder Incident Report es tun.

Baut die Policy-Matrix vor den Releases

Eine Policy-Matrix ist ein kleines Artefakt mit großer Wirkung. Sie ordnet Workloads erlaubten Modellen, Fallbacks, Risikokontrollen und Messzielen zu. Engineering, Finance, Legal und Operations müssen sie lesen können. Wenn nur das AI-Team die Routing-Policy versteht, ist es noch keine Governance.

Startet mit vier Spalten: Workload, Primärroute, Fallback-Route und Blockerbedingungen. Ein Code-Agent kann ein Frontier-Coding-Modell als Primärroute nutzen, ein günstigeres Modell für Zusammenfassungen und ein Premium-Modell für Reviews, wenn Auth, Payments oder Datenlöschung betroffen sind. Ein Research-Agent kann ein schnelles Modell für Quellen-Clustering, ein stärkeres Modell für Synthese und danach einen deterministischen Citation-Check nutzen.

Dorthin gehört auch Vendor-Change-Control. Ein Juni-Modell darf nicht automatisch Produktionsstandard werden. Es kommt zuerst in eine Testspur, läuft gegen repräsentative Aufgaben, produziert einen Vergleichsbericht und wird nur dann befördert, wenn es die bestehende Route bei der relevanten Metrik schlägt: Akzeptanzrate, Latenz, Kosten pro akzeptierter Antwort, weniger Eskalationen, geringeres Halluzinationsrisiko oder bessere Tool-Zuverlässigkeit.

Dasselbe Prinzip steckt in Cursor Composer 2.5: Der Kosten-Gegenschlag. Schnellere und günstigere Coding-Modelle ändern Annahmen, aber sie ersetzen Routing-Disziplin nicht. Sie machen sie wichtiger, weil jede neue Option auch neue stille Fehler ermöglicht.

Ein 10-Tage-Migrationsdrill für die Juni-Welle

Der beste Schritt vor Juni ist nicht, den Gewinner vorherzusagen. Der beste Schritt ist, Modellwechsel zu üben.

Tag 1: Listet die Workflows, bei denen ein neues Modell realistisch etwas verändert: Coding-Agenten, Research-Synthese, Support-Triage, Dokumentenautomatisierung, Datenextraktion und interne Copiloten. Ohne Owner oder Metrik ist ein Workflow nicht bereit.

Tag 2 bis 3: Definiert das Eval-Set. Nutzt echte Aufgaben statt Spielzeugprompts. Enthaltet Edge Cases, Long-Context-Beispiele, schlechte Inputs, sensible Datenränder und Beispiele, bei denen die aktuelle Route scheitert.

Tag 4 bis 5: Führt Shadow Routing aus. Dieselbe Aufgabe geht an die bestehende Produktionsroute und an die Kandidatenroute. Verglichen werden Qualität, Latenz, Kosten, Wiederholungen und Review-Aufwand. Die Kandidatenroute schreibt in dieser Phase nicht in Produktionssysteme.

Tag 6 bis 7: Testet Fallbacks. Lasst einen Tool Call scheitern. Erzwingt einen Timeout. Ändert ein Schema. Entfernt eine Quelle. Ein Modell, das nur im Happy Path glänzt, ist für agentische Produktion nicht bereit.

Tag 8: Macht den Finance-Review. Übersetzt Tokens in Kosten pro akzeptiertem Ergebnis. Rechnet Review-Zeit, Fehlversuche und Nacharbeit ein. Wenn ein Modell nur vor Wiederholungen günstiger ist, ist es nicht günstiger.

Tag 9: Schreibt die Beförderungsregel. Beispiel: "Gemini 3.5 Pro wird für Research-Synthese nur befördert, wenn Quellenakzeptanz um 8 % steigt und die Kosten pro akzeptiertem Briefing maximal 15 % über der aktuellen Route liegen." Das ist eine Entscheidungsregel, kein Bauchgefühl.

Tag 10: Bereitet Rollback vor. Alte Route verfügbar halten, Prompts versionieren, Evals wiederholbar machen, Logs durchsuchbar halten. Wenn ein Anbieter Verhalten ändert, sollte der Rückweg Minuten dauern, nicht eine Woche Slack-Archäologie.

Das ist die Art Betriebssystem, die Käufer von einem AI-Partner erwarten sollten. Wie in KI-Consulting: Anthropic gegen OpenAI beschrieben, verschiebt sich der Markt von Demos zu verantwortbaren Operating Models. Modell-Routing-Governance gehört dazu.

Was Context Studios zuerst aufsetzen würde

Für einen Kunden, der sich auf die Juni-Welle vorbereitet, würde ich nicht mit einer Benchmark-Tabelle starten. Ich würde mit einem Routing-Ledger starten.

Der Routing-Ledger dokumentiert jede relevante AI-Entscheidung: Aufgabe, Modell, Version, Grund, Kosten, Output-Status, Review-Status und Fallback-Pfad. Sobald das existiert, kann ein Team experimentieren, weil jedes Experiment Evidenz hinterlässt. Ohne Ledger wird Modelladoption zu Folklore.

Das zweite Artefakt ist ein risikogestufter Modellkatalog. Tier-1-Modelle dürfen sensible Workflows berühren. Tier 2 bedient interne Produktivität und risikoarme Synthese. Tier 3 übernimmt günstige Extraktion, Brainstorming und Entwürfe. Experimentelle Modelle laufen nur im Shadow Mode. Der Katalog enthält Anbieter, Version, erlaubte und verbotene Use Cases, Kontextgrenzen, Datenhinweise, Stärken, Fehlerbilder und Owner.

Das dritte Artefakt ist ein Promotion Board. Jedes neue Modell startet als Kandidat. Es braucht Ziel-Workload, Eval-Set, Kostenhypothese, Risikoprüfung und Rollback. Wenn es gewinnt, bekommt es eine schmale Produktionsroute. Wenn es weiter gewinnt, wächst die Route. Wenn es regressiert, erklärt das Board den Rollback.

So verbindet man auch Codex-artige Agentenworkflows mit Modell-Governance. In OpenAI Codex 0.132: Strukturierter Resume für Agenten-Automation war Kontinuität der Kern: Agenten brauchen Zustand, Checkpoints und Wiederherstellbarkeit. Modell-Routing braucht dasselbe. Was sich nicht rekonstruieren lässt, lässt sich nicht steuern.

Die Juni-Welle kann Gemini 3.5 Pro, weitere OpenAI-Bewegung, weitere Anthropic-Bewegung und neuen Preisdruck bringen. Ein Teil ist öffentlich. Ein Teil bleibt Gerücht. Die Unternehmensregel bleibt gleich: Release-Geschwindigkeit darf operative Disziplin nicht überholen.

FAQ

Was ist KI-Modell-Routing-Governance?

KI-Modell-Routing-Governance ist das Regel-, Log-, Evaluations- und Ownership-System, das entscheidet, welches KI-Modell welche Aufgabe übernimmt. Es macht Modellwahl auditierbar.

Sollten Unternehmen sofort zu Gemini 3.5 Pro wechseln?

Nein. Unternehmen sollten Gemini 3.5 Pro zuerst in einer Shadow- oder Testspur prüfen und nur für Workloads befördern, in denen Qualität, Kosten, Latenz und Risiko besser sind.

Sind GPT-5.6 und Claude 4.8 bestätigte Releases?

Nicht aus den für diesen Beitrag geprüften öffentlichen Quellen. GPT-5.6 und Claude 4.8 sollten als Beobachtungssignale gelten; GPT-5.5 und Googles Gemini-3.5-Ankündigungen sind belastbarere öffentliche Baselines.

Welche Metrik zählt beim Modell-Routing am meisten?

Kosten pro akzeptiertem Ergebnis sind wichtiger als Tokenpreis. Ein Modell ist nur günstiger, wenn es Arbeit mit weniger Wiederholungen, weniger Review-Zeit und akzeptablem Risiko erledigt.

Was sollten Teams vor der Juni-Welle bauen?

Baut Routing-Ledger, risikogestufte Modellkataloge, wiederholbare Evals, Fallback-Routen und Beförderungsregeln. Damit lassen sich neue Modelle schnell, aber kontrolliert übernehmen.

Artikel teilen

Share: