Warum europäische Server allein Europas KI-Abhängigkeit nicht lösen

Seit Jahren wird europäischen Unternehmen eine beruhigende Lösung angeboten:

Die Daten bleiben in Europa.

Die Server stehen in Frankfurt, Paris oder Dublin. Es gibt europäische Datenregionen, Verschlüsselung, DSGVO-konforme Verträge und inzwischen sogar sogenannte Sovereign Clouds.

Das alles kann Risiken reduzieren. Aber es schafft noch keine technologische Souveränität.

Der Fall Claude Fable 5 hat den Unterschied deutlich gemacht. Eine Exportkontrollanordnung der US-Regierung untersagte ausländischen Staatsangehörigen den Zugriff auf Fable 5 und Mythos 5. Anthropic deaktivierte daraufhin beide Modelle für sämtliche Kunden.

Ein Serverstandort in Europa hätte daran nichts geändert.

Die Kundendaten hätten in Frankfurt verarbeitet werden können. Das Modell, die Zugriffskontrolle und die Entscheidung über seine Verfügbarkeit lagen trotzdem außerhalb Europas.

Die eigentliche Frage lautet deshalb nicht nur:

Wo liegen unsere Daten?

Sondern:

Wer entscheidet, ob unser System morgen noch funktioniert?

Datenresidenz ist nicht Kontrolle

Ein europäischer Serverstandort kann Datenübertragungen begrenzen, regulatorische Anforderungen erleichtern und mehr Klarheit über die Verarbeitung schaffen.

Er garantiert aber weder automatisch Datenschutzkonformität noch die Kontrolle über das gesamte System.

Ein KI-Dienst besteht aus mehr als dem Ort, an dem Kundendaten verarbeitet werden. Entscheidend sind auch:

  • das Modell und seine Gewichte,
  • die API und die Benutzerkonten,
  • Identitäts- und Zugriffssysteme,
  • Updates und Sicherheitsregeln,
  • der Betreiber der Infrastruktur,
  • die Eigentümerstruktur,
  • sowie der anwendbare Rechtsraum.

Ein Unternehmen kann seine Daten vollständig innerhalb der EU verarbeiten lassen und trotzdem von einer Technologie abhängig sein, deren zentrale Entscheidungen außerhalb Europas getroffen werden.

Frankfurt kann Datenschutz und Datenresidenz verbessern – aber das allein schafft noch keine Souveränität.

Datenresidenz beantwortet die Frage, wo Daten liegen.

Souveränität beantwortet die Frage, wer im Ernstfall entscheidet und ob das Unternehmen handlungsfähig bleibt.

Compliance garantiert keinen Weiterbetrieb

Auch DSGVO und AI Act werden häufig mit technologischer Souveränität vermischt.

Die DSGVO regelt die Verarbeitung personenbezogener Daten. Der AI Act stellt abhängig von Modell, System, Rolle und Risikokategorie Anforderungen an Anbieter und Betreiber von KI.

Beide Regelwerke sind wichtig.

Aber sie garantieren nicht, dass ein Modell dauerhaft verfügbar bleibt.

Ein Dienst kann datenschutzkonform sein und trotzdem eingestellt werden. Ein KI-System kann rechtmäßig betrieben werden und aufgrund einer Exportkontrolle, einer strategischen Entscheidung oder eines wirtschaftlichen Konflikts dennoch verschwinden.

Compliance beantwortet die Frage:

Dürfen wir dieses System unter den gegebenen Bedingungen einsetzen?

Souveränität beantwortet die Frage:

Können wir weiterarbeiten, wenn es nicht mehr verfügbar ist?

Eine Organisation kann rechtlich sauber aufgestellt und gleichzeitig vollständig von einem einzelnen Anbieter abhängig sein.

Fable 5 war ein Warnsignal

Die Abschaltung von Fable 5 und Mythos 5 bedeutet nicht, dass nun jedes amerikanische KI-Modell unmittelbar gefährdet wäre.

Sie zeigt aber, dass selbst ein privates Technologieunternehmen nicht in jeder Situation die letzte Kontrolle über sein Produkt besitzt, wenn staatliche Sicherheits- oder Exportinteressen eingreifen.

