Die Multi-Cloud-KI-Falle für CIOs

Google News hat eine deutliche Warnung für CIOs aufgegriffen: Multi-Cloud-KI kann zwar Flexibilität versprechen, zugleich aber eine kostspielige Integrationsfalle schaffen. Der Bericht von InformationWeek stellt eine vertraute Strategie infrage, die Dienste von Google Cloud, Amazon Web Services, Microsoft Azure und spezialisierten KI-Anbietern kombiniert.

Die Attraktivität ist leicht nachzuvollziehen. Ein Anbieter kann das bevorzugte Modell bereitstellen, während ein anderer kritische Daten vorhält oder eine bessere regionale Abdeckung bietet. Eine dritte Plattform unterstützt möglicherweise bereits die Identitäts-, Analyse- oder Anwendungslandschaft des Unternehmens.

Der Konflikt beginnt, wenn diese Entscheidungen über isolierte Pilotprojekte hinausgehen. Jede zusätzliche Cloud bringt ein weiteres Identitätssystem, Richtlinienmodell, einen weiteren Datenpfad, eine Monitoring-Ebene und eine Abrechnungsstruktur mit sich. CIOs stehen dann vor der Wahl zwischen breitem Zugang zu KI-Diensten und einer Architektur, die ihre Teams steuern können.

Dabei handelt es sich nicht nur um eine weitere Warnung vor Cloud-Ausgaben. KI-Anwendungen kombinieren fortlaufend Modelle, Prompts, private Daten, Vektorindizes, Tools und automatisierte Aktionen. Ihre Abhängigkeiten überschreiten Systemgrenzen deutlich häufiger als die einer herkömmlichen Webanwendung.

Google Cloud, AWS und Microsoft bewerben allesamt Dienste, die Enterprise-KI einfacher bereitstellbar machen sollen. Dennoch unterscheiden sich ihre Plattformen bei Modellschnittstellen, Berechtigungen, Observability, Netzwerken und verwalteten Datendiensten. Diese Unterschiede machen Portabilität von einem Beschaffungsversprechen zu einem Engineering-Projekt.

Der zentrale Konflikt ist daher klar. Die Best-of-Breed-Auswahl einer Multi-Cloud-Strategie trifft auf die betriebliche Realität fragmentierter Infrastruktur. Je mehr KI-Komponenten ein Unternehmen verteilt, desto schwieriger wird es nachzuvollziehen, wie Informationen fließen und wer jede Entscheidung kontrolliert.

Google News zeigt den Wandel von Cloud-Auswahl zu KI-Abhängigkeit

Die wichtige Veränderung besteht nicht darin, dass Unternehmen mehrere Clouds nutzen. KI verbindet diese Clouds nun durch dauerhafte Daten- und Betriebsabhängigkeiten.

Jahrelang betrachteten Unternehmen die Einführung von Multi-Cloud als Möglichkeit, ihre Verhandlungsposition zu wahren und passende Dienste auszuwählen. Workloads konnten dabei vergleichsweise eigenständig bleiben. Ein Team konnte eine Anwendung auf AWS hosten, während ein anderes Microsoft Azure für ein separates Geschäftssystem nutzte.

Enterprise-KI schwächt diese Trennung. Eine einzelne Anwendung kann Dokumente aus einer Umgebung abrufen, ein Modell in einer anderen aufrufen und Ergebnisse in einen Workflow eines Drittanbieters senden. Sie kann außerdem eine externe Evaluierungsplattform und einen separaten Sicherheitsdienst nutzen.

Jede Interaktion wird Teil des Produktionspfads der Anwendung. Ein Fehler bei Identitätsföderation, Datensynchronisierung, Netzwerkverbindungen oder Modellzugriff kann die endgültige Antwort beeinträchtigen. Herkömmliches Uptime-Monitoring zeigt nicht immer, welche Komponente eine schwache oder unsichere Antwort verursacht hat.

Die Infrastrukturstudie von Google Cloud verdeutlicht das Ausmaß des Wandels. Für seinen Bericht 2026 befragte das Unternehmen 1.402 globale IT-Führungskräfte. Demnach nutzen 52 % der antwortenden Organisationen eine hybride Multicloud-Architektur.

Der Bericht besagt außerdem, dass 83 % Infrastruktur-Upgrades benötigen, um autonome Systeme auf Produktionsniveau zu unterstützen. Vier von fünf Befragten nannten Sicherheit, Governance oder MLOps als bedeutende Herausforderung. MLOps umfasst die Prozesse zur Bereitstellung, Überwachung und Verwaltung von Machine-Learning-Systemen.

Diese Ergebnisse stammen von einem Cloud-Anbieter, der ein Interesse an Infrastrukturinvestitionen hat. Sie sollten nicht als neutraler Beleg dafür verstanden werden, dass jedes Unternehmen einen umfassenden Neuaufbau benötigt. Sie zeigen jedoch, wie Infrastrukturanbieter die Hürde für den Produktionseinsatz einordnen.

