KI-Souveränität: Die vierte Risikoebene, die Sie noch nicht auditiert haben

Im März 2026 bestätigte das Bundesamt für Sicherheit in der Informationstechnik, dass ein Pilotprojekt, das DeepSeek-V3 für automatisierte Zusammenfassungen parlamentarischer Briefings einsetzte, klassifizierte Metadaten an DeepSeeks Server-Cluster in Shanghai übertragen hatte. Nicht die Dokumente selbst - die Metadaten: Einstufungsvermerke der Dokumente, interne Ausschusskennungen, Zugriffsprotokolle mit Zeitstempel. Dass ihr KI-Tool klassifizierte Signale nach China sendete, bemerkte die deutsche Regierung erst, als der Schaden bereits angerichtet war.

Europäische Sicherheitsverantwortliche haben jahrelang die Infrastrukturebene auf genau diese Art von Exposition geprüft: Jurisdiktionsrisiken kartiert, Hauptsitze von Anbietern geprüft, Cloud-Abhängigkeiten überdacht. Diese Arbeit ist wichtig. Aber sie adressiert die Netzwerkebene. Der DeepSeek-Vorfall spielte sich eine Ebene höher ab. Die KI-Ebene gehört jetzt zum Prüfumfang - und die meisten Organisationen haben mit deren Audit noch gar nicht begonnen.

Das Problem, das Sie für gelöst hielten, ist nicht gelöst

In den vergangenen Jahren haben viele Sicherheitsverantwortliche die mühsame Arbeit geleistet: Hauptsitze von Anbietern auditiert, jurisdiktionelle Exposition kartiert, Cloud-Abhängigkeiten hinterfragt, SASE-Anbieter dazu gedrängt offenzulegen, wo Daten gespeichert sind und welchem Recht sie unterliegen. Diese Arbeit adressiert eine bestimmte Schicht des Stacks - die Netzwerk- und Infrastrukturebene.

KI ist inzwischen eine Ebene darüber tief verankert. Threat Detection, Alert-Triage, Policy-Empfehlungen, Anomalieerkennung - all das wird zunehmend von Modellen getrieben. Und die meisten Organisationen haben diese KI-Abhängigkeiten genauso akzeptiert wie vor fünf Jahren ihre Cloud-Infrastruktur-Abhängigkeiten: schnell und ohne vollständig zu verstehen, worauf sie sich einlassen.

Organisationen, die auf der Netzwerkebene souveräne Architekturarbeit geleistet haben, haben die KI-Ebene oft völlig ungeprüft gelassen.

Die Jurisdiktion folgt dem Modell, nicht nur den Daten

Das Kernprinzip jeder ernsthaften CLOUD-Act-Analyse lautet: Die Jurisdiktion folgt dem Unternehmen, nicht den Daten. Es spielt keine Rolle, ob Ihre Daten in Frankfurt liegen, wenn Ihr Anbieter seinen Hauptsitz in Seattle hat. Der rechtliche Zugriff der Muttergesellschaft erstreckt sich auf die Daten, egal wo sie physisch gespeichert sind.

Dieselbe Logik gilt für KI-Modelle - und DeepSeek führt sie mustergültig vor. DeepSeeks Datenschutzerklärung hält fest, dass Daten auf Servern in der Volksrepublik China gespeichert werden. Chinesisches Recht räumt Peking weitreichende Befugnisse ein, auf Daten von Unternehmen mit Hauptsitz in China zuzugreifen. Selbst wenn DeepSeek innerhalb von EU-Mitgliedstaaten genutzt wurde, lief der API-Traffic über Rechenzentren auf dem chinesischen Festland. Die Jurisdiktion des Modells folgte dem Modell, nicht dem Standort des Nutzers.

US-Bundesbehörden - die NASA, die US Navy und andere - verboten DeepSeek aus Gründen der nationalen Sicherheit. Italien, Australien, Südkorea und Taiwan führten allesamt Beschränkungen ein. Das Muster ist konsistent: Sobald die Regulierer verstanden, wohin die Inferenzdaten flossen, war die Antwort ein Verbot oder eine Zugangsbeschränkung. Organisationen, die DeepSeek bereits in Produktionsumgebungen ausgerollt hatten, mussten im Nachhinein hektisch umsteuern.

Das ist das Lieferketten-Argument, eine Ebene höher angewendet. Diesmal geht es nicht um Ihren SASE-Anbieter. Sondern um Ihr KI-Modell.

Die Audit-Lücke, die die meisten Security-Teams übersehen

Die meisten Organisationen, die heute die Jurisdiktion ihrer Anbieter auditieren, prüfen die richtigen Dinge: Wo ist mein SASE-Anbieter eingetragen? Wo speichert meine Cloud-Plattform Telemetrie? Wer ist die Muttergesellschaft meines Managed-Services-Providers? Das sind gute Fragen. Die Solvinity-Übernahme in den Niederlanden - bei der eine souveräne Cloud-Entscheidung über Nacht zu einer US-Jurisdiktionsexposition wurde - hat gezeigt, warum sie zählen.

Fragen Sie dieselben Organisationen aber, welche KI-Modelle in ihrem Security-Stack stecken, wo diese Modelle laufen und welche Aufbewahrungsrichtlinien die Anbieter für Inferenzdaten haben: Die meisten können es nicht beantworten. Security-Operations-Plattformen haben Large Language Models in hohem Tempo und ohne genaue Prüfung integriert. Anbieter haben KI-gestützte Alert-Triage, natürlichsprachliche Abfrage-Interfaces und automatisiertes Policy-Tuning ausgeliefert - oft aufgesetzt auf Modell-APIs von Drittanbietern, die die jurisdiktionelle Exposition des jeweiligen Herstellers erben.

