Zum Inhalt springen
Zurück
DeepSeek ban supply chain audit NIS2 compliance enterprise
DeepSeek-Verbot Lieferkettenprüfung

DeepSeek-Verbot löst NIS2-Lieferkettenprüfung aus

Das Verbot von DeepSeek zwingt EU-Unternehmen zur Inventur nicht-souveräner Modellabhängigkeiten gemäß NIS2 Artikel 21.

Das DeepSeek-Verbot ist kein rein geopolitisches Spektakel, sondern ein Auslöser für Lieferkettenprüfungen gemäß NIS2 Artikel 21, der Enterprise-IT-Führungskräfte zwingt, alle nicht-souveränen Modellabhängigkeiten zu inventarisieren, bevor Regulierungsbehörden ihre umfassendere Bewertung abschließen.

TL;DR: Die DHS-Order #2026-01 verlangt die Entfernung von DeepSeek aus zivilen Bundes-IT-Systemen gemäß FASCSA 2018 und begründet dies mit mehreren Bedrohungsvektoren sowie Datenübertragungsrisiken an die VR China. EU-Unternehmen müssen dies als NIS2-Artikel-21-Auslöser behandeln und sofort eine Inventur nicht-souveräner Modellabhängigkeiten durchführen.

Wichtigste Erkenntnisse

  • Regulatorischer Auslöser: Die DHS-Order unter FASCSA 2018 dient als konkreter Auslöser für die Lieferkettenrisikomanagement-Pflichten des Artikels 21, der dokumentierte Nachweise des Abhängigkeitsmanagements erfordert.
  • Geltungslücke: Während Wettbewerber Marktanteile analysieren, deckt die Order explizit zivile Behörden (Finanzen, Außenministerium, Justiz) ab, schließt aber das Verteidigungsministerium aus, was eine sofortige Klassifizierungsherausforderung für Unternehmen mit dualen zivilen und Verteidigungsfunktionen darstellt.
  • Datensouveränitätsrisiko: Die Bedenken der DHS bezüglich der "Übertragung sensibler Daten an die VR China" begründen eine Präzedenzwirkung, die EU-Anforderungen an Datensouveränität gemäß GDPR und AI Act nun transitive Risiken über Modell-APIs berücksichtigen muss.
  • Staats-level-Kaskade: Historische Muster nach federalen Huawei- und TikTok-Beschränkungen legen nahe, dass gliedstaatliche Regierungen Beschaffungseinschränkungen innerhalb von zwei bis drei Monaten erlassen werden, was eine Compliance-Klippe für Multi-State-Betriebe schafft.
  • Prüfpriorität: Die Formulierung "mehrere Bedrohungsvektoren" deutet darauf hin, dass der Audit-Umfang über DeepSeek hinaus auf andere chinesische Open-Weight-Anbieter ausgedehnt werden muss, was eine umfassende nicht-souveräne Inventur statt einer Einzelanbieterprüfung erfordert.

Wettbewerber übersehen das regulatorische Signal im geopolitischen Lärm

Marktanalysen von Tech Insider konzentrieren sich auf die Release-Kadenz von DeepSeek und die Wettbewerbspositionierung gegenüber US-Rivalen und stellen fest, dass die Unternehmenswachstumskurve im kommerziellen Markt unverändert bleibt. Diese Analyse erfasst die kommerzielle Narrative, verfehlt jedoch die operative Realität für EU-Unternehmen, die gemischte US- und chinesische Modellabhängigkeiten verwalten.

Die Trump-Administration hat ein Verbot erlassen, das allen zivilen US-Bundesbehörden die Nutzung des chinesischen KI-Startups DeepSeek unter Berufung auf nationale Sicherheitsbedenken untersagt (leadstory.com).

Das Verbot, erlassen unter dem Federal Acquisition Supply Chain Security Act von 2018 (nypost.com), zielt spezifisch auf Behörden wie das Finanzministerium, das Außenministerium und das Justizministerium ab, während es das Verteidigungsministerium explizit ausnimmt (BBC News).

Der Unterschied zwischen ziviler und Verteidigungs-Abdeckung ist operativ bedeutsam für Unternehmen mit Dual-Use-Verträgen.

Die Order untersagt der chinesischen Firma die Teilnahme an Bundesverträgen und ordnet die Entfernung aus IT-Geräten an (Bloomberg); ob sie sich automatisch auf private Cloud-Umgebungen von Auftragnehmern erstreckt, wird in dieser Quelle nicht behandelt.

