Jede Architektur-Entscheidung ist eine Wette auf die Zukunft. Bei Enterprise-AI-Plattformen ist der Einsatz dieser Wette höher als bei fast jeder anderen IT-Entscheidung der letzten zwanzig Jahre, aus einem einfachen Grund: KI-Systeme akkumulieren organisationsspezifisches Wissen. Wer die Plattform kontrolliert, kontrolliert zunehmend nicht nur die Infrastruktur, sondern die operative Intelligenz der Organisation.
Technologische Souveränität ist deshalb kein politisches Schlagwort. Sie ist eine Architektureigenschaft, und sie wird in genau den Entscheidungen gewonnen oder verloren, die heute unter Zeitdruck in Plattform-Evaluierungen getroffen werden.
Die vier Lock-in-Ebenen
Lock-in wird meist als Lizenzfrage diskutiert. Das greift zu kurz. Ich habe Plattform-Entscheidungen von beiden Seiten des Tisches erlebt, als Datenverantwortlicher in Bank- und Aviation-Konzernen und heute als herstellerneutraler Bewerter. In technischen Bewertungen unterscheide ich vier Ebenen, die sich in ihrer Reversibilität dramatisch unterscheiden:
Ebene 1: Infrastruktur-Lock-in
Der klassische Fall: Workloads laufen auf proprietären Diensten eines Hyperscalers. Diese Ebene ist die sichtbarste, und paradoxerweise die am wenigsten gefährliche. Compute ist substituierbar, Migrationspfade existieren, der Markt ist kompetitiv. Wer nur hier gebunden ist, hat ein Kostenproblem, kein Souveränitätsproblem.
Ebene 2: Daten- und Format-Lock-in
Kritischer: Embeddings, Feature Stores, Vektorindizes und Trainingsdaten in proprietären Formaten, deren Export technisch möglich, aber praktisch wertlos ist, weil die semantische Struktur an die Plattform gebunden ist. Eine Organisation, die drei Jahre lang Dokumenten-Embeddings in einem geschlossenen System akkumuliert hat, migriert nicht, sie beginnt von vorn.
Ebene 3: Workflow- und Integrations-Lock-in
Die unterschätzte Ebene: Wenn Orchestrierung, Agenten-Logik, Prompt-Bibliotheken und Governance-Workflows in plattformspezifischen Abstraktionen gebaut sind, wird jeder Geschäftsprozess, der auf ihnen aufsetzt, zur Geisel der Plattform-Roadmap. Preiserhöhungen, Feature-Deprecations und Strategiewechsel des Anbieters schlagen direkt auf die eigene Prozesslandschaft durch.
Ebene 4: Kompetenz-Lock-in
Die gefährlichste und am seltensten diskutierte Ebene: Wenn das interne Wissen der Organisation ausschließlich in den Kategorien eines Anbieters existiert (dessen Zertifizierungen, dessen Referenzarchitekturen, dessen Denkmodelle), verliert die Organisation die Fähigkeit, Alternativen überhaupt zu bewerten. Der Lock-in sitzt dann nicht mehr im System, sondern in den Köpfen. An diesem Punkt ist jede „herstelleroffene Evaluierung“ eine Formalität mit vorbestimmtem Ergebnis.
Warum das Problem jetzt akut ist
- Plattform-Konsolidierung: Die großen Anbieter bündeln Modelle, Daten-Infrastruktur, Orchestrierung und Governance-Tooling zu integrierten Stacks. Die Bequemlichkeit ist real, und genau kalkuliert. Jede Integrationsschicht, die man nicht selbst besitzt, ist eine künftige Verhandlungsposition, die man nicht hat.
- Regulatorischer Druck: Der EU AI Act verlangt Nachvollziehbarkeit, Dokumentation und Kontrolle über eingesetzte Systeme. Eine Organisation, die nicht erklären kann, wie ihr System zu Entscheidungen kommt, weil die relevanten Komponenten Blackboxes eines Anbieters sind, hat ein Compliance-Problem, das sich nicht durch Vertragsklauseln lösen lässt.
- Geopolitische Realität: Für Banken, kritische Infrastruktur und den öffentlichen Sektor ist die Frage, unter welcher Jurisdiktion die eigene operative Intelligenz liegt, keine theoretische mehr. Souveränität wird zur Anforderung von Aufsichtsräten, nicht nur von Architekten.
Architekturmuster für Reversibilität
Souveränität heißt nicht, alles selbst zu bauen. Das wäre die teuerste Form des Scheiterns. Souveränität heißt: bewusst entscheiden, wo Abhängigkeit akzeptabel ist, und Reversibilität dort erhalten, wo sie strategisch zählt. Vier Muster haben sich in meiner Praxis bewährt:
1. Abstraktions-Disziplin an der Modellgrenze
Modell-Zugriffe laufen über eine eigene, schmale Abstraktionsschicht, nicht über die SDKs des Anbieters direkt in der Geschäftslogik. Der Wechsel eines Foundation Models darf ein Konfigurationsereignis sein, kein Migrationsprojekt. Diese Schicht ist billig, solange man sie von Anfang an baut, und fast unbezahlbar, wenn man sie nachrüsten muss.
2. Datenhoheit als nicht verhandelbare Grundlinie
Rohdaten, Trainingsdaten, Embeddings und Evaluationsdatensätze liegen in offenen Formaten unter eigener Kontrolle. Plattformen dürfen Kopien verarbeiten, die kanonische Quelle bleibt im eigenen Haus. Wer diese Linie hält, behält die Option, jede nachgelagerte Komponente zu ersetzen.
3. Governance-Tooling plattformneutral bauen
Modellrisiko-Register, Audit-Trails, Evaluations-Pipelines und Dokumentation gehören in eigene, anbieterunabhängige Strukturen. Sie sind das institutionelle Gedächtnis der KI-Landschaft, und genau die Artefakte, die Regulatoren sehen wollen. Sie an einen Anbieter zu binden heißt, die eigene Compliance-Fähigkeit zu verpfänden.
4. Kompetenz-Portfolio statt Zertifikats-Monokultur
Interne Teams werden bewusst über mehrere Stacks und Paradigmen entwickelt. Nicht, weil man alles nutzt, sondern weil Bewertungsfähigkeit Vergleichswissen voraussetzt. Die günstigste Versicherung gegen Ebene-4-Lock-in ist ein Team, das die Frage „Warum eigentlich dieser Anbieter?“ kompetent stellen kann.
Die Bewertungsfrage vor der Beschaffungsfrage
Die praktische Konsequenz: Vor jeder Plattform-Entscheidung mit mehrjähriger Tragweite gehört eine herstellerneutrale technische Bewertung, die explizit die Exit-Kosten modelliert, nicht nur die Einführungskosten. Die entscheidende Frage an jede Architektur lautet nicht „Was kostet der Einstieg?“, sondern:
„Was kostet es uns in drei Jahren, diese Entscheidung zu revidieren, und wer in unserer Organisation kann das dann noch beurteilen?“
Organisationen, die diese Frage vor der Unterschrift beantworten, kaufen Werkzeuge. Die anderen kaufen Abhängigkeiten.