Ein Vertrag schützt nicht vor jeder politischen Entscheidung.

Ein europäischer Datenstandort schützt nicht automatisch vor einer Exportbeschränkung.

Und ein technisch funktionierendes Modell kann trotzdem nicht mehr zugänglich sein.

Das ist kein Argument gegen US-Technologie.

Es ist ein Argument gegen Alternativlosigkeit.

Auch europäische KI ist nicht automatisch souverän

Wenn über europäische KI-Souveränität gesprochen wird, fällt schnell der Name Mistral.

Das ist nachvollziehbar. Mistral ist ein französisches Unternehmen, entwickelt leistungsfähige Modelle und bietet unterschiedliche Bereitstellungsformen an. Einige Modelle können auf eigener oder kontrollierter Infrastruktur betrieben werden.

Aber die Herkunft eines Modells allein entscheidet nicht über Souveränität.

Mistral-Modelle können unter anderem über Microsoft Azure, Amazon Bedrock und Google Cloud Vertex AI als verwaltete Dienste bereitgestellt werden. Sie können je nach Modell aber auch auf eigener Infrastruktur laufen.

Wird ein europäisches Modell als verwalteter Dienst auf der Plattform eines US-Konzerns betrieben, bleibt zumindest eine operative und vertragliche Abhängigkeit von dieser Cloud bestehen.

Umgekehrt kann ein nicht europäisches Open-Weight-Modell, das auf eigener oder europäisch kontrollierter Infrastruktur betrieben wird, bei Datenkontrolle und Weiterbetrieb mehr Unabhängigkeit bieten als ein europäisches Modell, das ausschließlich als fremd verwaltete API genutzt wird.

Die entscheidende Frage lautet daher nicht nur:

Welches Modell verwenden wir?

Sondern:

Wie wird es bereitgestellt?

Wer betreibt die Infrastruktur?

Wer kontrolliert Schlüssel und Zugänge?

Kann das Modell zu einem anderen Anbieter umziehen?

Und kann der Prozess weiterlaufen, wenn ein beteiligter Dienst ausfällt?

„Wir verwenden Mistral“ ist noch keine vollständige Souveränitätsstrategie.

Es wird erst dann eine, wenn auch Hosting, Datenkontrolle, Betrieb und Exit-Möglichkeiten zum tatsächlichen Risiko passen.

Open Weight schafft Kontrolle – aber keine vollständige Unabhängigkeit

Open-Weight-Modelle bieten einen wichtigen Vorteil: Die Modellgewichte können gespeichert und auf eigener oder kontrollierter Infrastruktur betrieben werden.

Werden die Gewichte rechtmäßig gespeichert und steht eine lauffähige Umgebung zur Verfügung, kann der ursprüngliche Anbieter diesen lokalen Zugang nicht wie eine externe API kurzfristig abschalten.

Versionen können eingefroren werden. Updates lassen sich kontrollieren. Sensible Daten müssen nicht zwingend an einen externen Modelldienst übertragen werden.

Das erhöht die operative Kontrolle erheblich.

Open Weight bedeutet jedoch nicht automatisch Open Source. Trainingsdaten, Trainingscode und Entwicklungsverfahren können weiterhin geschlossen sein. Auch Lizenzbedingungen unterscheiden sich.

Und der eigene Betrieb schafft neue Abhängigkeiten:

  • von Hardware,
  • Energie und Kühlung,
  • Sicherheitsupdates,
  • Inferenzsoftware,
  • Monitoring,
  • qualifiziertem Personal,
  • und internationalen Lieferketten.

Die Abhängigkeit verschwindet nicht vollständig.

Sie wird verändert und teilweise besser kontrollierbar.

Self-Hosting ist kein einfacher Notausgang

Ein Modell auf einer Workstation zu starten, ist nicht dasselbe wie einen verlässlichen Unternehmensdienst zu betreiben.

Sobald mehrere Nutzer gleichzeitig arbeiten, umfangreiche Dokumente verarbeitet werden oder Agenten dauerhaft Prozesse ausführen, steigen die Anforderungen an Hardware, Sicherheit, Verfügbarkeit und Wartung.

