KI-Souveränität zwischen USA, China und Europa

Ein KI-Projekt wirkt im Alltag oft wie eine Folge technischer Entscheidungen: Modell wählen, Daten anbinden, Schnittstelle bauen, Qualität prüfen. Doch unter jeder dieser Entscheidungen liegt eine zweite Ebene. Wer kontrolliert die Rechenleistung? Welches Recht gilt für den Anbieter? Wer darf Chips, Modellgewichte oder Updates liefern? Was passiert, wenn eine Regierung Exportregeln ändert, ein Anbieter einen Dienst zurückzieht oder eine Lizenz enger fasst?

Diese Fragen sind keine außenpolitische Zugabe. Sie beeinflussen Kosten, Termine, Beschaffung, Architektur und Betriebsfähigkeit. Geopolitik wird damit zu einem normalen Projektfaktor.

KI-Souveränität ist keine Herkunftsbehauptung. Sie ist die nachgewiesene Fähigkeit, kritische Abhängigkeiten zu verstehen, zu begrenzen und bei Bedarf zu wechseln.

Warum Geopolitik im Projektplan auftaucht

USA, China und Europa verfolgen unterschiedliche industrie-, sicherheits- und ordnungspolitische Ziele. Diese Ziele werden über Exportkontrollen, Investitionen, Beschaffungsregeln, Standards, Plattformbedingungen und nationale Regulierung in Märkte übertragen. Ein Projekt spürt das nicht als abstrakte „Weltlage“, sondern als verfügbaren Modellkatalog, Regionenauswahl, Vertragsklausel, Preis, Prüfung oder Lieferzeit.

Deshalb gehört geopolitische Exposition in Risiko-, Architektur- und Beschaffungsentscheidungen. Nicht jede Abhängigkeit ist schlecht. Unsichtbare und ungetestete Abhängigkeiten sind das Problem.

Souveränität ist nicht Autarkie

Kein realistisches Team kontrolliert die gesamte KI-Wertschöpfung: Halbleiterdesign, Fertigung, Rechenzentrum, Energie, Basismodell, Framework, Daten, Anwendung und Betrieb. Das Ziel kann daher nicht vollständige Unabhängigkeit sein.

Operative Souveränität bedeutet vielmehr: Das Team weiß, welche Fremdleistungen kritisch sind, welche Rechte und Restriktionen gelten, welche Teile austauschbar bleiben und wie lange ein Wechsel dauern würde. Es entscheidet bewusst, wo Abhängigkeit akzeptiert wird und wo eine Alternative vorgehalten werden muss.

Datenresidenz ist nur eine Teilfrage

Ein europäischer Serverstandort kann für Datenschutz, Latenz oder Beschaffung relevant sein. Er beantwortet aber nicht automatisch, welchem Konzernrecht der Anbieter unterliegt, wer Schlüssel und Administrationszugänge kontrolliert, ob Unterauftragnehmer beteiligt sind oder ob Modelle, Telemetrie und Supportprozesse aus anderen Rechtsräumen stammen.

Darum sind vier Fragen getrennt zu prüfen: Wo liegen die Daten? Wer kann technisch zugreifen? Welches Recht bindet die Beteiligten? Wer kann den Dienst verändern oder beenden? Erst die Kombination ergibt ein belastbares Bild.

Die KI-Wertschöpfung als Abhängigkeitskette

Ein Projekt sollte seine Wertschöpfung nicht als eine einzige „Cloud“-Box zeichnen. Mindestens diese Ebenen gehören in die Karte:

Die Karte zeigt, dass ein lokal laufendes Modell weiterhin von importierter Hardware, ausländischen Treibern, fremden Gewichten oder einer restriktiven Lizenz abhängen kann.

Kontrolle, Fähigkeit und Optionalität

Souveränität lässt sich in drei Dimensionen zerlegen. Kontrolle beschreibt Rechte, Schlüssel, Konfiguration und Entscheidungsgewalt. Fähigkeit beschreibt, ob das eigene Team das System verstehen und betreiben kann. Optionalität beschreibt, ob realistische Alternativen existieren.