Mit KI-Agenten wird diese Hürde folgenreicher. Ein Agent ist Software, die ein Modell nutzt, um Aktionen zur Erreichung eines Ziels auszuwählen und auszuführen. Er kann Datensätze lesen, Geschäftsanwendungen aufrufen, Dokumente erstellen oder operative Systeme aktualisieren.

Ein Chatbot kann scheitern, indem er eine wenig hilfreiche Antwort liefert. Ein Agent kann scheitern, indem er über verbundene Systeme hinweg die falsche Aktion ausführt. Das erhöht die Bedeutung konsistenter Berechtigungen, Audit-Datensätze und Richtliniendurchsetzung über jede beteiligte Cloud hinweg.

Das ursprüngliche Multi-Cloud-Versprechen konzentrierte sich stark darauf, die Abhängigkeit von einem einzelnen Anbieter zu vermeiden. KI verändert die Einheit der Abhängigkeit. Eine Organisation kann die ausschließliche Abhängigkeit von einer Cloud vermeiden und dennoch von einem maßgeschneiderten Geflecht inkompatibler Dienste abhängig werden.

Dieses Geflecht lässt sich schwerer ersetzen als ein einzelnes Managed Product. Sein Verhalten erstreckt sich über Konnektoren, Transformationen, Zugriffsrichtlinien, Routing-Regeln und das Wissen der Teams. Anbieterunabhängigkeit kann daher zu Architekturabhängigkeit führen.

Die Berichterstattung von Google News ist relevant, weil die Warnung zu einem Zeitpunkt kommt, an dem Unternehmen von Demonstrationen zu operativen Workflows übergehen. Pilotprojekte tolerieren manuelle Eingriffe und eng begrenzte Datensätze. Produktionssysteme müssen mit sich ändernden Berechtigungen, Modellversionen, Ausfällen, Compliance-Regeln und unerwartetem Nutzerverhalten umgehen.

Es geht nicht länger darum, ob mehrere Modelle hilfreiche Antworten erzeugen können. CIOs müssen entscheiden, ob die gesamte Kette verständlich bleibt, wenn Hunderte Teams beginnen, ihre eigenen Daten und Tools zu verbinden.

KI-Druck zwingt CIOs zur Integration, bevor sie standardisieren

CIOs werden dazu gedrängt, sichtbare KI-Ergebnisse zu liefern, während die für eine sichere Skalierung erforderlichen Architekturstandards noch nicht feststehen.

Vorstände und Geschäftsverantwortliche erwarten zunehmend, dass Technologieverantwortliche KI-Investitionen in messbare operative Verbesserungen umsetzen. Geschäftsbereiche wollen nicht auf ein mehrjähriges Programm zur Datenmodernisierung warten. Sie können Modellzugang und Automatisierungstools bereits direkt erwerben.

Dieser Druck begünstigt lokale Optimierung. Ein Produktteam wählt das Modell, das für seinen Anwendungsfall die beste Leistung liefert. Eine regionale Gruppe entscheidet sich für einen Anbieter, der lokale Hosting-Anforderungen erfüllt. Ein übernommenes Unternehmen behält den Cloud-Stack, den es bereits betreibt.

Jede Entscheidung kann für sich genommen vernünftig sein. Die zusammengefügte Architektur kann dennoch unbeherrschbar werden.

CIO-Berichte zur Cloud-Strategie beschreiben das Problem ähnlich. Technologieverantwortliche müssen heute KI-Bereitschaft mit Cybersicherheit, Data Governance, Souveränität, Edge Computing, Integrationsarchitektur und operativer Resilienz in Einklang bringen. Diese Aspekte betreffen dieselben Workloads und sind keine getrennten Planungsaufgaben.

KI erweitert zudem die Zahl der Stakeholder, die an Cloud-Entscheidungen beteiligt sind. Sicherheitsteams benötigen klare Kontrollen über den Datenzugriff. Rechtsabteilungen müssen wissen, welche Informationen ein Modell erreichen und wo die Verarbeitung stattfindet.

Finanzteams brauchen vorhersehbare Verbrauchs- und Transferkosten. Datenverantwortliche müssen Qualität, Herkunft und Aufbewahrungsregeln sicherstellen. Anwendungsverantwortliche erwarten weiterhin akzeptable Latenz und Zuverlässigkeit.

Ein Multi-Cloud-Design verteilt diese Zuständigkeiten auf unterschiedliche Control Planes. Eine Control Plane ist das System, mit dem Ressourcen, Berechtigungen, Richtlinien und Betriebsabläufe konfiguriert werden. Jeder Anbieter verwendet andere Begriffe und Durchsetzungspunkte.

Derselbe Mitarbeiter kann daher über mehrere Identitätszuordnungen Zugriff erhalten. Eine Richtlinie, die sensible Daten in einer Umgebung blockiert, deckt möglicherweise einen Modell-Endpunkt an anderer Stelle nicht ab. Protokolle können für denselben Nutzer oder Workload unterschiedliche Kennungen erfassen.

