Im März 2026 bestätigte das deutsche Bundesamt für Sicherheit in der Informationstechnik, dass ein Pilotprojekt mit DeepSeek-V3 zur automatisierten Erstellung parlamentarischer Briefing-Zusammenfassungen klassifizierte Metadaten an einen DeepSeek-Servercluster in Shanghai übertragen hatte. Nicht die Dokumente selbst, sondern die Metadaten: Dokumentenklassifizierungen, interne Ausschusscodes, zeitgestempelte Zugriffsprotokolle. Die deutsche Regierung bemerkte erst, nachdem der Schaden bereits entstanden war, dass ihr KI-Tool klassifizierte Signale nach China übermittelte.

Europäische Sicherheitsverantwortliche haben jahrelang genau diese Art von Risiko auf der Infrastrukturebene geprüft: jurisdiktionale Risiken kartiert, Unternehmenssitze von Anbietern analysiert und Cloud-Abhängigkeiten neu bewertet. Diese Arbeit ist wichtig. Doch sie adressiert in erster Linie die Netzwerk- und Infrastrukturebene.
Der DeepSeek-Vorfall spielte sich eine Ebene darüber ab. Die KI-Ebene gehört inzwischen ebenfalls zum Prüfbereich – und die meisten Organisationen haben noch nicht einmal begonnen, sie systematisch zu auditieren.

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

In den vergangenen Jahren haben viele Sicherheitsverantwortliche erhebliche Arbeit geleistet: Sie haben Anbieterstandorte geprüft, jurisdiktionale Abhängigkeiten kartiert, Cloud-Strategien überdacht und von SASE-Anbietern Transparenz darüber verlangt, wo Daten gespeichert werden und welchem Recht sie unterliegen. Diese Arbeit adressiert jedoch eine bestimmte Schicht des Technologie-Stacks – die Netzwerk- und Infrastrukturebene.

KI ist inzwischen eine Ebene darüber tief integriert. Bedrohungserkennung, Alarm-Triage, Policy-Empfehlungen, Anomalieerkennung – all diese Funktionen werden zunehmend durch Modelle gesteuert. Und viele Organisationen haben diese KI-Abhängigkeiten genauso akzeptiert, wie sie vor fünf Jahren Cloud-Abhängigkeiten akzeptiert haben: schnell und ohne vollständig zu verstehen, worauf sie sich einlassen.

Organisationen, die auf Netzwerkebene souveräne Architekturen aufgebaut haben, haben die KI-Ebene häufig vollständig ungeprüft gelassen.

Jurisdiktion folgt dem Modell, nicht nur den Daten

Eine zentrale Erkenntnis jeder ernsthaften CLOUD-Act-Analyse lautet: Jurisdiktion folgt dem Unternehmen, nicht den Daten.
Es spielt keine Rolle, ob Ihre Daten in Frankfurt gespeichert sind, wenn Ihr Anbieter seinen Hauptsitz in Seattle hat. Die rechtliche Zuständigkeit der Muttergesellschaft kann unabhängig vom physischen Speicherort auf die Daten zugreifen.

Genau dieselbe Logik gilt für KI-Modelle – und DeepSeek verdeutlicht dies besonders deutlich. Laut Datenschutzerklärung speichert DeepSeek Daten auf Servern in der Volksrepublik China. Chinesisches Recht gewährt staatlichen Stellen weitreichende Zugriffsrechte auf Daten von Unternehmen mit Sitz in China. Selbst wenn DeepSeek innerhalb von EU-Mitgliedstaaten genutzt wurde, lief der API-Verkehr über Rechenzentren auf dem chinesischen Festland. Die Jurisdiktion folgte dem Modell, nicht dem Standort des Nutzers.

US-Bundesbehörden – darunter NASA und die US Navy – untersagten DeepSeek aus Gründen der nationalen Sicherheit. Italien, Australien, Südkorea und Taiwan führten ebenfalls Einschränkungen ein. Das Muster ist klar: Sobald Regulierungsbehörden verstanden, wohin Inferenzdaten flossen, bestand die Reaktion darin, den Zugriff zu verbieten oder stark zu beschränken.

Organisationen, die DeepSeek bereits produktiv eingesetzt hatten, mussten nachträglich reagieren. Dies ist im Grunde das Supply-Chain-Argument – eine Ebene höher angewendet. Nicht Ihr SASE-Anbieter diesmal. Ihr KI-Modell.

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

Die meisten Organisationen, die heute Jurisdiktions-Audits durchführen, stellen grundsätzlich die richtigen Fragen:

  • Wo ist mein SASE-Anbieter registriert?
  • Wo speichert meine Cloud-Plattform Telemetriedaten?
  • Wer ist die Muttergesellschaft meines Managed-Services-Providers?

Das sind wichtige Fragen. Die Übernahme des niederländischen Cloud-Anbieters Solvinity, bei der eine souveräne Cloud-Lösung über Nacht unter US-Jurisdiktion fiel, hat gezeigt, warum.

Doch stellen Sie denselben Organisationen eine andere Frage: Welche KI-Modelle sind in Ihrem Security-Stack eingebettet? Wo laufen sie? Welche Richtlinien gelten für die Speicherung von Inferenzdaten? Die meisten können darauf keine Antwort geben.