Ein Projekt kann vertraglich viele Rechte besitzen und trotzdem nicht souverän sein, wenn niemand einen Export, Modelltausch oder Wiederanlauf beherrscht. Umgekehrt ersetzt technisches Können keine fehlenden Nutzungsrechte. Alle drei Dimensionen müssen zusammenkommen.

Die USA: Skalierung, private Plattformen und strategischer Export

Der US-Kurs verbindet private Innovations- und Kapitalstärke mit massiver Infrastruktur, Halbleiterpolitik und internationaler Technologiepolitik. Der offizielle AI Action Plan von 2025 ordnet Innovation, Infrastruktur sowie internationale Diplomatie und Sicherheit als drei Säulen. Er nennt ausdrücklich den weltweiten Export amerikanischer KI-Technologie und die Durchsetzung von Kontrollen für fortgeschrittene Rechenleistung.^[1]

Für Projekte bedeutet das hohe Leistungsfähigkeit und ein breites Ökosystem, aber oft auch Konzentration auf wenige Plattformen. Unternehmensentscheidungen und staatliche Regeln können dadurch gleichzeitig auf Modellzugang, Cloudkapazität und Hardware wirken.

China: industrielle Koordination, Infrastruktur und kontrollierte Offenheit

Chinas Politik verbindet rasche industrielle Anwendung, Ausbau von Recheninfrastruktur, eigene Chips und Modelle mit staatlichen Sicherheits- und Inhaltsanforderungen.^[4] Der chinesische Aktionsplan zur globalen KI-Governance von 2025 betont Infrastruktur, offene Ökosysteme, Interoperabilität, nationale Souveränität sowie Sicherheit und Kontrollierbarkeit.^[3]

Für ein europäisches Projekt können chinesische Modelle technisch oder wirtschaftlich attraktiv sein. Gleichzeitig müssen Herkunft, Lizenz, Hostingroute, Updatepolitik, Inhaltsregeln und mögliche Handelsrestriktionen geprüft werden. „Open Weight“ hebt diese Fragen nicht auf.

Europa: Regeln, Infrastrukturaufbau und strategische Autonomie

Europa kombiniert Grundrechte- und Marktregeln mit dem Versuch, eigene Rechen-, Daten- und Halbleiterkapazitäten auszubauen.^[8] Seit Januar 2026 kann EuroHPC auch KI-Gigafactories unterstützen.^[5] Im April 2026 berichtete EuroHPC über 19 KI-Fabriken und 13 Antennen im Aufbau beziehungsweise in Koordination.^[6]

Das ist ein Infrastrukturpfad, keine fertige Unabhängigkeit. Für Projekte bleibt entscheidend, welche Kapazität tatsächlich zugänglich ist, welche Modelle und Werkzeuge dort laufen, welche Wartezeiten gelten und ob der eigene Betriebsfall unterstützt wird.

Keine Region ist ein einheitliches Produktmerkmal

„US-Anbieter“, „chinesisches Modell“ oder „europäische Cloud“ sind zu grobe Kategorien für eine Freigabe. Innerhalb jeder Region unterscheiden sich Betreiber, Eigentümer, Unterauftragnehmer, Lizenzen, Sicherheitspraktiken und technische Portabilität erheblich.

Regionale Herkunft ist deshalb ein Eingangssignal, kein Urteil. Die Entscheidung braucht konkrete Anbieter-, Dienst-, Versions- und Vertragsdaten.

Exportkontrollen werden zu Architekturparametern

Exportkontrollen richten sich nicht nur an Staaten. Sie können Chips, Fertigungsgeräte, Software, Reexporte, Nutzung und Lieferketten betreffen. Die US-Handelsbehörde BIS hat 2025 beispielsweise Leitlinien zu bestimmten fortgeschrittenen chinesischen Rechenchips veröffentlicht und auf mögliche Durchsetzungsfolgen hingewiesen.^[2]

Ein Projektteam muss keine Außenhandelsbehörde spielen. Es muss aber erkennen, wann Hardwareherkunft, Nutzerstandort, Rechenzentrumsregion oder Vertragspartner eine spezialisierte Prüfung auslösen. Diese Prüfung gehört vor die Beschaffung, nicht hinter den Ausfall.

Regulierung kann Märkte auseinanderziehen