Google berichtete zuvor, dass 81 % der befragten Organisationen bei der Portabilität von Anwendungen und Daten über Cloud-, Rechenzentrums- und Edge-Standorte hinweg auf Herausforderungen stießen. Die Multicloud-Umfrage des Unternehmens ergab zudem, dass 39 % KI-Workloads als einen Hauptgrund für die Nutzung alternativer Anbieter nannten.

Der Zusammenhang ist aufschlussreich. KI treibt Organisationen zu zusätzlichen Clouds, während Portabilität weiterhin zu den häufigsten Schwierigkeiten der Architektur gehört. Der Dienst, der ein Unternehmen zu einem zweiten Anbieter bewegt, kann den Integrationsaufwand für seine Nutzung erhöhen.

Geschäftsbereiche sehen möglicherweise nur den Modell-Endpunkt. Plattformteams müssen Netzwerkrouten, Zugangsdaten, Verschlüsselungsschlüssel, Datenformate, Nutzungslimits, Monitoring und Incident Response verwalten. Sie benötigen außerdem einen Prozess für Modellaktualisierungen und die Einstellung von Diensten.

Dieses Ungleichgewicht setzt CIOs von beiden Seiten unter Druck. Zentrale Kontrolle kann Experimente verlangsamen und nicht autorisierte Tools fördern. Unbeschränkte Experimente können doppelte Plattformen und verborgene Datenflüsse hervorbringen.

Die notwendige Antwort besteht nicht einfach in höheren Ausgaben. CIOs müssen festlegen, wo Vielfalt geschäftlichen Mehrwert schafft und wo Standardisierung Risiken reduziert. Das erfordert Entscheidungen über zugelassene Modelle, gemeinsame Datenschichten, Identitätsmuster, Evaluierungsmethoden und Zuständigkeiten.

Diese Entscheidungen sind schwierig, weil sich der Markt ständig weiterentwickelt. Ein heute wegen seiner Leistung ausgewähltes Modell kann nach der nächsten Veröffentlichung seinen Vorteil verlieren. Eine Managed-Funktion, die Entwicklungszeit spart, kann eine stärkere Abhängigkeit von ihrem Anbieter schaffen.

Die daraus resultierende Unsicherheit fördert Abstraktionsschichten, die Anbieter austauschbar machen sollen. Solche Schichten können helfen, führen jedoch zugleich einen weiteren Dienst ein, den Teams betreiben müssen. Abstraktion beseitigt Komplexität nicht, wenn sich die zugrunde liegenden Fähigkeiten weiterhin wesentlich unterscheiden.

Der Druck ist unmittelbar, die Folgen sind langfristig. Eine Pilotintegration kann innerhalb weniger Monate zu einer Produktionsabhängigkeit werden. Sobald Mitarbeiter darauf aufbauende Workflows entwickeln, betrifft ein Austausch Prozesse, Schulungen und historische Daten.

CIOs wählen daher nicht nur zwischen Clouds. Sie entscheiden, welche Unterschiede ihre Organisationen als dauerhafte betriebliche Verpflichtungen tragen werden.

Best-of-Breed-KI wird zur Integrationssteuer

Multi-Cloud-KI schafft nur dann Mehrwert, wenn der Nutzen jedes spezialisierten Dienstes die fortlaufenden Kosten seiner Anbindung und Steuerung übersteigt.

Best-of-Breed-Beschaffung setzt voraus, dass Unternehmen für jede Anforderung die stärkste Komponente auswählen können. Eine Cloud kann geeignete Beschleuniger bereitstellen. Eine andere kann ein bevorzugtes Foundation Model anbieten, also ein allgemeines Modell, das für viele nachgelagerte Aufgaben angepasst wird.

Ein dritter Anbieter kann die Datenbanken der Organisation hosten. Unabhängige Anbieter können Retrieval, Modellrouting, Evaluierung, Observability und Sicherheit liefern. Auf dem Papier entsteht so ein flexibler Stack mit weniger Kompromissen bei einem einzelnen Anbieter.

In der Praxis erzeugt jede Grenze eine Integrationssteuer. Dazu zählen Engineering-Zeit, Datenbewegungen, doppelte Kontrollen, Tests, Incident-Koordination und spezialisiertes Fachwissen. Sie bleibt auch nach der ersten Bereitstellung bestehen.

Daten liefern das deutlichste Beispiel. Ein Modell benötigt relevanten Geschäftskontext, um nützliche Ergebnisse zu erzeugen. Dieser Kontext kann in Dokumenten, Datenbanken, Nachrichten, Tickets, Kundensystemen und operativen Datensätzen liegen.

Alle diese Informationen in eine Cloud zu verschieben, schafft Governance- und Aktualitätsprobleme. Sie verteilt zu lassen, erfordert Retrieval-Systeme, die sich über Quellen hinweg authentifizieren und Zugriffsregeln bewahren können. Beide Optionen haben betriebliche Folgen.

