Ja, chinesische KI-Modelle wie DeepSeek, Qwen, Yi oder GLM können in Unternehmen sinnvoll sein, aber rechtlich und organisatorisch nur unter klaren Bedingungen: Self-Hosting ist fast immer sicherer als API-Nutzung, Lizenzdetails müssen vor dem Rollout geprüft werden, und der EU AI Act gilt auch dann, wenn das Modell aus China stammt. Wer sensible Daten per API an einen Anbieter in China sendet, hat dagegen regelmäßig gleichzeitig ein Datenschutz-, Governance- und Lieferantenrisiko.
Der Artikel beantwortet deshalb nicht die Frage, ob chinesische KI pauschal “verboten” oder “unsicher” ist. Er beantwortet die wichtigere Praxisfrage: Unter welchen Bedingungen können Sie DeepSeek, Qwen, Yi und GLM rechtssicher, technisch kontrolliert und wirtschaftlich vernünftig einsetzen? Für den breiteren Open-Source-Kontext ist unsere Pillar Page Open-Source-KI im Unternehmen der beste Einstieg. Für die DeepSeek-Einzelfrage lohnt sich ergänzend der Beitrag DeepSeek sicher im Unternehmen einsetzen.
Welche chinesischen KI-Modelle gibt es?
Der chinesische Modellmarkt besteht nicht nur aus DeepSeek. Für Unternehmen sind derzeit vor allem fünf Linien relevant: DeepSeek R1 und V3, Qwen 2.5, Yi 1.5 sowie GLM-4. Diese Modelle unterscheiden sich bei Architektur, Lizenz, Hosting-Optionen und Governance deutlich stärker, als der Sammelbegriff “KI aus China” vermuten lässt.
| Modellfamilie | Typische offene Größen | Praxisprofil | Einordnung für Unternehmen | | --- | --- | --- | --- | | DeepSeek-V3 | 671B Gesamtparameter, davon 37B aktiv pro Token | Sehr stark bei allgemeiner Textgenerierung und Coding | Technisch attraktiv, aber nur sinnvoll mit sauberem Hosting- und Lizenzcheck | | DeepSeek-R1 | Destillate von klein bis groß plus großes Reasoning-Modell | Stark bei Schlussfolgerungen, Analyse und strukturierten Aufgaben | Für interne Wissensarbeit interessant, aber Governance bleibt Pflicht | | Qwen 2.5 | Von kleinen 0,5B/3B-Varianten bis 72B und multimodalen Ablegern | Breites Ökosystem, gute Tool-Unterstützung, viele Deployments | Für Self-Hosting oft die pragmatischste chinesische Modellfamilie | | Yi 1.5 | Vor allem 6B und 34B offene Varianten | Gute Allround-Leistung, kleineres Ökosystem als Qwen | Für Spezialfälle brauchbar, aber Lizenzstand je Release genau prüfen | | GLM-4 | Offene 9B-Varianten plus stärkere API-Modelle | Mehrsprachig, multimodal, teils stark bei Agent-Workflows | Lizenz- und Anbieterstruktur ist heterogener als bei Qwen |
Benchmarks zeigen: Chinesische Modelle sind kein Nischenprodukt mehr. DeepSeek-V3 wurde vom Hersteller mit Leistung in der Nähe führender Closed-Source-Modelle positioniert, Qwen 2.5 ist in vielen Open-Weight-Setups Standard geworden, und GLM-4 oder Yi tauchen regelmäßig in Leaderboards und Hosting-Katalogen auf. Für Unternehmen ist aber wichtiger als jeder Benchmark, ob das Modell lokal betrieben werden kann, ob Gewichte und Nutzungsrechte klar dokumentiert sind und ob Ihr Einsatz überhaupt in einen risikoarmen Use Case fällt.
Die kurze Priorisierung für die Praxis lautet deshalb: Wenn Sie chinesische KI testen wollen, schauen Sie zuerst auf Qwen und DeepSeek für Self-Hosting, auf GLM nur mit sauberer Dokumentation und auf Yi nur nach genauer Lizenzprüfung des konkreten Releases. Wer noch keinen belastbaren Bewertungsrahmen hat, sollte parallel den Beitrag Open-Source-KI und der EU AI Act lesen.
Lizenzen: MIT, Apache und proprietäre Einschränkungen
Die Lizenz entscheidet, ob ein Modell für Ihr Unternehmen überhaupt beschaffbar ist. Technische Qualität hilft wenig, wenn Nutzungsrechte, Weitergabe, Haftung oder Informationspflichten unklar bleiben. Genau deshalb sollten Sie bei chinesischen Modellen nie nur auf Hugging-Face-Tags oder GitHub-Sterne schauen, sondern auf die Primärdokumente des konkreten Releases.
Pragmatisch lassen sich drei Muster unterscheiden. Erstens gibt es permissive Modelle wie aktuelle DeepSeek-Repositories mit MIT-Komponenten oder MIT-freigegebenen Releases. Zweitens gibt es Apache-2.0-Modelle wie große Teile der Qwen-2.5-Familie. Drittens gibt es Modelle oder APIs mit eigenen Model Terms, Community Licenses oder Plattformbedingungen. Gerade bei Yi und Teilen des GLM-Ökosystems ist diese Gemengelage relevanter als eine simple Schublade “open” oder “closed”.
Für Unternehmen ist der Unterschied handfest:
| Lizenztyp | Typische Rechte | Typische Risiken | | --- | --- | --- | | MIT | Sehr weitgehende Nutzung, Modifikation und Weitergabe mit kurzer Lizenzpflicht | Wenig vertragliche Leitplanken, deshalb müssen Sie Haftung, Support und Herkunft selbst stärker prüfen | | Apache 2.0 | Weitgehend permissiv, plus ausdrückliche Patentlizenz und Notice-Pflichten | Operativ oft am angenehmsten, solange Notices sauber weitergegeben werden | | Eigene Modellbedingungen / proprietäre Terms | Nutzung nur im Rahmen individueller Vorgaben des Anbieters | Unklare Weitergabe, unklare Haftung, oft Einschränkungen bei Redistribution oder Hosting |
Qwen ist deshalb aus Compliance-Sicht oft leichter einzuordnen als der restliche Markt. Apache 2.0 ist für interne Freigaben, Lieferantenbewertung und Dokumentation meist sauberer als individuelle Model Terms. DeepSeek ist ebenfalls attraktiv, aber nur, wenn Sie nicht vorschnell von “alles MIT” ausgehen. Bei DeepSeek existieren je nach Repository Unterschiede zwischen Code-Lizenz und Modellbedingungen. Bei Yi ist die Lage noch uneinheitlicher: offene Repositories können permissive Elemente enthalten, API- oder Modellbedingungen einzelner Angebote sind aber teils enger. GLM wiederum bewegt sich zwischen offenen Repositories, Plattformangeboten und eigenen Nutzungsregeln.
Die operative Regel sollte deshalb lauten: Freigabe nie auf Familiennamen, sondern immer auf Release-Ebene. Dokumentieren Sie Repository, Commit oder Modellversion, Lizenztext, Herkunft der Gewichte und den geplanten Nutzungsmodus. Dann vermeiden Sie den klassischen Fehler, ein lokal ladbares Modell rechtlich wie freie Standardsoftware zu behandeln.
Das CCP-Risiko: Was steckt dahinter?
Das politische Risiko ist real, aber pauschale Panik hilft nicht weiter. Wenn Unternehmen von “CCP-Risiko” sprechen, meinen sie meist drei verschiedene Dinge gleichzeitig: gesetzlichen Zugriff chinesischer Behörden, mögliche Zensur oder Policy-Effekte im Modell und die Sorge vor versteckten Sicherheitsfunktionen oder Backdoors. Diese Ebenen müssen getrennt geprüft werden.
Erstens gibt es ein echtes Rechts- und Zugriffsrisiko bei cloudbasierten Diensten aus China. Wenn Sie einen chinesischen API-Anbieter nutzen, sollten Sie davon ausgehen, dass Datenzugriffe durch dortige Rechtsordnung und staatliche Eingriffsbefugnisse nicht mit EU-Erwartungen an Vertraulichkeit deckungsgleich sind. Genau deshalb ist die Aussage “Wir schicken ja nur Prompts” zu kurz. Prompts enthalten in der Praxis oft personenbezogene Daten, interne Strategien, Vertragsinhalte oder Quellcode.
Zweitens gibt es ein Governance-Risiko im Modellverhalten. Modelle, die unter chinesischer Regulierung trainiert oder betrieben werden, können in politischen Themen anders reagieren, filtern oder ausweichen als westliche Modelle. Für Compliance, HR, Vertragsprüfung oder rechtliche Textarbeit ist das nicht nur ein PR-Thema, sondern ein Qualitäts- und Steuerungsrisiko. Ein Modell, das bestimmte Themen systematisch ausblendet, ist in kritischen Workflows schlicht weniger verlässlich.
Drittens gibt es das oft überdramatisierte Backdoor-Narrativ. Dafür gibt es im Einzelfall selten öffentlich belastbare Beweise. Trotzdem wäre es fahrlässig, das Thema abzutun. Das BSI argumentiert in seinem Kriterienkatalog für externe generative Modelle nüchtern: Extern bereitgestellte Modelle brauchen ein belastbares Sicherheitsniveau, klare Schutzmaßnahmen und eine strenge Prüfung der Integration. Das ist die richtige Haltung. Realismus heißt nicht Entwarnung, sondern technische Kontrolle statt politischer Schlagworte.
Die sachliche Schlussfolgerung lautet also: Das größte CCP-Risiko liegt nicht in einer mystischen Eigenschaft “chinesischer KI”, sondern im unkontrollierten Fremdbetrieb über externe APIs. Wenn Sie dasselbe offene Modell lokal in Ihrer eigenen Infrastruktur betreiben, reduzieren Sie das Zugriffs- und Transferproblem drastisch. Das politische Herkunftsrisiko verschwindet damit nicht vollständig, wird aber von einem unmittelbaren Datenabfluss- zu einem prüfbaren Lieferkettenrisiko.
API vs. Self-Hosting: Der entscheidende Unterschied
Für Unternehmen ist die Architekturfrage wichtiger als die Herkunftsdebatte. API-Nutzung und Self-Hosting sind rechtlich und technisch zwei völlig verschiedene Szenarien. Bei einer API senden Sie Eingaben, Metadaten und oft auch Nutzungsprotokolle an einen externen Dienst. Beim Self-Hosting betreiben Sie die Modellgewichte lokal oder in einer kontrollierten EU-Umgebung, ohne dass Prompts an den ursprünglichen Modellanbieter fließen.
Das verändert die Risikolage fundamental:
| Betriebsmodell | Datentransfer | Kontrollniveau | Typische Eignung | | --- | --- | --- | --- | | API bei chinesischem Anbieter | Hoch, weil Prompts und Metadaten an den Anbieter fließen | Niedrig bis mittel | Nur für klar nicht-sensitive Tests, wenn überhaupt | | API bei westlichem Zwischenanbieter mit chinesischem Modell | Weiterhin relevant, weil Lieferkette und Subprozessoren geprüft werden müssen | Mittel | Nur nach genauer Vertrags- und Transferprüfung | | Self-Hosting on-premises oder in kontrollierter EU-Cloud | Kein Transfer an den Modellhersteller durch die Inferenz selbst | Hoch | Für Unternehmensnutzung klar bevorzugt |
Self-Hosting ist deshalb nicht bloß eine IT-Option, sondern die zentrale Compliance-Maßnahme. Wenn Sie DeepSeek oder Qwen lokal mit vLLM, SGLang oder einem anderen Inferenz-Stack betreiben, kontrollieren Sie Logging, Zugriff, Löschkonzept, Netzgrenzen und Monitoring selbst. Genau dann wird aus “KI aus China DSGVO” kein Exportproblem mehr, sondern primär eine Frage von Beschaffung, IT-Sicherheit und Dokumentation.
Natürlich löst Self-Hosting nicht alles. Sie müssen weiter prüfen, ob das Modell für Ihren Use Case geeignet ist, ob Outputs validiert werden, ob Trainingsdatenherkunft oder Lizenzlage vertretbar sind und ob sensible Prozesse zusätzliche AI-Act-Pflichten auslösen. Aber der zentrale Unterschied bleibt: Beim Self-Hosting senden Sie keine Unternehmensdaten an einen chinesischen Dienstbetreiber. Für viele Unternehmen ist das der Punkt, an dem der Einsatz überhaupt erst vertretbar wird.
Wenn Sie Kosten, Betriebsaufwand und Governance dieser Entscheidung systematisch vergleichen wollen, hilft unser Beitrag KI-Self-Hosting vs. Cloud-API: Kosten und Kontrolle.
AI Act Pflichten bei chinesischen Modellen
Der EU AI Act macht keinen Herkunftsbonus für China und keinen Herkunftsmalus für die USA. Maßgeblich ist, ob ein KI-System oder GPAI-Modell in den EU-Markt gelangt oder sein Output in der Union genutzt wird. Genau das steht in Art. 2 Abs. 1: Die Verordnung erfasst auch Anbieter und Betreiber in Drittländern, wenn der Output in der EU verwendet wird.
Für Ihr Unternehmen heißt das: Wenn Sie DeepSeek, Qwen, Yi oder GLM beruflich einsetzen, sind Sie regelmäßig mindestens Betreiber eines KI-Systems. Dann gilt seit dem 2. Februar 2025 die Pflicht zur KI-Kompetenz nach Art. 4. Ihre Mitarbeiter müssen also die Chancen, Grenzen und Risiken des konkret eingesetzten Systems in einem angemessenen Niveau verstehen. Die Nationalität des Modellanbieters ändert daran nichts.
Darüber hinaus können je nach Einsatz weitere Pflichten relevant werden:
- Wenn Sie ein chinesisches Modell nur intern für Textentwürfe oder Recherche nutzen, bleibt es oft bei Art. 4, Datenschutz, IT-Sicherheit und internen Freigaben.
- Wenn Sie es in HR, Kredit, Versicherung, Bildung oder anderen sensiblen Bereichen einsetzen, kann eine Hochrisiko-Prüfung nach Art. 6 und Anhang III nötig werden.
- Wenn ein Anbieter eines GPAI-Modells in einem Drittland sitzt und das Modell auf dem Unionsmarkt bereitstellt, kann für nicht frei und offen lizenzierte Modelle eine Pflicht zum EU-Bevollmächtigten nach Art. 54 entstehen.
Gerade der letzte Punkt wird oft übersehen. Ein chinesischer GPAI-Anbieter kann also nicht einfach deshalb außerhalb des Regimes stehen, weil er außerhalb der EU sitzt. Für frei und offen lizenzierte Modelle gibt es zwar eine wichtige Ausnahme, sofern Gewichte, Architekturinformationen und Nutzungsinformationen öffentlich verfügbar sind und kein systemisches Risiko vorliegt. Diese Ausnahme sollten Unternehmen aber nicht blind unterstellen, sondern anhand des konkreten Modells dokumentieren.
Die praktische Konsequenz lautet: Unternehmen dürfen chinesische Modelle nicht wie “regulierungsfreie Downloads” behandeln. Sie brauchen dieselbe Inventarisierung, Rollenklärung und Schulung wie bei westlichen Modellen. Wenn Sie dafür erst einen belastbaren Mindeststandard im Team schaffen wollen, ist unsere EU-AI-Act-Schulung der sinnvollste Startpunkt.
DSGVO-Analyse: China hat keinen Angemessenheitsbeschluss
Datenschutzrechtlich ist die Lage klarer als viele Produktbroschüren. China hat keinen Angemessenheitsbeschluss der EU-Kommission nach Art. 45 DSGVO. Damit sind Übermittlungen personenbezogener Daten an einen Empfänger in China nicht per se unzulässig, aber sie brauchen einen anderen tragfähigen Mechanismus nach Art. 46 oder ausnahmsweise eine der engen Ausnahmen aus Art. 49.
In der Theorie klingen Standardvertragsklauseln daher wie eine Lösung. In der Praxis reicht das allein nicht. Nach Schrems II und den EDPB-Empfehlungen 01/2020 müssen Unternehmen zusätzlich prüfen, ob das Recht des Empfängerlandes ein im Wesentlichen gleichwertiges Schutzniveau zulässt. Genau hier wird es bei Transfers an chinesische KI-APIs kritisch. Wenn Sie nicht überzeugend darlegen können, dass Zugriffe auf personenbezogene Daten technisch ausgeschlossen oder faktisch unwirksam gemacht sind, bleibt die Transfergrundlage fragil.
Für Unternehmenspraxis bedeutet das:
- Personenbezogene Daten über chinesische APIs senden ist regelmäßig nur sehr schwer tragfähig zu begründen.
- Pseudonymisierung hilft nur begrenzt, wenn der Empfänger den Personenbezug wiederherstellen kann oder Kontextdaten mitliefert.
- Verschlüsselung hilft nur dann voll, wenn der Anbieter die Daten nicht im Klartext für die Inferenz verarbeiten muss. Bei normalen Chat-APIs ist das gerade nicht der Fall.
- Art. 49 DSGVO ist kein Dauerfundament für den produktiven Regelbetrieb.
Deshalb ist die oft gehörte Aussage “Mit SCCs ist China schon machbar” zu pauschal. Theoretisch ja, praktisch nur in eng begrenzten Konstellationen. Für die breite Unternehmensnutzung mit realen Mitarbeiter-, Kunden- oder Vertragsdaten ist Self-Hosting die deutlich robustere Lösung. Dann entfällt der Drittlandtransfer an den Modellanbieter durch die Inferenz selbst, und Ihre Datenschutzprüfung verschiebt sich von internationalem Transferrecht hin zu interner Zugriffskontrolle, Löschung, TOMs und Rollenberechtigung.
Wer die Schnittstelle zwischen Datenschutz und AI Act systematisch verstehen will, sollte zusätzlich unseren Beitrag KI-Verordnung vs. DSGVO lesen.
Empfehlung: Chinesische KI pragmatisch und sicher einsetzen
Die richtige Empfehlung ist weder pauschales Verbot noch unkritischer Rollout. Chinesische KI kann wirtschaftlich attraktiv sein, besonders bei Open-Weight-Modellen mit guter Reasoning- oder Coding-Leistung. Sicher wird der Einsatz aber nur, wenn Sie Herkunft, Lizenz, Betriebsmodell und Risikokontext sauber trennen.
Eine einfache Entscheidungsmatrix hilft:
| Frage | Wenn Ja | Wenn Nein | | --- | --- | --- | | Können Sie das Modell selbst hosten? | Einsatz ist grundsätzlich realistisch | API-Nutzung nur in klar nicht-sensitiven Testfällen erwägen | | Verarbeiten Sie personenbezogene oder vertrauliche Daten? | Nur mit Self-Hosting und klaren internen Regeln arbeiten | Begrenzte Pilotierung ist eher vertretbar | | Ist die Lizenz des konkreten Releases dokumentiert? | Beschaffung kann weiter geprüft werden | Nicht freigeben | | Nutzt ein sensibler Bereich wie HR oder Compliance das Modell? | High-Risk- und Qualitätsprüfung vertiefen | Basiseinsatz mit Art.-4-Schulung kann genügen |
Für die meisten Unternehmen führt diese Matrix zu einer nüchternen Standardempfehlung: Qwen oder DeepSeek nur lokal oder in streng kontrollierter EU-Umgebung betreiben, keine sensiblen Daten an chinesische APIs senden, Lizenztexte pro Modellversion dokumentieren und den Einsatz zunächst auf nicht-sensitive Use Cases wie interne Recherche, Entwurfsarbeit, technische Hilfstexte oder Wissensstrukturierung beschränken. Genau das ist pragmatisch, weil es Innovationsspielraum erhält, ohne Datenschutz und Governance zu ignorieren.
Wenn Sie chinesische Modelle im Unternehmen einsetzen oder evaluieren wollen, sollten Sie zuerst Ihr Team auf denselben Wissensstand bringen: Was ist nach AI Act erlaubt, welche Rolle haben Sie als Betreiber, wo kippt ein Use Case in Hochrisiko, und wie dokumentieren Sie Schulung, Freigaben und Verantwortlichkeiten? Unsere EU-AI-Act-Schulung vermittelt genau diesen Rahmen in 90 Minuten und endet mit Test und Zertifikat für Ihren internen Nachweis.