Diese Lücke schafft eine Klassifizierungsambiguität: Wenn ein Auftragnehmer DeepSeek über eine API nutzt, die auf einer nicht-bundesstaatlichen Cloud-Instanz gehostet wird, ist diese Bereitstellung von der Removal Order abgedeckt oder lediglich zukünftigen gliedstaatlichen Vorschriften unterworfen?

NIS2 Artikel 21 – Ihr Lieferkettenprüfungsauslöser

Das Verbot fungiert als praktischer Auslöser für NIS2 Artikel 21, der Unternehmen verpflichtet, "angemessene und verhältnismäßige technische und organisatorische Maßnahmen zu ergreifen, die darauf ausgelegt sind, die mit der Sicherheit von Netz- und Informationssystemen verbundenen Risiken zu bewirtschaften." Artikel 21 gilt für alle mittleren und großen Unternehmen in kritischen Sektoren und verlangt spezifisch die Identifikation und Dokumentation von Lieferkettenabhängigkeiten.

Ein Beispiel-Szenario: Ein Enterprise-Procurement-Team setzt DeepSeek per API für Dokumentenanalyse-Workflows im Q3 2026 ein. Am 24. Juli tritt die DHS-Order in Kraft. Bis Oktober erhält das Team eine Benachrichtigung von seinem internen Risikokomitee, dass NIS2 Artikel 21 dokumentierte Nachweise des Lieferkettenrisikomanagements für alle kritischen IKT-Komponenten erfordert. Das Team muss sofort nicht nur DeepSeek, sondern alle abgeleiteten Abhängigkeiten inventarisieren – einschließlich fine-tuned-Modelle, die auf EU-Infrastruktur gehostet, aber mit DeepSeek-Gewichten trainiert wurden.

Der Bewertungsrahmen für Artikel 21 erfordert eine systematische Evaluierung nicht-souveräner Modellabhängigkeiten:

Lieferkettenrisikobewertung: Kritische Abhängigkeiten

  • 🔴 Kritisch: Direkte Bereitstellung von DeepSeek-Modellen oder APIs, die chinesisch-souveräne Modellausgaben zurückgeben; Anbieter ohne EU-rechtliche Entität mit Datenlokalisierungszusicherungen
  • 🟡 Erhöht: US-sitzende Modelle mit Trainingsdaten, die auf nicht-europäischer Compute verarbeitet werden; hybride Architekturen mit Kombination aus souveränen und nicht-souveränen Komponenten; Anbieter mit Standardvertragsklauseln (SCCs), aber ohne ergänzende Maßnahmen für Datentransfers
  • 🟢 Standard: Vollständig selbstgehostete Open-Weight-Modelle mit vollständigen Prüfpfaden, Datenspeicherung in der EU/EEA und keiner Abhängigkeit von chinesischen Open-Weight-Modellgewichten oder Trainingspipelines

Die obige Ampel-Klassifizierung ist nicht nur beratend. Nach NIS2 Artikel 21 Absatz 1 Buchstabe b müssen Unternehmen "systematische Richtlinien und Verfahren" für das Management von IKT-Lieferkettenrisiken umsetzen. Ein Anbieter, der ein nicht-souveränes Modell ohne dokumentierte Exit-Strategie oder Datenlokalisierungsverpflichtung nutzt, fällt in die Kategorie 🔴 und erfordert sofortige Behebung oder vertragliche Beendigung.

Die DHS erhob ausdrücklich Bedenken, dass die Nutzung des Produkts "to the transfer of sensitive data to the PRC if used by U.S. government employees or vendors" (CNA) führen könnte. Diese Aussage begründet eine faktische Grundlage für Artikel-21-Risikobewertungen in EU-Rechtsordnungen, selbst für Unternehmen, die nicht direkt US-Recht unterliegen. Das Risiko ist nicht hypothetisch: das Verbot verhindert, dass alle zivilen US-Bundesbehörden DeepSeek nutzen (leadstory.com), was es effektiv aus dem federalen Beschaffungswesen entfernt und sofortige Lieferkettenfragmentierung schafft.

Drei Prüfschritte zur sofortigen Compliance-Umsetzung