Retrieval-Augmented Generation, meist RAG genannt, versorgt ein Modell vor seiner Antwort mit ausgewählten Informationen. Eine RAG-Pipeline kann in einer Demonstration einfach wirken. Der Produktionseinsatz erfordert Dokumentenparsing, Indizierung, Berechtigungen, Aktualisierungen, Löschbehandlung, Ranking, Evaluierung und Monitoring.

Die Verteilung dieser Komponenten über mehrere Anbieter hinweg erschwert die Ursachenanalyse. Eine schlechte Antwort kann vom Modell, einem veralteten Index, einem ausgefallenen Konnektor, fehlenden Berechtigungen oder einer Änderung des Rankings verursacht werden. Jedes Team kann nur für einen Abschnitt zuständig sein.

Unternehmen kämpfen bereits außerhalb von KI mit dieser Fragmentierung. Gartner berichtete, dass 85 % der befragten Unternehmen Daten- und Analyseanwendungen über mehrere Clouds hinweg bereitgestellt hatten. Nur 30 % dieser Gruppe verfügten nach eigenen Angaben über fortgeschrittene Funktionen für cloudübergreifende Daten und Analysen.

Die Gartner-Ergebnisse stammen aus einer Umfrage, die vor der aktuellen Welle produktiver KI-Agenten durchgeführt wurde. Sie legen nahe, dass viele Unternehmen in die KI-Expansion mit Multi-Cloud-Landschaften starteten, deren Umfang ihre Integrationsreife bereits überstieg.

KI erhöht den Einsatz, weil das Verhalten von Anwendungen zugleich von Datenqualität und Modellausgabe abhängt. Eine herkömmliche Integration ordnet in der Regel bekannte Felder zwischen Systemen zu. Eine KI-Pipeline führt probabilistische Antworten ein, sodass dieselbe Anfrage unterschiedliche Ergebnisse liefern kann.

Teams müssen sowohl Infrastruktur als auch Ausgabequalität bewerten. Sie müssen wissen, ob eine Anfrage das vorgesehene Modell erreicht hat, die richtigen Daten verwendete, Richtlinien befolgte und eine akzeptable Antwort erzeugte. Diese Nachweise müssen über Anbietergrenzen hinweg erhalten bleiben.

Das Model-Routing bringt eine weitere Komplikation hinzu. Ein Router kann Anfragen abhängig von Kosten, Geschwindigkeit, Verfügbarkeit oder Aufgabentyp an unterschiedliche Modelle senden. Dieser Ansatz verringert die Abhängigkeit von einem einzelnen Modell, erschwert jedoch Tests und Verantwortlichkeit.

Verschiedene Modelle interpretieren Prompts unterschiedlich. Sie bieten unterschiedliche Formate für Tool-Aufrufe, Kontextgrenzen, Sicherheitskontrollen und regionale Verfügbarkeit. Ein Fallback-Modell kann eine Anwendung online halten, während sich Qualitäts- oder Compliance-Eigenschaften seiner Antworten verändern.

Echte Portabilität erfordert daher mehr als das Ändern einer API-Adresse. Teams müssen Prompts, Tools, Bewertungen, Inhaltskontrollen, Protokollierung und Fehlerbehandlung vereinheitlichen. Diese Arbeit müssen sie wiederholen, sobald ein Anbieter seine Schnittstelle oder das Verhalten seines Modells ändert.

Auch die Architektur für Datenübertragungen ist wichtig. Das Verschieben großer Datensätze oder wiederholter Inferenzkontexte zwischen Clouds kann Latenz und nutzungsabhängige Kosten erhöhen. Selbst wenn diese Kosten während Tests akzeptabel erscheinen, können sie nach einer breiten Einführung bei Mitarbeitenden schnell steigen.

Eine eng gefasste Best-of-Breed-Entscheidung kann dennoch sinnvoll sein. Ein spezialisiertes Modell kann beim Programmieren, bei der Dokumentenanalyse oder in wissenschaftlicher Arbeit einen bedeutenden Vorteil liefern. Regionale Dienste können zudem Anforderungen an Datenresidenz oder Latenz erfüllen, die ein einzelner Anbieter nicht abdecken kann.

Die Falle entsteht, wenn Unternehmen Wahlfreiheit mit kostenloser Austauschbarkeit verwechseln. Zugang zu mehreren Clouds ist nicht dasselbe wie die Fähigkeit, Workloads sicher zwischen ihnen zu verlagern. Jeder zusätzliche Pfad benötigt klare Verantwortung und einen Nachweis seines Nutzens.

CIOs sollten Anbietervielfalt als begrenzte Ressource behandeln. Ein neuer Dienst muss nicht nur seine unmittelbare Fähigkeit rechtfertigen, sondern auch die Integrationsfläche, die er schafft. Diese Fläche bleibt bestehen, nachdem der Neuheitswert des Dienstes verblasst ist.

