Die meisten Unternehmen bauen ihre KI-Strategie bis heute um einen einzigen Anbieter herum. 2026 ist genau diese Konzentration zum größten Risiko geworden.
Ein einzelner Modellanbieter ist inzwischen ein Single Point of Failure. Das erste Halbjahr hat es vorgeführt: Eine Regierung hat ein Spitzenmodell abgeschaltet, mehrere Anbieter fielen aus und legten Produktivsysteme lahm, und ein US-Softwarehaus prüfte ernsthaft ein chinesisches Modell, um seine Agentenflotte bezahlbar zu halten. Wenn deine kritischen Geschäftsprozesse an einer einzigen KI-Quelle hängen, trägst du ein Konzentrationsrisiko, das von theoretisch zu dringend geworden ist.
Fünf Treiber hinter der Multi-Modell-Strategie
Anfangs sah „mehrere Modelle einsetzen“ nach einem reinen Spartrick aus: einfache Aufgaben an günstige Modelle, komplexe an die teuren Spitzensysteme. Diese Logik gilt weiterhin und spart weiterhin Geld. Die Begründung für eine Multi-Modell-Strategie ist inzwischen aber breiter. Fünf Treiber machen sie unverzichtbar, und jeder einzelne hat in diesem Jahr ein konkretes Beispiel geliefert.
Erstens Verfügbarkeit und Modellwechsel – der Treiber, der 2026 am meisten an Gewicht gewonnen hat. Dann die Kosten für den Betrieb von Agenten, die alles Bisherige übersteigen. Regulierung und Compliance verlangen in verschiedenen Märkten verschiedene Regeln. Souveränität und Rechtsraum spielen hinein: Wer kontrolliert den Zugang zum Modell? Und schließlich die schlichte Frage, welches Modell zu welcher Aufgabe am besten passt. Kostenersparnis ist längst nicht mehr das stärkste Argument.
Verfügbarkeit und Modellwechsel: Wenn der Anbieter zum Flaschenhals wird
KI ist in Produktivumgebungen angekommen – bekommt dort aber weniger Ausfallsicherheit zugestanden als eine Datenbank oder eine Cloud-Region. Die Zahlen belegen das: Eine Auswertung von über 400 Tagen Downdetector-Daten großer KI-Dienste zeigt einen Anstieg der Ausfalltage von sechs im ersten Quartal 2025 auf 51 im ersten Quartal 2026. Auf Anthropic mit Claude entfielen 39 dieser 51 Tage – nicht aus Nachlässigkeit, sondern weil das Unternehmen das stärkste Wachstum bei agentischen Coding-Aufgaben erlebte. Skalierungsspitzen treffen den am schnellsten wachsenden Anbieter. Nächstes Jahr ist es jemand anderes. Deshalb solltest du deine Architektur auf diese Realität auslegen, statt auf den „besseren“ Anbieter zu setzen.
Die veröffentlichten Verfügbarkeitswerte liegen bereits unter dem, was du von einem verwalteten Datenbankdienst erwartest. Modelle bei Hyperscalern haben erst seit Kurzem Service-Level-Agreements, und die bleiben deutlich hinter üblichen Unternehmenserwartungen zurück. Direkte APIs der Frontier-Labs bieten meist gar keine Zusage. Eine Service-Gutschrift für einen Ausfall ist keine Lösung für Geschäftskontinuität. Der Modellwechsel ist dabei die leisere Hälfte des Risikos: Anbieter nehmen ältere Versionen binnen Wochen vom Netz, während ein reguliertes Unternehmen Monate für die Revalidierung braucht. Ein Modell, das verschwindet, stoppt nicht eine Anwendung, sondern die gesamte Workflow-Kette und jeden angeschlossenen Geschäftsprozess.
Die architektonische Lehre ist eindeutig. Ein fest verdrahteter Endpunkt eines einzigen Anbieters war in der Anfangszeit vertretbar. 2026 ist er ein ernsthafter Single Point of Failure. Ein zweites Modell als Ausweichpfad macht aus einem Totalausfall einen eingeschränkten Betrieb. Für die kritischsten Prozesse planst du zusätzlich einen komplett KI-freien Rückfall – regelbasiert oder mit einem Menschen in der Schleife. Die eigentliche Frage lautet nicht, auf welches Modell du umschaltest, sondern was mit dem Geschäft passiert, wenn gar kein Modell verfügbar ist. Die Antwort ist eine zweistufige Strategie: Multi-Modell als erste Verteidigungslinie, bewusst gestalteter Notbetrieb als zweite. Nicht jeder Workflow braucht eine LLM-Abhängigkeit.
Slack liefert ein bemerkenswertes Beispiel. Nach drei Jahren mit AWS als einzigem Anbieter stellte das Unternehmen fest, dass selbst die regionale und anbieterweite Zuverlässigkeit eines einzelnen Hyperscalers nicht genügte. Es nahm Google Vertex AI als zweiten vollwertigen Anbieter mit automatischem Failover hinzu – ohne jeden Druck durch Compliance oder Souveränität. Die reine Verfügbarkeitslogik reichte aus.
Agentenkosten: Der Turbo für Multi-Modell-Routing
Agenten haben die Ökonomie der KI-Nutzung grundlegend verändert. Ein Chatbot beantwortet eine Anfrage und hört auf. Ein Agent plant, liest, ruft Werkzeuge auf, versucht es erneut und verbraucht dabei durchgehend Token – auch dann noch, wenn der Nutzer längst weitergezogen ist. Eine gemeinsame Studie von Microsoft Research und dem Stanford Digital Economy Lab hat es gemessen: Agentische Coding-Aufgaben verbrauchen etwa tausendmal so viele Token wie klassischer Code-Chat. Die Streuung zwischen zwei Durchläufen derselben Aufgabe erreicht das Dreißigfache – und diese Schwankung sprengt ein Budget zuverlässiger als der absolute Verbrauch.
Die Rechnungen kamen mit voller Wucht. Uber hat sein gesamtes KI-Budget für 2026 in vier Monaten aufgebraucht, nachdem es Claude Code und Cursor an 5.000 Entwickler ausgerollt hatte. Danach führte das Unternehmen eine Obergrenze von 1.500 Dollar pro Entwickler und Monat ein. Die Botschaft ist deutlich: Eine pauschale Lizenz pro Arbeitsplatz überlebt diese Last nicht. Die Branche bewegt sich bei Agenten auf verbrauchsabhängige Abrechnung zu.
Microsoft ist der jüngste Beleg. Das Unternehmen hat seinen Enterprise-Agenten auf verbrauchsabhängige Preise umgestellt und angekündigt, neben den bestehenden Premium-Anbietern ein günstigeres Modell zu prüfen. Das ist kein politisches Signal, sondern ein architektonisches. Agenten mit hohem Volumen laufen auf einer Mischung von Modellen, ausgewählt nach Kosten und Aufgabe: Routinearbeit auf günstigen Maschinen, anspruchsvolles Schlussfolgern auf Spitzenmodellen. Microsoft hätte bei einem Anbieter bleiben können – der Kostendruck hat das Routing über mehrere Modelle zur besseren Alternative gemacht.
Compliance und Souveränität: Zwei Seiten derselben Medaille
Ein global tätiges Unternehmen sieht sich nicht einem Regelwerk gegenüber, sondern vielen, die sich teilweise widersprechen. Der EU AI Act wirkt extraterritorial – auch für Unternehmen außerhalb der EU, die dort Marktteilnehmer bedienen. Die Fristen haben sich dieses Jahr verschoben: Der Digital Omnibus hat die schweren Hochrisiko-Pflichten auf Ende 2027 und 2028 vertagt, während Transparenz- und Kennzeichnungspflichten kurzfristig in Kraft bleiben. Dazu kommen sektorale Regeln für Finanzwesen, Gesundheit und den öffentlichen Sektor sowie unterschiedliche Anforderungen an den Speicherort der Daten. Kein einzelner Anbieter erfüllt alle Regime gleichzeitig, die dein Geschäft berühren – eine Multi-Modell-Aufstellung ist der einzige Weg, über Märkte hinweg zu arbeiten, ohne die Plattform neu zu bauen.
Der zweite Teil ist die Souveränität. Der größte Bruch des Jahres kam im Juni: Die US-Regierung untersagte Anthropic über Exportkontrollen der nationalen Sicherheit, seine beiden leistungsfähigsten Modelle (Fable 5 und Mythos 5) an ausländische Staatsangehörige auszuliefern. Das Unternehmen musste diese Modelle daraufhin für alle Nutzer abschalten, während andere Modelle online blieben. Nach 19 Tagen kehrte der Zugang mit neuen Beschränkungen zurück. Überleg dir, was das bedeutet. Ein Modell, das am Freitag verfügbar war, war am Samstag weg – per Regierungsentscheidung, nicht weil der Anbieter einen Fehler gemacht hätte. Am Speicherort der Daten hätte sich dadurch keine Minute lang etwas geändert.
Die EU reagierte institutionell. Im Juli veröffentlichte die Europäische Kommission einen Aktionsplan für KI-Sicherheit mit Notfallmaßnahmen bis Ende 2026 für den Fall, dass ein Drittstaat den Zugang zu kritischen KI-Fähigkeiten kappt. Wenn Regulierer anfangen, Notfallpläne für solche Szenarien zu schreiben, ist das Risiko von der Konferenzbühne in die amtliche Politik gewandert. Chinesische Modelle tragen dieselbe Risikokategorie, nur in die andere Richtung. Jedes Modell, dessen Fortbestand von der Rechtsmacht eines einzelnen Staates abhängt, ist ein Konzentrationsrisiko – unabhängig von der Flagge. Die Lösung ist dieselbe wie bei allen anderen Treibern: Halte eine souveräne oder offene Option auf Infrastruktur am Laufen, die du selbst kontrollierst.
Das passende Modell für jede Aufgabe
Kein Modell führt in allem gleichzeitig. Eines glänzt bei langen Kontexten, ein anderes bei niedriger Latenz, ein drittes beim strukturierten Schlussfolgern, ein viertes bei Code. Latenz- und datenschutzkritische Schritte gehören oft auf ein kleines Modell direkt auf dem Gerät oder im eigenen Rechenzentrum. Erst wenn die Aufgabe es wirklich verlangt, sollte ein Spitzenmodell ins Spiel kommen. Diese Routing-Strategie senkt den Zugriff auf teure große Modelle spürbar, ohne dass die Qualität leidet.
Cursor liefert dazu einen überzeugenden Praxisfall. In einer Agentensimulation bauten vier verschiedene Modellkonfigurationen SQLite aus einem 835-seitigen Handbuch in Rust nach – ohne Quellcode, ohne Tests, ohne Internetzugang. Am Ende bestanden alle Konfigurationen die vollständige Testsuite, die Kosten unterschieden sich jedoch erheblich. Genau darum geht es: Mit einer durchdachten Modellmischung erreichst du dasselbe Ergebnis zu einem Bruchteil der Kosten.
Alle fünf Treiber zusammen machen eine umfassende Multi-Modell-Strategie unausweichlich. Wer bei einem einzigen Anbieter bleibt, nimmt eine Verfügbarkeitslotterie in Kauf, dazu die Kostenfalle bei Agenten, rechtliche Grauzonen, staatlichen Zugriff und eine Leistung, die für die jeweilige Aufgabe selten die beste ist. Die gute Nachricht: Die Werkzeuge sind da. Eine Orchestrierungsschicht, die Anfragen über Modelle verteilt, ein Failover-Mechanismus, der bei Ausfall automatisch umschaltet, und ein Portfolio aus gehosteten APIs und selbst betriebenen offenen Modellen sind inzwischen Standard. Wer das ignoriert, lernt die Lektion von 2026 auf die teure Art: durch einen Ausfall, den kein SLA abdeckt.
Quelle: kai-waehner.de