Wettbewerber, die Marktanteilsmetriken analysieren, übersehen den praktischen Durchsetzungsmechanismus. NIS2 Artikel 21 erfordert dokumentierte Nachweise des Risikomanagements, keine bloßen Absichtserklärungen. Der folgende dreistufige Prüfprozess transformiert das DHS-Verbot von einer geopolitischen Schlagzeile in eine Compliance-Aktivierung:

  1. Abhängigkeitsinventur: Erfassen Sie alle LLM-APIs, Modellendpunkte und Inferenzdienste, die derzeit in Unternehmensumgebungen aktiv sind. Schließen Sie Schatten-IT-Instanzen ein, bei denen Abteilungen DeepSeek möglicherweise für interne Pilotprojekte ohne IT-Beschaffungsaufsicht eingesetzt haben. Die KI-Lieferketten-Sicherheit erfordert dynamische Provenienzprüfung für alle Open-Weight-Modelle, insbesondere solche aus Nicht-EU-Rechtsordnungen.
  2. Datenspur-Mapping: Verfolgen Sie den Lebenszyklus von Daten, die von nicht-souveränen Modellen verarbeitet werden. Nach Artikel 21 Absatz 1 Buchstabe a müssen Unternehmen "relevante Informationen" über das IKT-Lieferkettenrisikomanagement identifizieren. Dazu gehört das Verständnis, ob Trainingsdaten, Inferenzeingaben oder Modellgewichte Nicht-EU-Rechtsordnungen durchlaufen oder für Nicht-EU-Behörden zugänglich sind. Die Software-Lieferkettensicherheit erfordert selbstgehostete Registries, um transitive Abhängigkeitsrisiken zu verhindern, die die wahre Herkunft von KI-Modellausgaben verschleiern.
  3. Vertragliche und Beschaffungsprüfung: Bewerten Sie alle bestehenden Verträge und Beschaffungsrahmenwerke auf Klauseln zur Modellabhängigkeit. Bestimmen Sie, ob Anbieter clauses enthalten, die das Unternehmen gegen regulatorische Bußgelder aufgrund nicht-souveräner Modellnutzung schützen. Die GDPR-Compliance als Wettbewerbsvorteil erstreckt sich auf die KI-Beschaffung: Verträge müssen Datenspeicherung, Modellsouveränität und Prüfrechte spezifizieren, die sowohl Artikel 21 als auch GDPR-Artikel-46-Transferanforderungen erfüllen.

Das stärkste Gegenargument für sofortiges Handeln sind vertragliche Schutzmechanismen und Standard-Anbieter-SLAs, die den Käufer angeblich vor Upstream-Lieferkettenrisiken schützen. Diese vertraglichen Schutzmechanismen bieten jedoch keine Verteidigung gegen regulatorische Durchsetzung nach NIS2. Eine Anbieter-Indemnitätsklausel kann die primäre Verpflichtung des Unternehmens nach Artikel 21 nicht außer Kraft setzen, das eigene IKT-Lieferkettenrisiko zu bewirtschaften. Regulierungsbehörden werden dokumentierte Risikomanagementpraktiken bewerten, nicht vertragliche Haftungsbeschränkungen.

Von NIS2 zu DORA – Folgen für die KI-Beschaffung

Für Finanzdienstleistungsunternehmen, die bereits dem Digital Operational Resilience Act (DORA) unterliegen, schafft das DeepSeek-Verbot eine Konvergenz der Anforderungen an das IKT-Drittanbieter-Risikomanagement. DORA Artikel 28 verpflichtet Finanzunternehmen, die finanzielle Lebensfähigkeit von IKT-Drittanbietern zu bewerten, während NIS2 Artikel 21 sich auf Sicherheits- und Resilienzrisiken konzentriert. Beide Verordnungen konvergieren auf dieselbe technische Realität: operationale Abhängigkeit von nicht-souveränen Modellen schafft unquantifizierbares Restrisiko, das nicht durch vertragliche Klauseln allein gemildert werden kann.

Die DORA-Anforderung für IKT-Drittanbieter-Risikomanagement mapt direkt auf NIS2-Lieferkettenanforderungen. Ein Unternehmen, das DeepSeek für kundenorientierte KI-Features betreibt, muss nicht nur die Sicherheitslage des Modells, sondern dessen Lieferkettenherkunft dokumentieren. Diese Dokumentationslast liegt beim Unternehmen, nicht beim Anbieter, unter beiden Regimen.

Die Trump-Administration hat zivilen US-Bundesbehörden die Nutzung von Produkten und Dienstleistungen von DeepSeek untersagt, wobei Bundesbehörden verpflichtet sind, alle DeepSeek-Produkte aus ihren Systemen zu entfernen (Bloomberg).