Teams benötigen außerdem belastbare Aufzeichnungen architektonischer Entscheidungen. Eine durchsuchbare technische Wissensdatenbank kann Verantwortlichkeiten, Abhängigkeiten und operativen Kontext bewahren. Dokumentation allein kann Fragmentierung nicht beheben, doch fehlender Kontext verlangsamt jeden Vorfall.

Gemeinsame Plattformen reduzieren Komplexität, beseitigen aber keine Cloud-Unterschiede

Eine gemeinsame Betriebsebene kann die Vielfalt der Infrastruktur steuern, doch sie kann proprietäre KI-Dienste nicht wirklich austauschbar machen.

Platform Engineering bietet eine Antwort auf Multi-Cloud-KI. Ein zentrales Team schafft genehmigte Wege für Anwendungsteams, darunter Bereitstellungsvorlagen, Identitätsmuster, Monitoring und Richtlinienkontrollen. Entwickler nutzen diese Wege, statt jede Verbindung eigenständig zusammenzustellen.

Kubernetes unterstützt diese Strategie häufig. Es orchestriert containerisierte Anwendungen über Infrastrukturumgebungen hinweg. Die Cloud Native Computing Foundation berichtete in ihrer Umfrage von 2026, dass 82 % der Container-Nutzer Kubernetes produktiv einsetzten.

Die CNCF-Umfrage beschreibt Kubernetes als gemeinsame Betriebsebene für cloudnative und KI-Systeme. Diese Positionierung spiegelt einen echten Vorteil wider. Container können Teile einer Anwendung über Clouds und private Infrastruktur hinweg konsistenter machen.

Kubernetes standardisiert jedoch nicht jede verwaltete KI-Fähigkeit. Ein proprietärer Modelldienst, eine Vektordatenbank, ein Identitätsprodukt oder ein Data Warehouse weist weiterhin anbieterspezifisches Verhalten auf. Das Verschieben von Anwendungscode verschiebt nicht automatisch dessen Daten und Betriebskontrollen.

Offene Modellschnittstellen können einige Reibungen reduzieren. Standardisierte APIs ermöglichen es Anwendungen, mehrere Modelle über ein gemeinsames Anfragemuster anzusprechen. Open-Source-Inferenzsoftware kann zudem dieselben Modellgewichte auf unterschiedlicher Infrastruktur ausführen.

Diese Ansätze schaffen Wahlmöglichkeiten, verlagern die Verantwortung jedoch auf das Unternehmen. Teams müssen Kapazitäten, Upgrades, Sicherheitskorrekturen, Performance-Tuning und Model Governance betreiben. Portabilität wird zu einer internen Fähigkeit statt zu einem eingekauften Merkmal.

Eine gemeinsame Datenschicht bietet eine weitere Option. Unternehmen können einen gesteuerten Zugang zu Informationen unabhängig von einzelnen Modellanbietern aufrechterhalten. Anwendungen verbinden dann genehmigte Modelle mit denselben richtlinienbewussten Datendiensten.

Diese Architektur begrenzt unkontrollierte Replikation. Sie konzentriert jedoch auch Risiken in der gemeinsamen Schicht. Schlechte Metadaten, fehlende Berechtigungen oder ein nicht verfügbarer Gateway können jede KI-Anwendung beeinträchtigen, die davon abhängt.

Zentrale Durchsetzung von Identität und Richtlinien ist ebenso wichtig. SANS stellte fest, dass 55 % der Befragten in seiner Multi-Cloud-Umfrage von 2023 mehrere Single-Sign-On-Lösungen nutzten. Nur 14 % gaben an, auf eine einzelne Lösung hinzuarbeiten.

Die SANS-Analyse stellte zudem eine erhebliche Zersplitterung von Konten fest. Sechzehn Prozent der Befragten nutzten mehr als 100 AWS-Konten, während 12 % mehr als 100 Azure-Abonnements und Google Cloud-Konten nutzten.

KI-Dienste, die über diese Landschaft hinweg geschichtet sind, können inkonsistente Berechtigungen übernehmen. Ein Modell kann umfassenden Zugriff erhalten, weil seine Dienstidentität nicht sauber bestehenden Benutzerberechtigungen zugeordnet wird. Ein Connector kann außerdem seinen Zugriff behalten, nachdem ein Mitarbeiter die Rolle gewechselt hat.

Zentrale Governance sollte daher dem Benutzer, den Daten, dem Modell und der Aktion folgen, statt nur dem Cloud-Konto. Teams benötigen ein Inventar, das jeden KI-Anwendungsfall mit einem Verantwortlichen, genehmigten Daten, bereitgestellten Modellen, Bewertungsergebnissen und Betriebskontrollen verknüpft.

Dieses Inventar darf keine statische Tabelle bleiben. KI-Konfigurationen ändern sich zu häufig, und Infrastrukturressourcen entstehen durch Automatisierung. Governance benötigt maschinenlesbare Richtlinien und kontinuierlich erhobene Nachweise.