Security-Operations-Plattformen integrieren derzeit Large Language Models in hoher Geschwindigkeit und ohne ausreichende Prüfung. Anbieter liefern KI-gestützte Alarm-Triage, natürliche Suchabfragen oder automatisierte Policy-Optimierung – häufig auf Basis von Drittanbieter-Modellen, deren Jurisdiktionsrisiken vollständig übernommen werden.

Der DeepSeek-Vorfall war sichtbar, weil es sich um einen bekannten chinesischen Anbieter handelte. Doch das strukturelle Risiko existiert bei jedem Modell, das ausserhalb der eigenen Rechtsordnung betrieben wird – sofern nicht geprüft wurde, wohin Inferenzdaten fliessen, wer darauf zugreifen kann und welchem rechtlichen Rahmen dies unterliegt.

Was „souveräne KI“ in der Security tatsächlich bedeutet

Souveräne KI bedeutet nicht zwangsläufig, Modelle lokal im eigenen Rechenzentrum zu betreiben – in den meisten Unternehmensumgebungen wäre das unpraktisch und mit erheblichen Performance-Einbussen verbunden.

Es bedeutet etwas Operativeres:

  • zu wissen, welches Modell welche Entscheidung trifft,
  • wo dieses Modell läuft,
  • wer rechtlich Zugriff auf die Inferenzdaten hat,
  • und welche Rolle das Modell im operativen Ablauf spielt.

Es besteht ein erheblicher Unterschied zwischen zwei Betriebsmodellen:

  1. KI unterstützt menschliche Analysten – sie liefert Signale und beschleunigt Entscheidungen.
  2. KI entscheidet standardmässig selbst, während Menschen nur Ausnahmen prüfen.

Im ersten Modell ist das Risiko eines kompromittierten oder rechtlich zugänglichen Modells begrenzt. Im zweiten nicht.

Ein einfacher Test: Wenn eine ausländische Regierung Ihrem KI-Anbieter eine rechtmässige Datenanfrage stellt – was würde dieser übergeben?

  • Inferenz-Logs?
  • Abfragehistorien?
  • Anomalieerkennungs-Muster aus Ihrer Umgebung?

Wenn Sie diese Frage nicht beantworten können, befindet sich in Ihrem Stack ein nicht geprüftes Risiko.

Was Security-Verantwortliche jetzt prüfen sollten

  1. Kartieren Sie die KI in Ihrem Security-Operations-Stack.
    Listen Sie jede KI-gestützte Funktion Ihrer Security-Tools auf: Alarm-Triage, Threat Detection, Policy-Empfehlungen, automatisierte Reaktionen. Identifizieren Sie für jede Funktion das zugrunde liegende Modell und dessen Betreiber.
  2. Wenden Sie denselben Jurisdiktionstest an wie bei Ihrem SASE-Anbieter.
    Wo hat der Modellanbieter seinen Sitz? Wohin fliessen Inferenzdaten? Was sagt die Datenschutzerklärung über Datenspeicherung, staatliche Zugriffe und Datenresidenz?
  3. Prüfen Sie, ob Inferenzdaten für Modelltraining verwendet werden.
    Mehrere KI-Anbieter behalten sich das Recht vor, API-Interaktionsdaten zur Verbesserung ihrer Modelle zu nutzen. In einem Security-Kontext bedeutet das: Signale aus Ihrer Umgebung – etwa Abfrage-Muster, Alarmkategorien oder Netzwerktelemetrie – könnten in Modelle einfliessen, die auch anderen Kunden zur Verfügung stehen.
  4. Fragen Sie nach Transparenz bei KI-Entscheidungen.
    Kann Ihr Managed-Security- oder SASE-Anbieter genau erklären, welche Modelle bei welchen Entscheidungen eingesetzt werden, wo diese Modelle laufen und welche Daten sie erhalten?

Bei Open Systems – mit Hauptsitz in der Schweiz und ausserhalb der Reichweite des US CLOUD Act sowie chinesischer Gesetzgebung – laufen KI-gestützte Funktionen innerhalb einer Managed-SASE-Architektur, in der nachvollziehbar ist, was läuft, wo es läuft und welche Entscheidungen von Technologie versus von Menschen getroffen werden.
Operative Transparenz auf der KI-Ebene ist kein Zusatzfeature. Sie ist eine grundlegende Voraussetzung.

Der Stack reicht höher, als viele denken

Die Arbeit europäischer Security-Verantwortlicher zur Datensouveränität auf Infrastrukturebene ist real und wichtig. Doch Souveränität ist kein Problem, das man einmal auf einer Ebene löst und danach abhaken kann. KI ist inzwischen Teil Ihrer Sicherheitsinfrastruktur.

Der DeepSeek-Fall war kein Randereignis eines unvorsichtigen Unternehmens. Es handelte sich um ein Regierungsprojekt, betreut von Fachleuten, die sich der Risiken bewusst waren – und dennoch wurden klassifizierte Signale an eine ausländische Jurisdiktion übertragen, weil die KI-Ebene nicht mit derselben Aufmerksamkeit geprüft wurde wie die darunterliegende Infrastruktur.

Das vierte Risiko ist bereits da. Die Frage ist nur, ob Ihr Audit es abdeckt. Souveränität auf der Netzwerkebene ist notwendig, aber nicht mehr ausreichend. Wenn Ihre aktuelle Architekturprüfung die KI-Ebene nicht einschliesst, ist genau dort die wichtigste Lücke.

Kontaktieren Sie das Open-Systems-Team, um zu besprechen, wie ein Souveränitäts-Audit aussehen kann, das den gesamten Technologie-Stack abdeckt.