EU-Unternehmen mit US-Muttergesellschaften oder Bundesauftragnehmern müssen duale Compliance-Verpflichtungen navigieren: US-federalen Anforderungen genügen, während EU-Datensouveränitätsstandards beibehalten werden. Diese regulatorische Divergenz schafft eine Compliance-Klippe für multinationale Organisationen.

Warum US-Verbote souveräne KI beschleunigen

Das Verbot eliminiert einen wichtigen Kostenwettbewerber aus federalen Beschaffungsberechnungen und nimmt den Preisdruck, der zuvor Open-Weight-China-Modelle gegenüber EU-souveränen Alternativen begünstigte. Das regulatorische Risiko, das durch die DHS-Order eingeführt wird, beschleunigt jedoch letztlich die Adoption souveräner KI-Modelle nicht aus Patriotismus, sondern weil die Prüfkosten die nicht-souveräne Bereitstellung für mittlere und große Unternehmen operativ irrational machen.

Unternehmen stehen vor einer binären Wahl bei der Bewertung von Modellbeschaffungen: Akzeptieren Sie die Artikel-21-Dokumentationslast und laufende Compliance-Monitoringskosten für nicht-souveräne Modelle oder stellen Sie vollständig selbstgehostete Open-Weight-Modelle bereit, bei denen Datenspeicherung und Lieferkettenherkunft vollständig kontrolliert werden. Die von der DHS identifizierten "mehreren Bedrohungsvektoren" – einschließlich potenzieller Datentransfers in die VR China und Ausrichtung an chinesische Regierungsinteressen – übersetzen sich in spezifische Compliance-Kosten nach NIS2, die westliche Modellanbieter nicht tragen.

Marktanalysen deuten darauf hin, dass gliedstaatliche Regierungen Beschaffungseinschränkungen im Gefolge der federalen Maßnahme innerhalb von zwei bis drei Monaten erlassen werden. Dieser Kaskadeneffekt bedeutet, dass Unternehmen, die derzeit Modellstrategien evaluieren, ein schrumpfendes Zeitfenster haben, bevor Einschränkungen über zivile Bundesbehörden hinaus auf gliedstaatlicher Ebene wirksam werden. Die KI-Lieferketten-Sicherheit erfordert dynamische Provenienzprüfung, um Vendor-Lock-in mit nicht-souveränen Anbietern zu verhindern, während die regulatorische Umgebung strafft.

Fazit: Führen Sie die Inventur durch, bevor Regulierungsbehörden es tun

Wettbewerber analysieren weiterhin Marktanteile, während Unternehmen vor einem konkreten regulatorischen Auslöser stehen. Die DHS-Order #2026-01, erlassen unter dem FASCSA-Gesetz von 2018 und mit Verweis auf „mehrere Bedrohungsvektoren" einschließlich Datenübertragungsrisiken an die VR China, verpflichtet EU-Unternehmen, NIS2 Artikel 21 als sofortige Compliance-Anforderung zu behandeln. Führen Sie eine umfassende Inventur aller nicht-souveränen Modellabhängigkeiten durch, bevor Regulierungsbehörden Lücken identifizieren. Die heute etablierte Prüfkette wird sowohl NIS2-Artikel-21- als auch DORA-IKT-Drittranbieter-Risikomanagementanforderungen erfüllen.

Klingt das nach Ihrem Use Case? Sprechen wir.

Schicken Sie uns Ihre E-Mail. Optional: Was beschäftigt Sie gerade?

Häufige Fragen

Das DeepSeek-Verbot fungiert als praktischer regulatorischer Auslöser für die Lieferkettenprüfungspflichten nach NIS2 Artikel 21. Dieser Artikel verpflichtet Unternehmen, angemessene und verhältnismäßige technische und organisatorische Maßnahmen zu ergreifen, die darauf ausgelegt sind, die mit der Sicherheit von Netz- und Informationssystemen verbundenen Risiken zu bewirtschaften. Artikel 21 gilt für alle mittleren und großen Unternehmen in kritischen Sektoren und verlangt speziell die Identifikation und Dokumentation von Lieferkettenabhängigkeiten. Die DHS-Order unter FASCSA 2018 erfordert dokumentierte Nachweise des Abhängigkeitsmanagements, bevor Regulierungsbehörden ihre umfassendere Bewertung abschließen. Unternehmen müssen daher sofort eine Inventur aller nicht-souveräner Modellabhängigkeiten durchführen, bevor die Aufsichtsbehörden ihr Bewertungsverfahren abschließen.