Auch Observability muss Clouds übergreifen. Teams sollten Anwendungstraces, Modellanfragen, Retrieval-Ereignisse, Tool-Aufrufe, Richtlinienentscheidungen und Geschäftsergebnisse verbinden. Ein Trace ist ein verknüpfter Datensatz, der zeigt, wie sich eine Anfrage durch ein verteiltes System bewegt hat.

Ohne diese Verbindung liefern Infrastruktur-Dashboards nur Teilantworten. Ein Anbieter kann eine erfolgreiche Modellanfrage anzeigen, obwohl der gesamte Workflow veraltete Informationen zurückgab. Ein anderer kann einen blockierten Tool-Aufruf erfassen, ohne den vorgelagerten Prompt zu erklären.

Gemeinsame Plattformen verringern die Zahl der Muster, die Teams unterstützen müssen. Sie sind erfolgreich, wenn sie genehmigte Aktionen einfacher machen als improvisierte. Eine Plattform, die Formulare und Verzögerungen ohne nützliche Automatisierung hinzufügt, wird Entwickler zum direkten Anbieterzugang treiben.

Das Ziel ist nicht überall identische Infrastruktur. Es ist eine kontrollierte Zahl von Unterschieden mit expliziten Verantwortlichen. CIOs sollten anbieterspezifische Dienste nur dort beibehalten, wo diese Dienste einen messbaren Vorteil schaffen.

Dieser Ansatz akzeptiert einen gewissen Lock-in. Das ist oft ehrlicher, als zu behaupten, dass jeder KI-Workload portabel bleibt. Die relevante Frage ist, ob die Abhängigkeit beabsichtigt, sichtbar und zu akzeptablen Kosten reversibel ist.

Die Sicherheits- und Governance-Lücke ist am schwersten zu testen

Das größte Multi-Cloud-KI-Risiko ist kein dramatischer Ausfall. Es besteht darin, die Fähigkeit zu verlieren, zu erklären, welche Daten, welches Modell, welche Identität und welche Richtlinie eine Aktion geprägt haben.

Sicherheitsteams verwalten seit Langem Unterschiede bei Cloud-Berechtigungen, Netzwerken und Protokollen. KI führt Prompts, abgerufenen Kontext, modellgenerierte Inhalte und autonome Tool-Aufrufe ein. Jedes Element kann sensible Informationen über Systemgrenzen hinweg transportieren.

Ein Prompt kann Kundendaten oder interne Strategien enthalten. Ein Retrieval-Dienst kann Passagen aus mehreren Repositories zusammenstellen. Ein Modellanbieter kann diesen Kontext in einer anderen Region oder unter separaten Aufbewahrungsbedingungen verarbeiten.

Die Anwendung kann ihre Antwort anschließend an E-Mail, Quellcodeverwaltung, Finanzsoftware oder ein Kundensystem senden. Eine einzelne Anfrage kann mehrere administrative Domänen durchlaufen, bevor jemand das endgültige Ergebnis sieht.

Herkömmliche Zugriffskontrolle prüft, ob eine Identität eine Ressource aufrufen darf. KI-Governance muss zudem berücksichtigen, ob ein Anwendungsfall bestimmte Daten mit einem Modell kombinieren sollte. Sie muss bewerten, welche Aktionen das Modell empfehlen oder ausführen kann.

Diese Unterscheidung erschwert die Übersetzung von Richtlinien. Google Cloud, AWS, Azure und private Umgebungen stellen separate Richtlinien-Engines bereit. Eine für eine Plattform formulierte Einschränkung deckt einen gleichwertigen Dienst an anderer Stelle nicht automatisch ab.

Dieselbe Inkonsistenz betrifft Audit-Nachweise. Regulierungsbehörden und interne Prüfer können fragen, welche Modellversion einen Datensatz verarbeitet hat, welchen Kontext sie erhielt und warum ein Tool ausgeführt wurde. Die Bereitstellung dieser Historie erfordert abgestimmte Protokolle mit kompatiblen Kennungen und Aufbewahrungsfristen.

Die Modellbewertung führt eine weitere Lücke ein. Teams testen, ob ein Modell für eine definierte Aufgabe genau, sicher und zuverlässig ist. Ein bestandenes Ergebnis gilt für eine spezifische Konfiguration, einschließlich Prompts, Retrieval-Einstellungen, Tools und Modellversion.

Ein Wechsel des Anbieters oder Fallback-Modells kann diese Nachweise entkräften. Selbst ein anbieterseitiges Modellupdate kann das Verhalten verändern, ohne die umgebende Anwendung zu ändern. Multi-Cloud-Routing vervielfacht die Konfigurationen, die bewertet werden müssen.

CIOs sollten auch Anbieterbehauptungen über einheitliche Kontrolle hinterfragen. Ein Dashboard kann Ressourcen aggregieren, ohne identische Richtlinien durchzusetzen. Ein Connector kann Aktivitäten anzeigen, während wichtiger Modell- oder Datenkontext fehlt.