Auch nach dem Kauf eines eigenen Servers bleiben laufende Kosten:

Strom, Personal, Updates, Monitoring, Backups, Ersatzteile und Ausfallsicherheit.

Self-Hosting kann sinnvoll sein, wenn Daten besonders sensibel sind, die Aufgabe klar begrenzt ist und das Unternehmen den Betrieb technisch beherrscht.

Für viele kleine und mittlere Unternehmen ist ein spezialisierter europäischer Hostingpartner realistischer als ein eigener Serverraum.

Souveränität bedeutet nicht, alles selbst betreiben zu müssen.

Sie bedeutet, bewusst entscheiden zu können, welche Kontrolle für welchen Prozess notwendig ist.

Sind europäische und lokale Modelle gleichwertig?

Nicht in jedem Einsatzgebiet.

Bei Dokumentenanalyse, Datenextraktion, Klassifikation, Wissenssuche, Zusammenfassungen oder Übersetzungen können europäische und selbst betriebene Modelle bereits sehr gute Ergebnisse liefern.

Bei komplexer Softwareentwicklung, Computer Use, anspruchsvoller Multimodalität oder langen autonomen Agentenprozessen können leistungsfähige geschlossene Frontier-Modelle weiterhin deutliche Vorteile bieten.

Welche Lösung tatsächlich besser ist, lässt sich nicht aus Herkunft oder Benchmarks allein ableiten. Sie muss mit den eigenen Aufgaben, Daten und Qualitätskriterien getestet werden.

Souveränität darf nicht bedeuten, schwächere Ergebnisse aus politischen Gründen als gleichwertig zu verkaufen.

Gleichzeitig benötigt ein Unternehmen nicht für jede E-Mail, Klassifikation oder Dokumentensuche das stärkste Modell der Welt.

Die wirtschaftlich sinnvolle Frage lautet:

Welches Modell erledigt unsere konkrete Aufgabe zuverlässig genug, zu vertretbaren Kosten und mit einem akzeptablen Risiko?

Die realistische Lösung heißt kontrollierte Abhängigkeit

Die meisten europäischen Unternehmen werden auch künftig amerikanische Modelle und Clouds einsetzen.

Das ist nicht automatisch ein strategischer Fehler.

US-Anbieter verfügen über leistungsfähige Systeme, ausgereifte Infrastrukturen und große Entwicklerökosysteme. Ein vollständiger Verzicht wäre für viele Organisationen derzeit weder wirtschaftlich noch technisch sinnvoll.

Die Lösung lautet deshalb nicht digitale Abschottung.

Sie lautet kontrollierte Abhängigkeit.

Ein Unternehmen kann ein US-Spitzenmodell einsetzen. Es sollte seine Prozesse aber nicht so bauen, dass mit diesem Modell gleichzeitig der gesamte Betrieb verschwindet.

Was Unternehmen konkret tun sollten

1. Den gesamten Stack bewerten

Nicht nur der Modellname zählt.

Auch Hosting, Betreiber, Rechtsraum, Schlüsselverwaltung, Zugriffskontrolle, Exportmöglichkeiten und technische Abhängigkeiten gehören in die Bewertung.

2. Mindestens einen Ersatz real testen

Ein Fallback auf einer Architekturzeichnung ist kein Fallback.

Das Ersatzmodell muss mit echten Daten, Werkzeugen und Aufgaben getestet werden. Dabei sind Qualität, Kosten, Geschwindigkeit und notwendige menschliche Kontrolle zu vergleichen.

Ein Ersatz muss nicht dieselbe Spitzenleistung erreichen. Er muss den kritischen Kernbetrieb aufrechterhalten können.

3. Wissen und Prozesse portabel halten

Prompts, Systemanweisungen, Wissensdatenbanken, Testfälle und Prozesslogik sollten nicht ausschließlich in einer proprietären Plattform gespeichert werden.

Wer sein gesamtes Prozesswissen in einer schwer exportierbaren Agentenoberfläche aufbaut, schafft einen zusätzlichen Lock-in.

4. Aufgaben nach Risiko trennen

Nicht jede Aufgabe benötigt denselben Schutz.