Der DeepSeek-Vorfall war sichtbar, weil ein bekannter chinesischer KI-Anbieter beteiligt war. Dasselbe strukturelle Risiko besteht aber bei jedem Modell, das außerhalb der Jurisdiktion Ihrer Organisation gehostet wird - sofern Sie nicht verifiziert haben, wohin die Inferenzdaten fließen, wer darauf zugreifen kann und unter welchem Rechtsrahmen.

Was souveräne KI in der Security wirklich bedeutet

Souveräne KI in der Security heißt nicht zwingend, Modelle lokal on-premises zu betreiben - in den meisten Enterprise-Umgebungen ist das unpraktikabel, und die Einbußen bei der Performance sind erheblich. Es bedeutet etwas Operativeres: zu wissen, welches Modell welche Entscheidung trifft, wo es läuft, wer rechtlich Zugriff auf die Inferenzdaten hat und welche Betriebsphilosophie gilt, wenn der Output eines Modells eine Sicherheitsaktion auslöst.

Es macht einen wesentlichen Unterschied, ob KI in einem Deployment-Modell menschliche Analysten unterstützt - Signale sichtbar macht, Entscheidungen beschleunigt - oder ob KI standardmäßig entscheidet und Menschen nur die Ausnahmen prüfen. Im ersten Modell ist die Risikoexposition eines kompromittierten oder rechtlich zugreifbaren Modells begrenzt. Im zweiten nicht.

Ein praktischer Test: Wenn eine ausländische Regierung Ihrem KI-Anbieter ein rechtmäßiges Datenersuchen vorlegte - was würde er herausgeben? Inferenz-Logs? Abfrage-Historien? Anomalieerkennungsmuster aus Ihrer Umgebung? Wenn Sie diese Frage nicht beantworten können, haben Sie ein unauditiertes Risiko in Ihrem Stack.

Was Sicherheitsverantwortliche jetzt auditieren sollten

• Kartieren Sie die KI in Ihrem Security-Operations-Stack. Listen Sie jede KI-gestützte Funktion in Ihren Security-Tools auf: Alert-Triage, Threat Detection, Policy-Empfehlungen, automatisierte Response. Identifizieren Sie für jede das zugrunde liegende Modell und dessen Betreiber. Viele Security-Plattformen betten Modelle von Drittanbietern ein; die KI-Funktion und der Modellanbieter sind oft unterschiedliche Unternehmen.

• Wenden Sie denselben Jurisdiktionstest an wie bei Ihrem SASE-Anbieter. Wo hat der Modellanbieter seinen Hauptsitz? Wohin fließen die Inferenzdaten? Was sagt die Datenschutzerklärung des Anbieters zu Datenaufbewahrung, Behördenzugriff und Datenresidenz? Wenn der Vertrag diese Fragen nicht beantwortet, muss er es künftig tun.

• Prüfen Sie, ob Inferenzdaten aus Ihrer Umgebung für das Modelltraining genutzt werden. Mehrere KI-Anbieter behalten sich das Recht vor, API-Interaktionsdaten zur Verbesserung ihrer Modelle zu verwenden. Im Security-Kontext heißt das: Signale aus Ihrer Umgebung - Abfragemuster, Alert-Kategorien, selbst Netzwerktelemetrie - könnten in Modelle einfließen, die andere Kunden nutzen. Das ist ein Datenabfluss-Risiko mit einem anderen Profil als klassische Exfiltration.

• Fragen Sie, wie Ihr Managed-Security- oder SASE-Anbieter Transparenz über KI-Entscheidungen herstellt. Kann er Ihnen sagen, welche Modelle an welchen Entscheidungen beteiligt sind, wo diese Modelle laufen und welche Daten sie erhalten? Bei Open Systems - mit Hauptsitz in der Schweiz, außerhalb der Reichweite des US CLOUD Act wie auch der chinesischen Rechtshoheit - laufen KI-gestützte Funktionen innerhalb einer Managed-SASE-Architektur, in der wir Rechenschaft darüber ablegen können, was läuft, wo es läuft und welche Entscheidungen von Tools und welche von Menschen getroffen werden. Operative Transparenz auf der KI-Ebene ist kein Bonus-Feature. Sie ist eine Grundvoraussetzung.

Der Stack reicht höher, als Sie dachten

Die Arbeit, die europäische Sicherheitsverantwortliche bei der Datensouveränität auf der Infrastrukturebene geleistet haben, ist real und sie zählt. Aber Souveränität ist kein Problem, das man einmal auf einer Ebene des Stacks löst und dann abhakt.

KI ist inzwischen Teil Ihrer Sicherheitsinfrastruktur. Der DeepSeek-Fall war kein Randphänomen einer leichtsinnigen Organisation. Es war ein Pilotprojekt einer Regierung, betreut von Menschen, die wussten, was auf dem Spiel steht - und trotzdem gelangten klassifizierte Signale in eine fremde Jurisdiktion, weil die KI-Ebene nicht derselben Kontrolle unterlag wie die Infrastruktur darunter.

Das vierte Risiko ist da. Die Frage ist, ob Ihr Audit es abdeckt.

Souveränität auf der Netzwerkebene ist notwendig, aber nicht mehr hinreichend. Wenn Ihr aktuelles Architektur-Review die KI-Ebene nicht einschließt, ist das die Lücke, die Sie zuerst schließen sollten. Nehmen Sie Kontakt mit dem Open-Systems-Team auf, um zu besprechen, wie ein Souveränitäts-Audit aussieht, das für Ihre Organisation den gesamten Stack abdeckt.