Unabhängige Überprüfung bleibt unverzichtbar. Teams sollten testen, ob Kontrollen verbotene Datenpfade und Aktionen tatsächlich blockieren. Sie sollten zudem Ausfälle mit abgelaufenen Anmeldedaten, nicht verfügbaren Modellen, beschädigten Indizes und unvollständigen Protokollen proben.

Die Sicherheitskomplexität wächst mit der organisatorischen Komplexität. Fusionen bringen übernommene Cloud-Konten, Identitätssysteme und Datenklassifizierungen mit sich. SANS identifizierte Fusionen und Übernahmen als einen wesentlichen Grund dafür, dass Unternehmen zusätzliche Cloud-Anbieter einführten.

Diese Vorgeschichte ist wichtig, weil KI-Projekte oft Daten im gesamten zusammengeschlossenen Unternehmen suchen. Ein neuer Assistent kann Inkonsistenzen offenlegen, die verborgen blieben, solange Systeme getrennte Abteilungen bedienten. Retrieval kann Repositories schneller überbrücken, als Governance-Teams ihre Richtlinien abstimmen können.

Datensouveränität erzeugt eine ähnliche Spannung. Ein Unternehmen kann regionale Clouds einsetzen, um Daten innerhalb vorgeschriebener Rechtsräume zu halten. Dennoch kann ein KI-Workflow Prompts, Telemetrie oder Bewertungsproben über Dienste außerhalb der vorgesehenen Grenze leiten.

Verträge und Architektur müssen übereinstimmen. Ein Richtliniendokument kann einen nicht dokumentierten Netzwerkpfad nicht ausgleichen. Ebenso löst eine technisch regionale Bereitstellung nicht jede rechtliche Frage zu Modellen, Supportzugriff oder Subunterauftragnehmern.

Die skeptische Schlussfolgerung lautet, dass keine aktuelle Plattform diese Arbeit beseitigt. Anbieter können Kontrollen, Protokolle und Integrationsprodukte bereitstellen. Unternehmen bleiben dafür verantwortlich, diese Elemente zu Nachweisen zusammenzuführen, die ihren Geschäftsprozessen und Verpflichtungen entsprechen.

Standardisierung hat ebenfalls ihre Grenzen. Ein Unternehmen kann ein zentrales Gateway für den Modellzugriff vorschreiben, doch Nutzer können Informationen in externe Tools einfügen. Es kann mehrere Modelle genehmigen, während Produktteams Funktionen entdecken, die über die genehmigte Schnittstelle nicht verfügbar sind.

Governance muss daher technische Kontrollen mit Beschaffung, Schulungen und Verantwortlichkeit verbinden. Jedes Experiment zu blockieren, ist unrealistisch. Ebenso unsicher ist es, jedes Experiment zur Produktionsinfrastruktur werden zu lassen.

CIOs benötigen messbare Abbruchkriterien für Pilotprojekte. Vor einer Ausweitung sollte ein System einen benannten Verantwortlichen, einen genehmigten Datenumfang, dokumentierte Abhängigkeiten, Bewertungsergebnisse, Verfahren für Incidents und eine Nutzungsüberwachung haben. Es sollte zudem einen klar definierten Abschaltpfad geben.

Diese Anforderungen werden einige Bereitstellungen verlangsamen. Diese Verzögerung ist weniger kostspielig, als später festzustellen, dass kein Team nachvollziehen kann, wie eine folgenschwere Entscheidung zustande kam.

Worauf CIOs nach der Google-News-Warnung achten sollten

Die nächste Phase wird zeigen, ob Multi-Cloud-KI zu einer gesteuerten Architektur wird oder zu einer weiteren Schicht unkontrollierter Unternehmenszersplitterung.

Das erste Signal ist das Wachstum standardisierter Schnittstellen für Modelle und Agenten. Technische Kompatibilität muss mehr abdecken als Textgenerierung. Sie muss Tool-Aufrufe, Identitätskontext, Richtlinienentscheidungen, Traces, Bewertungen und Fehlerverhalten einschließen.

Wenn Anbieter und Open-Source-Projekte bei sinnvollen Standards zusammenfinden, können Unternehmen kundenspezifische Adapter reduzieren. Das würde die Argumente für bewusst geplante Multi-Cloud-KI stärken. Oberflächliche API-Kompatibilität würde das zentrale Integrationsproblem unverändert lassen.

CIOs sollten tatsächliche Workload-Migrationen beobachten statt Ankündigungen zur Anbieterinteroperabilität. Ein glaubwürdiger Portabilitätstest verschiebt eine produktionsähnliche Anwendung zwischen Anbietern und erhält dabei Berechtigungen, Qualitätsschwellen, Protokolle und Wiederherstellungsverfahren.