Die DHS-Order zielt spezifisch auf zivile Bundesbehörden wie das Finanzministerium, das Außenministerium und das Justizministerium ab. Das Verteidigungsministerium wird in der Order explizit ausgenommen. Dieser Unterschied zwischen ziviler und Verteidigungs-Abdeckung ist operativ bedeutsam für Unternehmen mit Dual-Use-Verträgen, da eine Klassifizierungsambiguität entsteht. Die Order untersagt der chinesischen Firma die Teilnahme an Bundesverträgen und ordnet die Entfernung aus IT-Geräten an, erstreckt sich jedoch nicht automatisch auf private Cloud-Umgebungen von Auftragnehmern. Wenn ein Auftragnehmer DeepSeek über eine API nutzt, die auf einer nicht-bundesstaatlichen Cloud-Instanz gehostet wird, ist unklar, ob diese Bereitstellung von der Removal Order abgedeckt ist oder lediglich zukünftigen gliedstaatlichen Vorschriften unterworfen wird.

Der Bewertungsrahmen für Artikel 21 erfordert eine systematische Evaluierung nicht-souveräner Modellabhängigkeiten über eine Ampel-Klassifizierung. 🔴 Kritisch sind direkte Bereitstellung von DeepSeek-Modellen oder APIs, die chinesisch-souveräne Modellausgaben zurückgeben, sowie Anbieter ohne EU-rechtliche Entität mit Datenlokalisierungszusicherungen. 🟡 Erhöht sind US-sitzende Modelle mit Trainingsdaten, die auf nicht-europäischer Compute verarbeitet werden, hybride Architekturen und Anbieter mit Standardvertragsklauseln ohne ergänzende Maßnahmen. 🟢 Standard sind vollständig selbstgehostete Open-Weight-Modelle mit vollständigen Prüfpfaden und Datenspeicherung in der EU/EEA. Nach Artikel 21 Absatz 1 Buchstabe b müssen systematische Richtlinien und Verfahren umgesetzt werden; ein Anbieter ohne dokumentierte Exit-Strategie fällt in die Kategorie 🔴.

Ein dreistufiger Prüfprozess transformiert das DHS-Verbot von einer geopolitischen Schlagzeile in eine Compliance-Aktivierung. Der erste Schritt ist die Abhängigkeitsinventur, bei der alle LLM-APIs, Modellendpunkte und Inferenzdienste erfasst werden, einschließlich Schatten-IT-Instanzen. Der zweite Schritt ist das Datenspur-Mapping des Lebenszyklus von Daten, die von nicht-souveränen Modellen verarbeitet werden; nach Artikel 21 Absatz 1 Buchstabe a müssen relevante Informationen über das IKT-Lieferkettenrisikomanagement identifiziert werden. Der dritte Schritt ist die vertragliche und Beschaffungsprüfung, bei der alle bestehenden Verträge auf Klauseln zur Modellabhängigkeit bewertet werden. NIS2 Artikel 21 erfordert dokumentierte Nachweise des Risikomanagements, keine bloßen Absichtserklärungen.

Die GDPR-Compliance erstreckt sich auf die KI-Beschaffung und wird zum Wettbewerbsvorteil. Verträge müssen Datenspeicherung, Modellsouveränität und Prüfrechte spezifizieren, die sowohl Artikel 21 als auch GDPR-Artikel-46-Transferanforderungen erfüllen. Nach der CNA-Bewertung könnte die Nutzung des Produkts zur Übertragung sensibler Daten an die VR China führen, wenn es von US-Regierungsmitarbeitern oder Auftragnehmern verwendet wird. Diese Aussage begründet eine faktische Grundlage für Artikel-21-Risikobewertungen in EU-Rechtsordnungen, selbst für Unternehmen, die nicht direkt US-Recht unterliegen. Das stärkste Gegenargument für sofortiges Handeln sind vertragliche Schutzmechanismen und Standard-Anbieter-SLAs, die den Käufer angeblich vor Upstream-Lieferkettenrisiken schützen.

Kostenloser Download

EU AI Act Checkliste für Unternehmen

Compliance-Fristen, Risikoklassen, Pflichten nach Art. 4 und 50 auf einer Seite. PDF, kein Login.

Wir nutzen Ihre E-Mail-Adresse für den Versand der Checkliste und speichern sie als Kontakt bei Brevo. Datenschutzerklärung

Brauchen Sie das für Ihr Business?

Wir können das für Sie implementieren.

Kontakt aufnehmen