Funktioniert Elasticsearch in China? PIPL-Grenztransfer, Datenresidenz & Self-Hosting
Elasticsearch ist zugleich eine Volltext-Suchmaschine und eine Vektor-Datenbank: Die Dokumente, die Sie indexieren, und die daraus abgeleiteten Dense-Vector-Embeddings sind personenbezogene Information, die ruhend gehalten wird, und Elastic Cloud hat keine Festlandchina-Region — die Daten Ihrer China-Nutzer dort zu indexieren ist also ein PIPL-Grenztransfer. Ein Compliance-zuerst-Blick auf die Residenz-Exponierung und den inländischen Self-Host-Hebel.
Funktioniert Elasticsearch in China?
Elasticsearch ist ein Daten-im-Ruhezustand-Speicher des Inhalts Ihrer Nutzer — die Dokumente, die Sie indexieren, und die daraus abgeleiteten Dense-Vector-Embeddings — und Elastic Cloud hat keine Festlandchina-Region, ein auf China ausgerichteter Index sitzt also offshore: ein Residenz- und Grenztransfer-Problem, keine Geschwindigkeits-Frage.
Sie laden Elasticsearch mit Dokumenten, Datensätzen, Logs und den Embeddings, die es daraus für kNN-Suche und RAG berechnet — alle aus den Nachrichten, Profilen und Dateien Ihrer Nutzer gebaut, also alle personenbezogene Information, wenn diese Nutzer in China sind. Das in einer Offshore-Elastic-Cloud-Region zu indexieren (AWS, GCP oder Azure — die nächste ist Hongkong, nicht das Festland) ist ein PIPL-Grenztransfer (Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus, Artikel 38–40), mit einer Inland-Speicherpflicht für Betreiber kritischer Informationsinfrastruktur und Verarbeiter großer Mengen (Artikel 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). Embeddings anonymisieren das nicht weg — sie unterstützen Inversion und Membership Inference, ein Vektor-Speicher ist also weiterhin ein Personeninformations-Speicher. Weil Elasticsearch quelloffen ist (AGPL seit 2024) und voll selbst hostbar, ist der rechtmäßige Hebel, den Index und die Embeddings im Inland zu halten — die offene Engine auf Festland-Infrastruktur selbst hosten oder ein lizenziertes inländisches verwaltetes Deployment nutzen — nicht, einen Offshore-Endpunkt erreichbar zu machen.
Dies ist eine Risikokarte, kein Urteil — welcher Transfermechanismus passt und ob eine Lokalisierungs-Pflicht Sie bindet, hängt von Ihrem Rechtsträger, Ihren Datenmengen und davon ab, wessen Daten es sind. Unser China-Team kann Ihre Exponierung kartieren →
Compliance-Momentaufnahme
- ! Elastic Cloud läuft auf AWS, GCP und Azure — nächste Region ist Hongkong, nicht das Festland
- ! Was Sie indexieren — Dokumente und Dense-Vector-Embeddings — ist personenbezogene Daten im Ruhezustand
- ! Embeddings sind nicht anonym — Inversion und Membership Inference stellen die Person wieder her
- ✕ Elastic Cloud hat keine Festlandchina-Region, kann also keine Datenlokalisierung erfüllen
- ! Alibaba Cloud Elasticsearch läuft im Inland über einen lizenzierten Betreiber — ein Warn, kein Pass
- ✓ Die quelloffene (AGPL) Engine im Inland selbst hosten; ICP reitet auf der App davor
Was die offizielle Elasticsearch-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Elasticsearch ist wieder quelloffen und voll selbst hostbar — der Hebel, um Daten im Inland zu halten. Im August 2024 fügte Elastic die OSI-anerkannte AGPL-(AGPLv3-)Lizenzoption neben der Elastic License v2 und SSPL hinzu und schrieb, dass „Elasticsearch and Kibana can be called Open Source again.“ Weil Sie dieselbe Engine auf Ihrer eigenen Hardware betreiben können, können Sie den Cluster — Index und Dense-Vector-Embeddings — auf Festland-Infrastruktur hosten statt auf einer Offshore-verwalteten Region. | Elastic blog — „Elasticsearch Is Open Source. Again!“ (Shay Banon, Aug 29 2024), abgerufen 2026-10-10 |
| Elastic Cloud hat keine Festlandchina-Region — und es speichert Dense-Vector-Embeddings, nicht bloß Text. Elastics eigene Elastic-Cloud-Hosted-Regions-Seite listet AWS-, GCP- und Azure-Standorte; seine nächste Asien-Pazifik-Region ist Hongkong (aws-ap-east-1), und keine liegt innerhalb Festlandchinas. Elasticsearch indexiert sowohl Dokumente (in einem invertierten Index) als auch Embeddings über seinen dense_vector-Feldtyp für kNN-Suche — ein auf China ausgerichtetes Deployment auf Elastic Cloud hält diesen Inhalt also offshore. | Elastic Docs — Elastic Cloud Hosted regions; Elastic Docs — kNN / dense_vector, abgerufen 2026-10-10 |
| Die Daten von China-Nutzern in einem Offshore-Cluster zu indexieren ist ein PIPL-Grenztransfer, mit einer Inland-Speicherpflicht für manche Verarbeiter. Personenbezogene Information in einer Offshore-Region zu halten löst PIPLs Grenzregeln aus — Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus (eine CAC-Sicherheitsbewertung, der CAC-Standardvertrag oder eine Zertifizierung), Artikel 38–40. Ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen muss in China erhobene personenbezogene Information im Festland speichern (PIPL Artikel 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37) — die Cybersicherheitsgesetz-Änderung von 2025, in Kraft am 1. Januar 2026, nummerierte den Datenlokalisierungs-Artikel von 37 auf 39 um, seine Substanz unverändert). | PIPL Articles 38–40 (DigiChina/Stanford translation); Cybersecurity Law Article 39 (formerly Article 37), abgerufen 2026-10-10 |
| Embeddings sind aus personenbezogenen Daten abgeleitet und sind keine Anonymisierung. PIPL definiert personenbezogene Information als Information, die sich auf identifizierte oder identifizierbare natürliche Personen bezieht, und behandelt nur wirklich anonymisierte Daten als außerhalb des Geltungsbereichs (Artikel 4). Ein Vektor-Embedding wird aus dem Text oder Bild einer Person berechnet und unterstützt Inversion (ungefähre Rekonstruktion der Quelle) und Membership Inference, ein Speicher von Embeddings der Daten Ihrer Nutzer ist also weiterhin ein Speicher personenbezogener Information — „we only send vectors“ nimmt es nicht aus PIPLs Residenz- und Grenztransfer-Pflichten heraus. | PIPL Article 4 (DigiChina/Stanford translation), abgerufen 2026-10-10 |
Quellen vom 21YunBox Compliance-Team am 10. Oktober 2026 geprüft.
Für eine auf China ausgerichtete Anwendung ist die Frage zu Elasticsearch nicht, ob ein Cluster eine Abfrage beantwortet — das wird es — sondern wo der Inhalt, den Sie ihm zuführen, leben darf. Elasticsearch ist ein Daten-im-Ruhezustand-Speicher in zwei Bedeutungen zugleich: eine Volltext-Suchmaschine, die die Dokumente, Datensätze und Logs, die Sie indexieren, in einem invertierten Index hält, und eine Vektor-Datenbank, die Dense-Vector-Embeddings in ihrem dense_vector-Feldtyp hält, die k-Nearest-Neighbor-(kNN-)Suche für semantische Suche und RAG antreibt. Beide werden aus den Nachrichten, Profilen und Dateien Ihrer Nutzer gebaut — personenbezogene Information in transformierter Form. Die Engine ist wieder quelloffen und voll selbst hostbar, aber Elastic Cloud, das verwaltete Angebot, läuft auf AWS, GCP und Azure ohne Festlandchina-Region. Die entscheidenden Fragen sind also Residenz und Grenztransfer, dass Embeddings die Menschen dahinter nicht anonymisieren, und der Hebel, die offene Engine im Inland selbst zu hosten.
Elasticsearch in China auf einen Blick
| Was es entscheidet | In Elasticsearchs eigenen Worten — und Chinas Recht |
|---|---|
| Was Sie hineinladen | Dokumente, Datensätze, Logs und Chat, die Sie in einen invertierten Index indexieren, plus die Dense-Vector-Embeddings, die Elasticsearch daraus für kNN-Suche und RAG berechnet. Wenn Ihre Nutzer in China sind, ist das ihre personenbezogene Information, die ruhend gehalten wird. |
| Wo die Engine läuft | Elastic Cloud (verwaltet) läuft auf AWS, GCP und Azure — seine nächste Asien-Pazifik-Region ist Hongkong (aws-ap-east-1), was nicht Festlandchina ist. China-Nutzer-Daten dort zu indexieren ist ein Grenztransfer (数据出境) unter PIPL Artikel 38–40; die offene Engine selbst zu hosten hält ihn im Inland. |
| Embeddings sind personenbezogene Information | Ein Vektor wird aus dem Text oder Bild einer Person berechnet; er unterstützt Inversion (ungefähre Rekonstruktion) und Membership Inference, er ist also nicht anonymisiert. Ein Speicher von Embeddings der Daten Ihrer Nutzer ist selbst ein Speicher personenbezogener Information — „nur Vektoren, keine Rohdaten“ ist ein falscher Trost. |
| Datenlokalisierung und Abfrage-Logs | Ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen muss in China erhobene personenbezogene Daten im Festland halten (PIPL Artikel 40; Cybersicherheitsgesetz Art. 39, vormals Art. 37). Abfrage-Logs können ebenfalls personenbezogene Information tragen. Eine Offshore-Elastic-Cloud-Region erfüllt nichts davon. |
| Erreichbarkeit ist nicht die Achse | Ob ein Cluster eine Abfrage beantwortet, war nie die Frage. Der Hebel ist, den Index und die Embeddings im Inland zu halten — die quelloffene (AGPL) Engine selbst hosten oder ein lizenziertes inländisches verwaltetes Deployment — zu minimieren und zu pseudonymisieren, was Sie indexieren, und die ICP-Beian auf der App davor zu tragen. |
Was Sie tatsächlich speichern — indexierter Inhalt und seine Embeddings
Elasticsearch verdient seinen Platz, indem es Ihre Daten hält, nicht indem es sie weiterreicht. Als Suchmaschine behält es jedes Dokument, das Sie indexieren — Support-Tickets, Produktdatensätze, Nutzerprofile, Logs, Chat-Transkripte — in einem invertierten Index, gebaut für schnelle Volltext-Abfrage. Als Vektor-Datenbank behält es Dense-Vector-Embeddings in seinem dense_vector-Feldtyp, die k-Nearest-Neighbor-(kNN-)Suche für semantische Suche und Retrieval-Augmented Generation antreiben; die meisten Designs speichern auch den Originaltext oder die Payload neben jedem Vektor, sodass eine Übereinstimmung gezeigt und nachverfolgt werden kann. Jede dieser Strukturen ist aus dem eigenen Inhalt Ihrer Nutzer abgeleitet. Wenn diese Nutzer in China sind, ist der Index kein beiläufiger Abgas — es ist ein Speicher ihrer personenbezogenen Information im Ruhezustand, und er lebt, wo auch immer der Cluster läuft. Deshalb ist die entscheidende Frage eine Standort-Frage, keine Latenz-Frage: Wo darf Elasticsearch all das behalten?
Es ist ein Residenz- und Grenztransfer-Problem — und Embeddings anonymisieren es nicht — unter PIPL
Betreiben Sie diesen Cluster auf Elastic Cloud, und die Geografie beantwortet die Frage für Sie. Elastics verwalteter Dienst läuft auf AWS, GCP und Azure, und seine eigene Elastic-Cloud-Hosted-Regions-Seite listet keinen Standort innerhalb Festlandchinas — der nächste ist Hongkong (aws-ap-east-1), was für Datenlokalisierungs-Zwecke nicht das Festland ist. Die Dokumente und Embeddings Ihrer chinesischen Nutzer in eine Offshore-Region zu indexieren ist daher ein Grenztransfer personenbezogener Information (数据出境) unter Chinas Gesetz zum Schutz personenbezogener Daten: Sie — der Verarbeiter, nicht Elastic — müssen Mitteilung geben, eine gesonderte Einwilligung einholen und einen Transfermechanismus erfüllen (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung) nach Artikel 38–40. Wenn Sie ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen sind, muss in China erhobene personenbezogene Information im Festland gespeichert werden (PIPL Artikel 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37) — die Cybersicherheitsgesetz-Änderung von 2025, in Kraft am 1. Januar 2026, nummerierte den Datenlokalisierungs-Artikel von 37 auf 39 um, seine Substanz unverändert) — eine Pflicht, die keine Offshore-Region erfüllen kann.
Und die Embeddings holen Sie nicht aus diesem heraus. Es ist verlockend, zu denken, ein Vektor-Index sei befreit, weil er Arrays von Gleitkommazahlen speichert statt Namen und E-Mails — „wir senden nur Vektoren, keine Rohdaten.“ Dieser Trost ist falsch. Ein Embedding wird direkt aus dem Text, Dokument oder Bild einer Person berechnet, und es bewahrt genug vom Original, um Inversion — ungefähre Rekonstruktion des Quelltexts — und Membership Inference zu unterstützen, die offenbart, ob der Datensatz einer bestimmten Person im Speicher ist. PIPL definiert personenbezogene Information als Information, die sich auf identifizierte oder identifizierbare natürliche Personen bezieht, und stellt nur wirklich anonymisierte Daten außerhalb seines Geltungsbereichs (Artikel 4); ein Embedding der Daten Ihrer Nutzer ist weder anonymisiert noch außerhalb des Geltungsbereichs. Ein Speicher von Embeddings der personenbezogenen Daten chinesischer Nutzer trägt dieselben Residenz- und Grenzübertritts-Pflichten wie der Rohtext, aus dem er stammt.
Den Endpunkt zu erreichen ist nicht die Frage — den Index im Inland zu halten schon
Nichts davon betrifft, ob ein Cluster in Oregon oder Singapur eine Abfrage aus Shanghai beantwortet. Das wird er. Die Exponierung ist, dass der Index und seine Embeddings — personenbezogene Information — ruhend außerhalb des Festlands sitzen. Der saubere Hebel folgt direkt aus dem, was Elasticsearch ist: quelloffen. Seit Elastic 2024 die AGPL-Option hinzufügte, können Sie dieselbe Engine auf Ihrer eigenen Infrastruktur innerhalb Chinas betreiben, den Index und die Embeddings im Inland halten und minimieren und pseudonymisieren, was Sie indexieren, sodass von vornherein weniger personenbezogene Information gehalten wird. Wo ein voll verwalteter Dienst erforderlich ist, ist ein lizenziertes inländisches verwaltetes Elasticsearch — zum Beispiel Alibaba Cloud Elasticsearch, angeboten über Alibaba Clouds Festland-Regionen — ein Warn-Positiv: Es hält die Daten im Inland, aber es ist ein eigener Betreiber und Vertrag, und Ihre Einwilligungs-Grundlage, Transfer-Position und Abfrage-Log-Handhabung müssen weiterhin geklärt werden. Was der Hebel nicht ist, ist ein Weg, die Daten offshore zu halten und einen fernen Endpunkt lokal fühlen zu lassen; Lokalisierung bedeutet, den Daten-im-Ruhezustand-Speicher auf einem inländischen Weg zu halten, nicht ihn aus dem Festland hinaus und zurück zu leiten.
Dies ist eine Risikokarte, kein Urteil: Ob eine Lokalisierungs-Pflicht Sie bindet, welcher Grenz-Mechanismus passt und wie viel Ihres Index als personenbezogene Information gilt, hängt von Ihrem Rechtsträger, Ihren Datenmengen und davon ab, wessen Daten es sind — klären Sie die Einzelheiten mit Rechtsbeistand, bevor Sie bauen.
Der rechtmäßige Weg — kartieren, lokalisieren, ausliefern
21YunBox ist ein rechtskonformer Overlay um den Stack, den Sie bereits betreiben, kein Ersatz für Elasticsearch und kein Konkurrent von Elastic. Die Arbeit hat drei Teile. Kartieren: inventarisieren, was Sie indexieren und vektorisieren, welche personenbezogene Information diese Dokumente und Embeddings tragen, wo der Cluster heute läuft, was Ihre Abfrage-Logs erfassen und auf welcher Einwilligungs-Grundlage Sie beruhen. Lokalisieren: Ihren China-Nutzer-Index und die Embeddings im Inland halten — die quelloffene (AGPL) Engine auf Festland-Infrastruktur selbst hosten oder ein lizenziertes inländisches verwaltetes Deployment nutzen — minimieren und pseudonymisieren, was indexiert wird, und jeden verbleibenden Grenztransfer steuern; der Punkt ist, den Daten-im-Ruhezustand-Speicher auf einem inländischen Weg zu halten. Ausliefern: Die Anwendung, die den Index abfragt, trägt eine ICP-Beian-Pflicht und braucht rechtskonforme, inländische Auslieferung — der 21YunBox Optimizer, vor den Stack gesetzt, den Sie bereits betreiben, ohne Neuaufbau und ohne zweite Codebasis. 21YunBox nutzt oder empfiehlt niemals irgendeine Form von Umgehung. Das Ergebnis ist ein Elasticsearch-Deployment, das legal und rechtskonform für Ihre Nutzer in China läuft.
Compliance-Einschätzung anfordern →
Weiterführende Lektüre:
- Grenzüberschreitende Datentransfers unter PIPL
- Chinas Cybersicherheitsgesetz erklärt
- Chinas Maßnahmen zur Datenexport-Sicherheitsbewertung
- Wie man eine ICP-Beian für China erhält
Häufige Fragen
Sind Embeddings wirklich personenbezogene Information, wenn sie nur Vektoren sind?
Behandeln Sie sie als personenbezogene Information, denn das sind sie. Ein Embedding wird direkt aus der Nachricht, dem Dokument oder dem Bild eines Nutzers berechnet, und es wurde gezeigt, dass Embeddings Inversion — ungefähre Rekonstruktion des Quelltexts — und Membership Inference unterstützen. Elasticsearch speichert zudem in den meisten Designs das Rohdokument oder die Payload neben dem Vektor. Ein aus der Aktivität Ihrer chinesischen Nutzer gebauter Index hält also ihre personenbezogene Information in transformierter, nicht anonymisierter Form; nach PIPL Artikel 4 sind nur wirklich anonymisierte Daten außerhalb des Geltungsbereichs. In einer Offshore-Elastic-Cloud-Region gehalten, ist es ein Grenztransfer, und die Pflichten fallen auf Sie als Verarbeiter.
Ist Self-Hosting von Elasticsearch nicht die saubere Antwort für China?
Es ist der stärkste Hebel, und er ist real: Seit Elastic 2024 die AGPL-Option hinzufügte, ist Elasticsearch quelloffen, und Sie können dieselbe Engine auf Ihrer eigenen Infrastruktur innerhalb des Festlands betreiben und den Index und seine Embeddings im Inland halten. Das beantwortet die Datenresidenz. Es beantwortet von sich aus nicht alles — die öffentliche App, die den Cluster abfragt, braucht weiterhin eine ICP-Beian, wenn sie ein Festland-Publikum bedient, Ihre PIPL-Einwilligungs- und Mitteilungs-Pflichten sind nun Ihre, und Abfrage-Logs können selbst personenbezogene Information tragen. Ein lizenziertes inländisches verwaltetes Elasticsearch (zum Beispiel Alibaba Cloud Elasticsearch in Alibaba Clouds Festland-Regionen) ist eine Warn-Positiv-Alternative — im Inland, aber ein eigener Betreiber und Vertrag.
Kann 21YunBox helfen, unsere Elasticsearch-gestützte App in China zum Funktionieren zu bringen?
Ja. Unser China-Team kann inventarisieren, was Sie indexieren und vektorisieren und welche personenbezogene Information es trägt, Ihre PIPL-Grenzübertritts- und Datenresidenz-Position für Ihren Rechtsträger und Ihre Datenmengen kartieren und einen selbst gehosteten, inländischen Elasticsearch-Weg aufstellen — plus die ICP-gemeldete, inländische Auslieferung, die die Anwendung davor braucht — um den Stack gewickelt, den Sie bereits betreiben, ohne Neuaufbau und ohne Wechsel weg von Elasticsearch. Nehmen Sie Kontakt auf, um Ihren konkreten Fall durchzugehen.
