Mitte 2026 sorgen sich 81 % der Unternehmenslenker um die Abhängigkeit von einem KI-Anbieter. Sorge ist aber keine Strategie. Die Strategie ist ein Gateway zwischen Geschäftslogik und Modell — und genau dort leben auch Governance und Datenresidenz.
Sorge ist keine Strategie
Mitte 2026 äussern 81 % der Unternehmenslenker Bedenken hinsichtlich der Abhängigkeit von einem einzelnen KI-Anbieter. Das ist eine bemerkenswerte Zahl — und ein bemerkenswert wenig handlungsleitendes Gefühl. Denn Sorge ist keine Strategie. Sich Sorgen über Lock-in zu machen, ändert an der Architektur eures Systems exakt nichts. Was die Architektur ändert, ist eine Entscheidung: nämlich die, einen Anbieter zum austauschbaren Detail zu machen statt zum Fundament.
Die meisten KI-Integrationen entstehen pragmatisch. Man wählt ein Modell, das gerade gut funktioniert, verdrahtet die Geschäftslogik direkt gegen dessen Endpunkt, und das Produkt läuft. Der Preis dieser Bequemlichkeit zeigt sich erst später — wenn der Anbieter die Preise anhebt, ein Modell zurückzieht, eine Compliance-Anforderung kippt oder schlicht ein besseres Modell anderswo erscheint. In diesem Moment ist die harte Kopplung kein Detail mehr, sondern ein Quartalsprojekt.
Das Muster: ein Gateway zwischen Logik und Modell
Klingt interessant?
Die architektonische Antwort, die sich gerade durchsetzt, ist unspektakulär und genau deshalb wirksam: eine Abstraktions- oder Gateway-Schicht zwischen der Geschäftslogik und jedem einzelnen Anbieter. In einem Multi-Model-Setup spricht die Anwendung nicht mehr mit "OpenAI" oder "Anthropic", sondern mit einer einheitlichen, anbieterneutralen Schnittstelle. Welches Modell die Anfrage tatsächlich bearbeitet, entscheidet die Schicht — dynamisch.
Und zwar nach drei Kriterien: Fähigkeit, Kosten und Latenz. Eine Coding-Aufgabe geht an das Modell, das Code am besten beherrscht. Ein Reasoning-Problem über ein langes Dokument an das Modell mit dem passenden Kontextfenster und dem stärksten Schlussfolgern. Eine leichtgewichtige Klassifikation an ein billigeres, schnelleres Modell, weil der teure Frontier-Endpunkt hier reine Verschwendung wäre. Das Routing ist keine Einmalentscheidung beim Architektur-Review, sondern eine laufende, anfrageweise Optimierung.
Reife Multi-Model-Plattformen hören dort nicht auf. Sie ergänzen die Schicht um zentrale Sicherheitskontrollen, Audit-Trails, Data-Loss-Prevention und Policy-Enforcement — und um die Fähigkeit, bestimmte Daten ausschliesslich auf freigegebenen, regionsspezifischen Modellen zu halten. Aus der Routing-Schicht wird so eine Governance-Schicht. Drei Eigenschaften fallen dabei zusammen ab: Resilienz, reduzierter Lock-in und Kontrolle über die Datenresidenz.
Warum das Gateway der richtige Ort für Governance ist
Der oft übersehene Punkt: Das Gateway ist nicht nur eine technische Bequemlichkeit für den Modellwechsel. Es ist der einzig sinnvolle Ort, an dem sich Governance und Datenresidenz überhaupt durchsetzen lassen. Wenn jede Anwendung selbst entscheidet, welches Modell sie anspricht, dann ist eure Datenschutz-Policy ein PDF und kein durchgesetzter Mechanismus. Wenn alle Anfragen durch eine Schicht laufen, dann ist die Regel "diese Kundendaten dürfen nur ein in der EU gehostetes Modell berühren" keine Bitte an die Entwickler mehr, sondern eine technische Eigenschaft des Systems.
Das ist der eigentliche Hebel. Datenresidenz ist keine Frage, die man pro Team und pro Projekt neu beantwortet und hofft, dass alle es richtig machen. Sie ist eine Konfiguration an genau einer Stelle. Wer welche Daten an welches Modell in welcher Region schicken darf, wird im Gateway entschieden — und nirgends sonst. Audit-Trails entstehen automatisch, weil der gesamte Verkehr ohnehin durch diese Stelle fliesst.
Was das für CTOs und Tech-Leads bedeutet
Drei Konsequenzen, die ich für relevant halte:
Erstens: Behandelt das Modell wie eine Datenbank-Engine, nicht wie eure Geschäftslogik. Niemand verdrahtet ernsthafte Software fest gegen eine konkrete Datenbankversion, ohne eine Abstraktionsschicht dazwischen. Beim Modell sollte derselbe Reflex gelten. Der Anbieter ist Infrastruktur — austauschbar, versioniert, abstrahiert. Sobald das so ist, wird der Modellwechsel von einem Migrationsprojekt zu einer Konfigurationsänderung.
Zweitens: Lock-in-Resilienz und Kostenoptimierung sind dieselbe Schicht. Das Gateway, das euch vor dem Wegfall eines Anbieters schützt, ist exakt dasselbe Gateway, das billige Aufgaben an billige Modelle routet. Ihr baut diese Schicht nicht zweimal. Wer sie wegen der Kosten baut, bekommt die Resilienz gratis dazu — und umgekehrt.
Drittens: Governance gehört in die Schicht, nicht in die Köpfe. Eine Datenresidenz-Regel, die nur in einer Confluence-Seite steht, ist kein Schutz. Eine Regel, die im Gateway erzwungen wird, schon. Verlagert die Entscheidung "welche Daten dürfen welches Modell berühren" an genau eine durchsetzbare Stelle, und die Diskussion über Compliance wird vom Dauerthema zur Konfigurationsfrage.
Und genau hier kommt nopex ins Spiel
Die übliche Antwort auf das Lock-in-Problem lautet: "Dann baut euch halt ein Gateway." Das ist richtig — und übersieht, dass jedes Team diese Schicht sonst von Grund auf neu baut, inklusive Routing, Policy-Enforcement, Audit-Trails und Datenresidenz-Logik. Das ist viel Plumbing für etwas, das in keinem Geschäftsmodell ein Differenzierungsmerkmal ist.
nopex ist diese Abstraktionsschicht — für die Softwareentwicklung selbst. Unsere Agenten routen über Modelle und Anbieter hinweg, hinter einer einzigen, governten Schnittstelle, auf europäischer Infrastruktur. Welches Modell eine Coding-Aufgabe, ein Reasoning-Problem oder eine leichtgewichtige Klassifikation bearbeitet, entscheidet die Plattform nach Fähigkeit, Kosten und Latenz — nicht euer Anwendungscode. Welche Daten welches Modell in welcher Region berühren dürfen, ist eine Eigenschaft der Plattform, kein Versprechen pro Projekt.
Damit werden Resilienz, Kostenoptimierung und Datenresidenz zu Eigenschaften des Fundaments — nicht zu Plumbing, das jedes Team aufs Neue zusammensteckt. Die 81 %, die sich Sorgen machen, haben recht mit ihrer Sorge. Aber die Antwort ist keine bessere Wahl des Anbieters. Die Antwort ist, den Anbieter zum austauschbaren Detail zu machen.
