Funktioniert LaunchDarkly in China? PIPL-Grenztransfer, automatisierte Entscheidungen & Data Residency
LaunchDarkly ist aus Festlandchina erreichbar, aber seine Flag- und Experiment-Entscheidungen laufen offshore: der Nutzer-Kontext, den Sie senden, um ein Flag zu targeten, und die zurückgesendeten Auswertungs- und Analytics-Events sind personenbezogene Information, verarbeitet auf US- oder EU-Servern ohne Festlandchina-Region. Ein Compliance-zuerst-Blick auf den PIPL-Grenztransfer und die Artikel-24-Exponierung automatisierter Entscheidungen.
Funktioniert LaunchDarkly in China?
LaunchDarkly lädt problemlos aus China — aber der Nutzer-Kontext, den Sie ihm senden, um ein Flag oder Experiment zu targeten, wird auf seinen US- oder EU-Servern ausgewertet, um zu entscheiden, was jede Person sieht, und dort sitzt die Compliance-Exponierung.
Um ein Flag auszuwerten, übergeben Sie LaunchDarkly einen Kontext — einen Nutzer-Key, oft eine E-Mail, einen Plan, ein Gerät, IP und Custom-Merkmale — und Impressions und Analytics-Events strömen zurück; es gibt keine Festlandchina-Region. Bei China-Nutzern ist das sowohl ein PIPL-Grenztransfer personenbezogener Information als auch eine automatisierte Entscheidung nach Artikel 24 darüber, was jeder Nutzer sieht. Der rechtmäßige Hebel ist, die Flag-Auswertung und die Nutzerdaten im Inland zu halten — eine selbst betriebene In-Cluster-Auswertungs-Komponente oder eine lizenzierte inländische Alternative, der am wenigsten identifizierende Kontext und der Artikel-24-Opt-out — nicht, das Offshore-SDK erreichbar zu machen.
Welche Pflicht zuerst greift, hängt davon ab, welchen Kontext Sie senden und wer Ihre Nutzer sind — eine Karte, die vor dem Bauen zu klären ist. Unser China-Team kann Ihre Exponierung kartieren →
Compliance-Momentaufnahme
- ! Der Kontext, den Sie senden, um ein Flag zu targeten — Nutzer-Key, E-Mail, Gerät, IP — ist personenbezogene Information
- ! Flag-/Experiment-Entscheidungen und Events werden auf US- oder EU-Servern ausgewertet, außerhalb des Festlands
- ✕ LaunchDarkly hat keine Festlandchina-Region; der Targeting-Kontext wird offshore ausgewertet
- ! Ein Flag, das entscheidet, was jeder Nutzer sieht, ist automatisierte Entscheidungsfindung nach PIPL Art 24
- ✓ Wir halten die Flag-Auswertung im Inland mit dem Art-24-Opt-out, hinter ICP-eingereichter Auslieferung
Was die offizielle LaunchDarkly-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Das SDK wertet Flags lokal aus, dennoch erhält LaunchDarkly die Auswertungsdaten — und Sie können eine In-Cluster-Auswertungs-Komponente selbst betreiben. LaunchDarklys Architekturdokumentation gibt an, ein serverseitiges SDK „stores and evaluates this initial feature flag data in an in-memory cache“, aber „the SDK sends information about flag evaluations back to LaunchDarkly“ (client-seitige und mobile SDKs rufen seinen Auswertungs-Endpunkt direkt auf). Dieselben Docs beschreiben optionale Komponenten, die Sie selbst installieren und betreiben, wo „you control the data that flows in or out of them“ — die Grundlage, um die Auswertung im Inland zu halten. | LaunchDarkly — Architecture (launchdarkly.com/docs), abgerufen 2026-10-10 |
| LaunchDarkly verarbeitet Daten in den USA oder der EU — keine Festlandchina-Region. Seine EU-Instanz residiert in „the AWS Frankfurt (eu-central-1) region“ neben der Standard-US-Instanz und einer separaten US-Federal-Instanz, und seine List of Subprocessors, wirksam ab 18. Dezember 2025, nennt Verarbeitungs-Orte in den USA, Deutschland, Frankreich, Irland und Singapur. Keiner liegt in Festlandchina, der Kontext und die Events Ihrer China-Nutzer werden also offshore ausgewertet und gespeichert. | LaunchDarkly — List of Subprocessors, effective December 18, 2025, abgerufen 2026-10-10 |
| Targeting-Kontext offshore zu senden ist ein PIPL-Grenztransfer, und die Flag-Entscheidung ist automatisierte Entscheidungsfindung. Als der Handler schulden Sie Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus nach PIPL Artikel 38–40, und ein Flag oder Experiment, das aus den Attributen wählt, was jeder Nutzer sieht, ist automatisierte Entscheidungsfindung nach PIPL Artikel 24 — der eine Möglichkeit zur Ablehnung und, für Profiling, eine Option verlangt, nicht nach persönlichen Merkmalen getargetet zu werden. | Personal Information Protection Law (PIPL), Articles 24 and 38–40 |
| Ein CIIO oder Handler mit hohem Volumen trägt zudem eine inländische Speicherpflicht. Wo sie gilt, muss personenbezogene Information im Festland gespeichert werden, nach PIPL Artikel 40 und Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) — die Cybersicherheitsgesetz-Novelle von 2025, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungs-Artikel von 37 auf 39 um, Substanz unverändert. Keine US- oder EU-Region kann sie erfüllen. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37); PIPL Article 40 |
Quellen vom 21YunBox Compliance-Team am 10. Oktober 2026 geprüft.
Für ein Festlandchina-Publikum ist die Frage zu LaunchDarkly nicht, ob sein SDK oder sein Streaming-Dienst erreicht werden kann — es ist, was mit dem Nutzer-Kontext geschieht, den Sie ihm senden. Um ein Flag zu targeten oder ein Experiment zu fahren, übergeben Sie LaunchDarkly einen Kontext: einen Nutzer-Key und oft eine E-Mail, einen Plan oder Tier, ein Gerät, Geografie, IP und welche Custom-Attribute auch immer Sie wählen. Serverseitige SDKs werten Flag-Regeln lokal in einem In-Memory-Store aus, aber „the SDK sends information about flag evaluations back to LaunchDarkly“, und client-seitige und mobile Apps rufen seinen Auswertungs-Endpunkt direkt auf — der Targeting-Kontext und die Impression- und Analytics-Events, die er zurückgibt, fließen also zu LaunchDarklys Servern, die in den Vereinigten Staaten oder, wahlweise, der Europäischen Union laufen, ohne Festlandchina-Region. Das wirft drei Fragen zugleich auf: einen PIPL-Grenztransfer personenbezogener Information, eine automatisierte Entscheidung nach Artikel 24 darüber, was jeder Nutzer sieht, und Einwilligung für das Verhaltens-Tracking dahinter.
LaunchDarkly in China auf einen Blick
| Was darüber entscheidet | In LaunchDarklys eigenen Worten — und Chinas Recht |
|---|---|
| Was Sie senden | Um ein Flag oder Experiment auszuwerten, übergeben Sie LaunchDarkly einen Kontext — einen Nutzer-Key und oft eine E-Mail, einen Plan, ein Gerät, Geografie, IP und Custom-Attribute. Diese Identifikatoren und Merkmale sind personenbezogene Information, und die Impression- und Analytics-Events strömen ebenfalls zurück. |
| Wo es ausgewertet und gespeichert wird | LaunchDarkly läuft in den Vereinigten Staaten, mit einer optionalen EU-Instanz in „the AWS Frankfurt (eu-central-1) region“ und einer separaten US-Federal-Instanz — keine Festlandchina-Region. Den Kontext Ihrer China-Nutzer dorthin zu senden ist ein PIPL-Grenztransfer (Artikel 38–40, 数据出境). |
| Es entscheidet, was jeder Nutzer sieht | Ein Flag oder Experiment wählt aus den Attributen, welche Variation jeder Kontext erhält — automatisierte Entscheidungsfindung nach PIPL Artikel 24, der Transparenz und Fairness, eine Möglichkeit zur Ablehnung und, für profiling-basierte Entscheidungen, eine Option verlangt, nicht nach persönlichen Merkmalen getargetet zu werden. |
| Einwilligung und Residency | Nicht-essenzielle Experimentierung und Verhaltens-Tracking brauchen die Einwilligung des Nutzers (PIPL Artikel 13 und 23), nicht einen vergrabenen Hinweis. Ein Betreiber kritischer Informationsinfrastruktur oder Handler mit hohem Volumen trägt zudem eine inländische Speicherpflicht (Cybersicherheitsgesetz Artikel 39, vormals Artikel 37). |
| Erreichbarkeit ist nicht die Achse | Das SDK oder den Streaming-Dienst zu erreichen ist nicht die Frage. Der rechtmäßige Pfad hält Flag-Auswertung und Nutzerdaten im Inland — eine selbst betriebene In-Cluster-Komponente oder eine lizenzierte inländische Alternative, der am wenigsten identifizierende Kontext und der Artikel-24-Opt-out — während die App, die die Entscheidungen konsumiert, eine ICP-Beian für inländische Auslieferung trägt. |
Was Sie tatsächlich senden — die Attribute und das Verhalten Ihrer Nutzer
LaunchDarkly ist eine Feature-Management- und Experimentier-Plattform: Sie wickeln Features in Flags, rollen sie aus, targeten sie und testen Varianten gegeneinander. Dazu wertet Ihre Anwendung ein Flag gegen einen Kontext aus — in LaunchDarklys Modell der Nutzer oder die Entität, die Sie bedienen, die „any attributes you specify“ trägt. In der Praxis bedeutet das einen Nutzer-Key und gewöhnlich eine E-Mail, einen Plan oder Tier, ein Gerät und eine App-Version, Geografie, IP und Custom-Merkmale, die Sie fürs Targeting anhängen. Das ist personenbezogene Information in dem Moment, in dem der Nutzer eine reale Person in China ist.
Wie dieser Kontext LaunchDarkly erreicht, hängt vom SDK ab. Ein serverseitiges SDK, in LaunchDarklys Worten, „stores and evaluates this initial feature flag data in an in-memory cache“, roher Kontext kann also innerhalb Ihres Prozesses bleiben — aber „the SDK sends information about flag evaluations back to LaunchDarkly“, so werden Impressions, Experiment-Expositionen und Analytics aufgezeichnet. Client-seitige und mobile SDKs gehen weiter und senden den Kontext an LaunchDarklys Auswertungs-Endpunkt, um die Variationen jedes Nutzers abzuholen. So oder so verlassen Identifikatoren und Verhalten, die an Ihre China-Nutzer gebunden sind, das Land zu LaunchDarklys US- oder EU-Servern — es gibt keine Festlandchina-Region, um sie dort zu halten, und ein Experiment oder ein personalisierter Rollout fügt der Aufzeichnung, wer was sah, stetig hinzu.
Es ist ein grenzüberschreitender Transfer — und eine automatisierte Entscheidung — nach PIPL
Den Kontext und die Events Ihrer China-Nutzer an LaunchDarklys Offshore-Server zu senden ist, in PIPLs Begriffen, ein grenzüberschreitender Transfer personenbezogener Information (数据出境). Als der Handler — Sie, nicht LaunchDarkly — schulden Sie die Pflichten aus Artikel 38–40, bevor der erste Kontext das Land verlässt: Mitteilung geben, eine gesonderte Einwilligung für den Transfer einholen und einen Transfermechanismus freigeben (eine CAC-Sicherheitsbewertung, der CAC-Standardvertrag oder eine Zertifizierung). Die Mechanik ist in unserer Notiz zu grenzüberschreitenden Datentransfers nach PIPL dargelegt.
Die besondere Facette ist Artikel 24. Ein Feature-Flag oder ein Experiment ist fast per Definition automatisierte Entscheidungsfindung: es entscheidet aus den Attributen oder der Kohorte, welche Variation, welches Feature, welche Erfahrung jeder Nutzer erhält. PIPL Artikel 24 regelt genau das — er verlangt, dass die Entscheidung transparent und fair ist, gibt der Person eine Möglichkeit zur Ablehnung und verlangt, wo die Entscheidung oder der Push auf Profiling beruht, eine Option, nicht nach ihren persönlichen Merkmalen getargetet zu werden. Ein Experiment auf einem China-Segment zu fahren oder aus einem Profil zu personalisieren, ist Profiling, das Sie für die Person, die fragt, abschalten können müssen.
Einwilligung ist eine dritte Pflicht: nicht-essenzielle Experimentierung und die Verhaltens-Events dahinter brauchen die informierte Einwilligung des Nutzers nach PIPL Artikel 13 und 23 — eine vergrabene „by using this product…“-Zeile trägt sie nicht. Und wo Sie ein Betreiber kritischer Informationsinfrastruktur oder ein Handler mit hohem Volumen sind, greift eine Datenlokalisierungspflicht: die personenbezogene Information muss im Festland gespeichert werden (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) — die Cybersicherheitsgesetz-Novelle von 2025, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungs-Artikel von 37 auf 39 um, Substanz unverändert), eine Residency, die keine US- oder EU-Region erfüllen kann.
Das SDK zu erreichen ist nicht die Frage — die Entscheidungsfindung im Inland zu halten ist es
Nichts davon ist ein Latenz-Problem, nichts davon wird also gelöst, indem man den Offshore-Endpunkt schneller oder erreichbarer macht. Die Exponierung ist, dass die Entscheidung und die Daten dahinter offshore sitzen; die rechtmäßige Antwort ist, beide auf einen inländischen Pfad zu bringen.
LaunchDarkly gibt Ihnen hier einen echten Hebel. Es bietet eine optionale In-Cluster-Flag-Delivery- und Auswertungs-Komponente, die Sie innerhalb Ihrer eigenen Infrastruktur betreiben: in seinen eigenen Worten „you install and configure the components, and you control the data that flows in or out of them“. Innerhalb Chinas gehostet, lässt diese Komponente Ihre SDKs gegen einen lokalen Cache auswerten, roher Kontext muss die Grenze also nicht für jede Auswertung durchqueren. Seien Sie aber präzise darüber, was es ist — es ist ein Cache und Relay, kein vollständiger On-Premises-Ersatz: die Flag-Konfiguration stammt weiterhin aus LaunchDarklys managed Service, und Experiment- und Analytics-Events sind weiterhin darauf ausgelegt, zurückzufließen. Die In-Cluster-Komponente ist also ein Werkzeug, gepaart mit dem Minimieren und Pseudonymisieren des Kontexts, den Sie doch senden (mit dem am wenigsten identifizierenden Key auswerten, idealerweise ohne rohe E-Mail oder IP), dem Wahren des Artikel-24-Rechts auf eine nicht-profilierte Option und — wo Residency oder Volumen es verlangen — dem Routen von China-Nutzern durch eine lizenzierte inländische Experimentier-Alternative stattdessen. Die Entscheidungsfindung auf einem inländischen Pfad zu halten ist das Ziel; dieselben Daten offshore unter einem anderen Namen zu verschicken ist es nicht.
Dies ist eine Risikokarte, kein Urteil. Ob die Grenztransfer-Regeln, die Artikel-24-Pflichten, eine Einwilligungslücke oder eine Datenlokalisierungspflicht zuerst greifen, hängt davon ab, welchen Kontext Sie senden, worauf Sie experimentieren und wer Ihre Nutzer sind — wert, die Besonderheiten mit Rechtsbeistand zu klären, bevor Sie bauen.
Der rechtmäßige Pfad — kartieren, lokalisieren, ausliefern
Sie betreiben LaunchDarkly weiter. 21YunBox fügt das Stück hinzu, das sein Offshore-Dienst nicht kann, als rechtskonforme Overlay vor dem Stack, den Sie bereits betreiben — kein Neuaufbau, keine Migration.
- Kartieren — wir inventarisieren den Kontext und die Events, die Ihre Flags und Experimente senden: welche Attribute sie tragen, wo jeder ausgewertet und gespeichert wird, wie sie entscheiden, was Nutzer sehen, ob ein persistentes Profil offshore anwächst und die Einwilligungs-Grundlage, auf die Sie sich stützen.
- Lokalisieren — wir halten Flag-Auswertung und Daten von China-Nutzern auf einem inländischen Pfad: die selbst betriebene In-Cluster-Komponente innerhalb Chinas gehostet, wo sie passt, oder eine lizenzierte inländische Experimentier-Alternative, wo Residency oder Volumen es verlangen; der am wenigsten identifizierende Kontext offshore gesendet; und der Artikel-24-Opt-out gewahrt. 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art.
- Ausliefern — die App oder Seite, die Ihre Flags fährt und die Entscheidungen konsumiert, trägt eine ICP-Beian-Pflicht und braucht rechtskonforme, inländische Auslieferung — den 21YunBox Optimizer, vor Ihren bestehenden Origin gesetzt, damit ein Festland-Publikum rechtmäßig bedient wird, ohne von Ihrem globalen Stack wegzuziehen.
Das Ergebnis ist LaunchDarkly, das legal und rechtskonform für Ihre Nutzer in China läuft, mit der Entscheidungsfindung und der personenbezogenen Information dahinter auf einem inländischen Fundament.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- Chinas Datenausfuhr-Sicherheitsbewertung
- So erhalten Sie eine ICP-Beian für China
Häufige Fragen
Verlassen unsere LaunchDarkly-Daten Festlandchina?
Wenn Sie Flags auswerten oder Experimente auf Ihren China-Nutzern fahren, ja. Um ein Flag zu targeten, senden Sie LaunchDarkly einen Kontext — einen Nutzer-Key und oft eine E-Mail, einen Plan, ein Gerät, IP und Custom-Merkmale — und selbst wo ein serverseitiges SDK lokal auswertet, sendet es Flag-Auswertungs-Informationen an LaunchDarkly zurück, während client-seitige und mobile SDKs seinen Auswertungs-Endpunkt direkt aufrufen. Diese Daten werden auf LaunchDarklys US- oder EU-Servern verarbeitet, ohne Festlandchina-Region. Personenbezogene Information von China-Nutzern zu sammeln und offshore zu senden ist ein grenzüberschreitender Transfer nach PIPL, der Mitteilung, eine gesonderte Einwilligung und einen rechtmäßigen Transfermechanismus erwartet.
Ist ein Feature-Flag wirklich „automatisierte Entscheidungsfindung“ nach PIPL?
Im Allgemeinen ja. Ein Flag oder Experiment entscheidet aus den Attributen oder der Kohorte, welche Variation, welches Feature oder welche Erfahrung jeder Nutzer erhält — was PIPL Artikel 24 regelt. Er verlangt, dass die Entscheidung transparent und fair ist, gibt der Person eine Möglichkeit zur Ablehnung und verlangt, wo die Entscheidung auf Profiling beruht, eine Option, nicht nach ihren persönlichen Merkmalen getargetet zu werden. Ein Experiment auf einem China-Segment zu fahren oder aus einem Profil zu personalisieren, ist Profiling, das Sie für einen Nutzer, der fragt, abschalten können müssen — eine Pflicht, die Teams übersehen, wenn sie Flags als rein technisch behandeln.
Können wir LaunchDarkly behalten und dennoch rechtskonform in China laufen?
Oft ja — indem Sie die Entscheidungsfindung und die Nutzerdaten auf einem inländischen Pfad halten, statt den Offshore-Endpunkt erreichbar zu machen. LaunchDarkly bietet eine optionale In-Cluster-Auswertungs-Komponente, die Sie selbst betreiben, die, innerhalb Chinas gehostet, Ihre SDKs gegen einen lokalen Cache auswerten lässt; es ist ein Cache und Relay, kein vollständiger On-Premises-Ersatz, paaren Sie es also mit dem Minimieren und Pseudonymisieren des Kontexts, den Sie senden, dem Wahren des Artikel-24-Opt-outs und — wo Residency oder Volumen es verlangen — einer lizenzierten inländischen Alternative. Die App, die die Entscheidungen konsumiert, braucht weiterhin eine ICP-Beian und rechtskonforme inländische Auslieferung. 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art. Dies ist eine Risikokarte, klären Sie die Besonderheiten also mit Rechtsbeistand.