Ein Modell oder Dienst kann in einer Region verfügbar, in einer anderen eingeschränkt und in einer dritten nur mit zusätzlichen Kontrollen nutzbar sein. Gründe reichen von Datenschutz und Produktsicherheit bis zu Inhalts-, Sicherheits- oder nationalen Vorgaben.

Wer eine globale Anwendung plant, braucht daher keine einzige pauschale Freigabe, sondern eine Einsatzmatrix: Region, Nutzergruppe, Datentyp, Modellroute, erforderliche Kontrolle und erlaubter Funktionsumfang.

Open Source ist nicht automatisch souverän

Offener Code erleichtert Prüfung, Anpassung und Wechsel. Offene Gewichte können den Betrieb außerhalb eines einzelnen API-Anbieters ermöglichen. Trotzdem können Trainingsdaten unbekannt, Lizenzen eingeschränkt, Hardwareanforderungen hoch und Updates von einer kleinen Organisation abhängig sein.

Die richtige Frage lautet nicht „Ist es Open Source?“, sondern: Welche Rechte, Artefakte, Fähigkeiten und Ressourcen besitzen wir tatsächlich, um es ohne den ursprünglichen Anbieter weiterzubetreiben?

Geschlossene APIs sind nicht automatisch unsouverän

Eine geschlossene API kann für einen unkritischen, klar begrenzten Workload eine gute Entscheidung sein. Wenn Inputs kontrolliert, Outputs geprüft, Daten exportierbar und eine Ersatzroute vorbereitet sind, bleibt die Abhängigkeit beherrschbar.

Souveränität verlangt nicht, jede Komponente selbst zu besitzen. Sie verlangt, dass der Ausfall einer fremden Komponente nicht überraschend die gesamte Leistung zerstört.

Konzentrationsrisiko entsteht über mehrere Ebenen

Ein Team kann scheinbar drei Anbieter nutzen und trotzdem an derselben Infrastruktur hängen. Mehrere Modell-APIs können auf demselben Hyperscaler laufen. Verschiedene Clouds können dieselbe Chipfamilie, denselben Identitätsanbieter oder dieselbe Open-Source-Bibliothek verwenden.

Darum wird Konzentration auf Ebene der wirtschaftlich und technisch letzten gemeinsamen Abhängigkeit gemessen. Anbieterzählung allein ist kein Diversitätsbeleg.

Der Dependency Ledger macht Exposition sichtbar

Für jede kritische Projektfunktion wird ein Datensatz angelegt:

Das Ledger ist kein einmaliger Compliance-Anhang. Es ist ein lebendes Projektartefakt.

Kritikalität vor Herkunft bewerten

Nicht jede ausländische Abhängigkeit verlangt einen Fallback. Eine austauschbare Übersetzungsfunktion ist anders zu behandeln als ein Modell, das eine medizinische Priorisierung, einen Produktionsprozess oder das zentrale Produktversprechen trägt.

Bewertet werden Ausfallwirkung, Wiederanlaufzeit, Datenverlust, Vertragsfolgen und Kundenschaden. Erst danach wird entschieden, wie viel Kontrolle und Redundanz wirtschaftlich angemessen ist.

Substituierbarkeit muss bewiesen werden

„Wir können später wechseln“ ist eine Hypothese. Ein Beweis besteht aus einem erfolgreichen Export, einer lauffähigen Ersatzroute, gemessener Qualitätsdifferenz, dokumentierter Umstellung und einer realistischen Zeitangabe.

Ohne Test ist der vermeintliche Fallback oft nur ein Anbietername auf einer Folie.

Portabilität beginnt bei den eigenen Artefakten

Prompts, Systemregeln, Evaluationsfälle, Datenmodelle, Schnittstellenverträge, Embeddings, Protokolle und Entscheidungslogik sollten möglichst unabhängig vom Anbieter gespeichert werden. Proprietäre Funktionen werden als Adapter gekapselt, statt sich unbemerkt durch den gesamten Prozess zu ziehen.

Besonders wichtig sind exportierbare Rohdaten und reproduzierbare Evaluationssätze. Wer nur den finalen Output besitzt, kann einen Modellwechsel kaum verlässlich bewerten.