Allgemeine Recherche und öffentliche Inhalte können möglicherweise über ein externes Spitzenmodell laufen.

Personenbezogene Daten, Geschäftsgeheimnisse, medizinische Informationen oder strategische Dokumente können in einer stärker kontrollierten Umgebung verarbeitet werden.

5. Einen Notbetrieb definieren

Unternehmen sollten vorab beantworten:

Welche Prozesse stehen still, wenn das primäre Modell ausfällt?

Welches System übernimmt?

Welche Aufgaben können vorübergehend manuell erledigt werden?

Wer entscheidet über die Umschaltung?

Welche Qualitätsverluste sind akzeptabel?

Dieser Ansatz passt zum Risikomanagement eines KI-Managementsystems nach ISO/IEC 42001. Die Norm schreibt keinen bestimmten Zweitanbieter vor, verlangt aber einen strukturierten Umgang mit KI-bezogenen Risiken und geeignete Maßnahmen zu ihrer Behandlung.

Multi-Modell statt Single Point of Failure

Für viele Unternehmen dürfte eine hybride Architektur sinnvoll sein.

Ein lokal oder europäisch betriebenes Modell verarbeitet sensible und klar definierte Aufgaben.

Ein leistungsfähiges externes Modell übernimmt komplexere Arbeit.

Ein zweiter Anbieter steht als Fallback bereit.

Das ist aufwendiger als ein einziger API-Zugang. Aber genau dieser Aufwand schafft Widerstandsfähigkeit.

In anderen Bereichen würde kaum ein Unternehmen freiwillig auf einen einzigen unersetzbaren Lieferanten setzen, wenn dessen Ausfall den gesamten Betrieb stoppen könnte.

Bei KI geschieht genau das derzeit erstaunlich häufig.

Europa baut auf – aber der Rückstand bleibt

Die Europäische Kommission behandelt Souveränität inzwischen nicht mehr als reine Standortfrage. Ihr Cloud Sovereignty Framework bewertet Anbieter anhand von 48 Kriterien in acht Kategorien. Dazu zählen rechtliche und gerichtliche Kontrolle, Daten und KI, Betrieb, Lieferketten, technologische Autonomie sowie Sicherheit und Compliance.

Europa baut außerdem Kapazitäten bei Cloud, Halbleitern, KI und Open Source aus.

Das ist notwendig.

Aus meiner Sicht liegt Europas Rückstand aber weiterhin im gesamten Ökosystem: bei Rechenkapazität, Kapital, Plattformen, Entwicklerwerkzeugen, Beschaffungsgeschwindigkeit und internationaler Skalierung.

Europäische Anbieter können nicht wachsen, wenn Unternehmen zwar Souveränität fordern, bei jeder Kaufentscheidung aber ausschließlich den größten Funktionsumfang und den niedrigsten kurzfristigen Preis bewerten.

Souveränität kostet Geld.

Sie kostet manchmal auch Bequemlichkeit.

Fazit: Souverän ist, wer weiterarbeiten kann

Absolute technologische Souveränität ist kaum erreichbar.

Hardware, Software, Forschung und Lieferketten sind dafür zu stark international verflochten.

Strategische Handlungsfähigkeit ist dagegen erreichbar.

Ein Unternehmen ist nicht automatisch souverän, weil sein Server in Europa steht.

Es ist nicht automatisch souverän, weil es Mistral nutzt.

Es ist nicht automatisch souverän, weil ein Modell als Open Weight verfügbar ist.

Und es ist nicht souverän, nur weil ein Anbieter mit DSGVO oder AI Act wirbt.

Souveräner wird ein Unternehmen, wenn es seine Abhängigkeiten kennt, sie bewusst auswählt und im Ernstfall über getestete Alternativen verfügt.

Die entscheidende Frage lautet nicht:

Steht unser Server in Europa?

Die entscheidende Frage lautet:

Können wir weiterarbeiten, wenn unser wichtigster Anbieter morgen ausfällt oder nicht mehr liefern darf?

Wer darauf keine Antwort hat, besitzt möglicherweise eine datenschutzkonforme Infrastruktur.

Aber noch keine souveräne.