Das zweite Signal ist, ob Unternehmen ihre KI-Kontrollschichten konsolidieren. Relevante Hinweise sind weniger Modell-Gateways, gemeinsame Bewertungsdienste, einheitliche Inventare und eine konsistente Durchsetzung von Richtlinien über Geschäftsbereiche hinweg.

Konsolidierung würde darauf hindeuten, dass Organisationen Experimente in verwaltete Plattformen überführen. Anhaltendes Wachstum bei sich überschneidenden Gateways, Vektorspeichern und Observability-Produkten würde die These von der Integrationshölle stützen.

Die Kennzahl sollte nicht allein die Anzahl der Tools sein. Ein großes Unternehmen kann durchaus mehrere Produkte benötigen. Führungskräfte sollten doppelte Funktionen, nicht unterstützte Verbindungen, Richtlinienausnahmen und die Zeit messen, die erforderlich ist, um eine einzelne KI-Transaktion nachzuverfolgen.

Das dritte Signal sind Berichte über Produktionszuverlässigkeit und Kosten aus Agentenbereitstellungen. Anbieter werden weiterhin Umfragen zur Akzeptanz veröffentlichen, doch CIOs benötigen operative Kennzahlen. Dazu gehören die Häufigkeit von Incidents, die Qualität der Reaktionen, Latenz, Interventionsraten, Datentransfernutzung und Kosten pro abgeschlossener Geschäftsaufgabe.

Wenn sich diese Kennzahlen verbessern, während die Anbietervielfalt zunimmt, halten gemeinsame Plattformen die Komplexität in Grenzen. Steigen Kosten und Incidents schneller als die Akzeptanz, erzeugt die Multi-Cloud-Auswahl mehr Belastung als Nutzen.

Google News wird weiterhin Behauptungen über neue Modelle, Cloud-Partnerschaften und Interoperabilitätsfunktionen hervorheben. CIOs sollten jede Ankündigung als Entscheidung über eine einzelne Komponente behandeln, nicht als vollständige Architektstrategie.

Ein Modell mit besserer Benchmark-Leistung kann dennoch die falsche Ergänzung sein, wenn es eine weitere Identitätsbrücke und einen zusätzlichen Bewertungsprozess erfordert. Ein günstigerer Endpunkt kann mehr kosten, sobald Datenbewegungen, Engineering, Monitoring und Compliance-Aufwand in die Rechnung einfließen.

Unternehmen sollten außerdem Resilienz von Duplizierung unterscheiden. Gleichwertige Workloads über mehrere Anbieter hinweg auszuführen, kann die Abhängigkeit von einem einzelnen Ausfall verringern. Die Resilienz verbessert sich jedoch nur, wenn Teams Failover regelmäßig testen und prüfen, ob der sekundäre Pfad akzeptabel funktioniert.

Ein ungenutzter Fallback ist keine Resilienz. Er ist eine ungetestete Abhängigkeit. Dieselbe Regel gilt für Modellrouter, Backup-Indizes und replizierte Datenpipelines.

Die Beschaffung sollte neben der Dienstgenehmigung auch ein Integrationsbudget verlangen. Dieses Budget umfasst Personal, Tests, Sicherheitsprüfungen, Observability, Dokumentation und eine spätere Migration. Es macht die laufenden Kosten sichtbar, bevor die Einführung internen Druck erzeugt, einen Dienst beizubehalten.

Architekturprüfungen sollten außerdem fragen, was geschieht, wenn der Anbieter ein Modell verändert oder eine Funktion einstellt. Teams müssen ermitteln, welche Prompts, Bewertungen, Workflows und Nutzer betroffen wären. Diese Abhängigkeitskarte macht abstrakten Lock-in zu einem umsetzbaren Risiko.

Die richtige Strategie unterscheidet sich je nach Workload. Hochwertige Forschungs- oder Engineering-Aufgaben können den Zugriff auf mehrere spezialisierte Modelle rechtfertigen. Routinemäßige Unterstützung für Mitarbeitende profitiert möglicherweise stärker von einer schlanken, standardisierten Plattform mit einheitlichen Kontrollen.

CIOs müssen Multi-Cloud-KI nicht ablehnen. Sie müssen aufhören, sie als automatischen Schutz gegen Abhängigkeit zu betrachten. Vielfalt hilft nur, wenn die Organisation das daraus entstehende System betreiben, absichern und erklären kann.

Die über Google News hervorgehobene InformationWeek-Warnung verweist auf eine praktische Entscheidung. Unternehmen können weiterhin KI-Dienste dort hinzufügen, wo sie jeweils am stärksten erscheinen, oder sie können die Integrationsgrenzen definieren, die künftige Betriebsabläufe schützen.

Bevor Führungskräfte einen weiteren Anbieter genehmigen, sollten sie eine direkte Frage stellen: Schafft dieser Dienst genug messbaren Wert, um eine weitere dauerhafte Kontrollfläche zu rechtfertigen? Bleibt die Antwort unklar, sollte die nächste Integration warten.