Funktioniert OpenSearch in China? PIPL-Grenztransfer, Data Residency & Self-Hosting
OpenSearch ist ein Data-at-Rest-Speicher: die Dokumente, die Sie indexieren, und die k-NN-Embeddings, die es daraus ableitet, sind personenbezogene Daten, wenn sie Personen in China beschreiben. Der globale Amazon OpenSearch Service hat keine Festlandchina-Region, China-Nutzerdaten offshore zu indexieren ist also ein PIPL-Grenztransfer — ein Compliance-zuerst-Blick auf die Residency-Exponierung und den inländischen Self-Host-Hebel.
Funktioniert OpenSearch in China?
OpenSearch ist ein Data-at-Rest-Speicher der indexierten Dokumente Ihrer Nutzer und der k-NN-Embeddings, die daraus gebaut werden — und der globale Amazon OpenSearch Service hat keine Festlandchina-Region, für Ihre China-Nutzer sitzen diese Inhalte also offshore als ein PIPL-Grenztransfer mit einer anhängenden Data-Residency-Frage.
Sie laden OpenSearch mit Dokumenten, Tickets, Logs und Datensätzen, und seine Vektor-Engine leitet Dense-Embeddings ab, die neben dem rohen Payload gespeichert werden — alle personenbezogene Daten, wenn sie Personen in China beschreiben. Sie in einem Cluster außerhalb Chinas zu halten ist ein grenzüberschreitender Transfer nach PIPL (Benachrichtigung, gesonderte Einwilligung und ein Transfermechanismus, Artikel 38–40), mit einer inländischen Speicherpflicht für CIIOs und Verarbeiter großer Mengen (Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)); und weil ein Embedding Inversion und Membership Inference unterstützt, anonymisiert es diese Pflicht nicht weg. Der rechtmäßige Hebel ist, den Index und die Embeddings im Inland zu halten — OpenSearch ist Apache 2.0 und vollständig selbst hostbar auf Infrastruktur auf dem Festland, und Amazon OpenSearch Service wird auch in der lizenzierten AWS-China-(Peking/Ningxia)-Partition angeboten — nicht einen Endpunkt außerhalb Chinas erreichbar zu machen.
Dies ist eine Risikokarte, kein Urteil — welcher Transfermechanismus passt und ob eine Lokalisierungspflicht gilt, dreht sich um Ihre Rechtsperson, Ihre Datenmengen und wessen Daten es sind. Unser China-Team kann Ihre Exponierung kartieren →
Compliance-Momentaufnahme
- ! OpenSearch ist ein Data-at-Rest-Speicher: indexierte Dokumente und Embeddings sind PII
- ! Embeddings sind nicht anonym; Inversion und Membership Inference halten sie als PII
- ✕ Globales Managed OpenSearch hat keine Festland-Region; der Index sitzt offshore
- ! Amazon OpenSearch Service läuft in AWS China (Peking/Ningxia) über lokalen Betreiber
- ✓ Apache-2.0-Engine hostet im Inland selbst; 21YunBox fügt ICP-eingereichte Auslieferung hinzu
Was die offizielle OpenSearch-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Amazon OpenSearch Service ist innerhalb der AWS-China-Partition verfügbar — eine echte inländische Managed-Option. AWS' China-Dokumentation erklärt „Amazon OpenSearch Service is available in the following regions in China:" und listet die China-(Peking)-Region und die China-(Ningxia)-Region — die AWS-China-Partition, betrieben von lizenzierten lokalen Partnern (Sinnet in Peking, NWCD in Ningxia). Sie braucht ein separates AWS-China-Konto und nur einige Instance-Typen sind verfügbar, behandeln Sie es also als Warn-Positiv, keinen sauberen globalen Freifahrtschein — und verschieden vom globalen Amazon OpenSearch Service, der keine Festlandchina-Region hat. | AWS China Documentation — Amazon OpenSearch Service in Amazon Web Services China (docs.amazonaws.cn), abgerufen 2026-10-10 |
| Die OpenSearch-Engine ist Apache 2.0 und vollständig selbst hostbar — die stärkste Form des inländischen Hebels — und ihre k-NN-Engine speichert Embeddings. OpenSearch ist die quelloffene Apache-2.0-Such- und Vektor-Engine, verwaltet von der OpenSearch Software Foundation unter der Linux Foundation, Sie können sie also auf einer Infrastruktur Ihrer Wahl betreiben, einschließlich des Festlands China. Ihre eingebaute k-NN-Vektor-Engine verwandelt Text und Bilder in Dense-Vector-Embeddings, die in knn_vector-Feldern für semantische Suche und RAG gespeichert werden — personenbezogene Daten im Ruhezustand, wenn aus den Daten Ihrer China-Nutzer abgeleitet. | OpenSearch — opensearch.org (Apache 2.0; OpenSearch Software Foundation / Linux Foundation) and k-NN developer guide, abgerufen 2026-10-10 |
| China-Nutzer-Inhalte offshore zu indexieren ist ein PIPL-Grenztransfer — und Embeddings nehmen ihn nicht aus. Die Dokumente, die Sie indexieren, und die daraus abgeleiteten Embeddings sind personenbezogene Daten, wenn sie Personen in China beschreiben, sie in einem Cluster außerhalb Chinas zu halten ist also ein grenzüberschreitender Transfer nach PIPL: Sie, der Verarbeiter, müssen informieren, eine gesonderte Einwilligung einholen und einen Transfermechanismus erfüllen (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung) nach Artikel 38–40. Weil ein Embedding Inversion und Membership Inference unterstützt, ist „wir senden nur Vektoren" keine Ausnahme. | PIPL Articles 38–40 (cross-border transfer of personal information), abgerufen 2026-10-10 |
| Für CIIOs und Verarbeiter großer Mengen müssen in China erhobene personenbezogene Daten auf dem Festland bleiben — kein Cluster außerhalb Chinas kann das erfüllen. Betreiber kritischer Informationsinfrastruktur und Verarbeiter oberhalb der Mengenschwellen der Regulierer müssen in China erhobene personenbezogene Daten im Inland speichern (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)). Die Novelle des Cybersicherheitsgesetzes von 2025, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungsartikel von 37 auf 39 um, mit unveränderter Substanz. Ein selbst gehosteter OpenSearch-Cluster auf Infrastruktur auf dem Festland oder die lizenzierte AWS-China-Partition kann diese Pflicht erfüllen, wo der globale Managed Service es nicht kann. | PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37), abgerufen 2026-10-10 |
Quellen vom 21YunBox Compliance-Team am 10. Oktober 2026 geprüft.
Für eine China-gerichtete Anwendung ist die entscheidende Frage zu OpenSearch nicht, ob ein Cluster-Endpunkt erreichbar ist — sie ist, wo die Inhalte, die Sie indexieren und vektorisieren, leben dürfen. OpenSearch ist ein Data-at-Rest-Speicher: Sie laden ihn mit den Dokumenten, Tickets, Logs und Datensätzen, die Sie durchsuchen wollen, und es hält sie in einem invertierten Index und — über seine eingebaute k-NN-Vektor-Engine — als Dense-Vector-Embeddings für semantische Suche und RAG. Für Ihre China-Nutzer sind diese Inhalte personenbezogene Daten, die ruhen, wo immer die Engine läuft. OpenSearch ist die quelloffene Apache-2.0-Engine, unter der OpenSearch Software Foundation (Linux Foundation) und vollständig selbst hostbar — was genau der Hebel ist. Drei Stränge entscheiden das Risiko: Residency und grenzüberschreitender Transfer der indexierten Inhalte; dass Embeddings personenbezogene Daten sind, die Sie nicht weganonymisieren können; und den Index im Inland zu halten, indem man die offene Engine selbst hostet, statt eine Cloud außerhalb Chinas zu erreichen.
OpenSearch in China auf einen Blick
| Was es entscheidet | In OpenSearchs eigenen Worten — und Chinas Recht |
|---|---|
| Was Sie hineinladen | OpenSearch hält die Dokumente, Logs, Tickets und Datensätze, die Sie indexieren, in einem invertierten Index und — über seine k-NN-Vektor-Engine — die Dense-Vector-Embeddings plus den Payload und Quelltext, der daneben gespeichert wird. Wenn diese Inhalte Personen in China beschreiben, sind sie personenbezogene Daten, die im Ruhezustand gehalten werden, kein flüchtiger Cache. |
| Wo die Engine läuft | Sie hosten entweder die Apache-2.0-Engine selbst auf einer Infrastruktur Ihrer Wahl oder nutzen einen Managed Service. Der globale Amazon OpenSearch Service läuft in AWS-Regionen außerhalb des Festlands, China-Nutzerdaten in irgendeinen Cluster außerhalb Chinas zu indexieren ist also ein grenzüberschreitender Transfer durch Sie (数据出境; PIPL Artikel 38–40). Amazon OpenSearch Service wird auch in der AWS-China-(Peking/Ningxia)-Partition über einen lizenzierten lokalen Betreiber angeboten — eine inländische Option, kein globaler Freifahrtschein. |
| Embeddings sind personenbezogene Daten | Ein k-NN-Embedding wird aus dem Text oder Bild einer Person berechnet; es unterstützt Inversion (approximative Rekonstruktion der Quelle) und Membership Inference, es ist also nicht anonymisiert. Ein Speicher von Embeddings der Daten Ihrer China-Nutzer ist selbst ein Speicher personenbezogener Daten — „wir senden nur Vektoren, keine Rohdaten" ist keine Grenz-Ausnahme. |
| Datenlokalisierung und Query-Logs | Ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen muss in China erhobene personenbezogene Daten auf dem Festland halten (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)). Suchstrings und Query-Logs tragen ebenfalls personenbezogene Daten und dieselbe Residency-Pflicht. |
| Den Endpunkt zu erreichen ist nicht die Achse | Ob der Cluster antwortet, ist nicht die Compliance-Frage. Der dauerhafte Zug ist, den Index und die Embeddings im Inland zu halten — die quelloffene Engine auf Infrastruktur auf dem Festland selbst hosten oder die lizenzierte inländische Managed-Option nutzen — und zu minimieren und pseudonymisieren, was Sie indexieren. Die öffentliche App, die den Index abfragt, trägt weiterhin eine ICP-Beian-Pflicht. |
Was Sie tatsächlich speichern — indexierte Inhalte und ihre Embeddings
OpenSearch ist, in AWS’ eigenen Worten, „a popular open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, and clickstream analytics.” Was es zu einem Compliance-Objekt macht, sind nicht die Abfragen, die es beantwortet, sondern das, was es behält, um sie zu beantworten. Wenn Sie ein Dokument indexieren, speichert OpenSearch das ursprüngliche _source und baut einen invertierten Index über seine Felder; wenn Sie semantische Suche oder RAG ausführen, verwandelt seine k-NN-Vektor-Engine (über die Neural-Search- und ml-commons-Komponenten) Text oder Bilder in Dense-Vector-Embeddings, die in knn_vector-Felder geschrieben werden, und der rohe Payload und die Metadaten — Nutzer-IDs, Quellausschnitte, Zeitstempel — werden routinemäßig neben jedem Vektor gespeichert, sodass ein Treffer auf einen Datensatz zurückgeführt werden kann.
Ein OpenSearch-Cluster, der aus den Support-Tickets, Chat-Logs, Profilen und Dokumenten Ihrer China-Nutzer gebaut ist, hält ihre personenbezogenen Daten also dreifach: als den ursprünglichen indexierten Text, als den daraus abgeleiteten invertierten Index und als die daraus abgeleiteten Embeddings. All das sind personenbezogene Daten im Ruhezustand, und sie leben, wo immer der Cluster läuft — eine US- oder EU-Region des globalen Managed Service, ein selbst gehosteter Cluster außerhalb Chinas oder inländische Infrastruktur. Der Index ist kein Cache vor Ihren Daten; er ist Ihre Daten, in transformierter Form.
Es ist ein Residency- und Grenztransfer-Problem — und Embeddings anonymisieren es nicht — nach PIPL
Weil die indexierten Inhalte und ihre Embeddings personenbezogene Daten sind, ist ihr Halten in einem Cluster, der außerhalb des Festlands läuft, ein grenzüberschreitender Transfer personenbezogener Daten (数据出境), den Chinas Gesetz zum Schutz personenbezogener Daten direkt regelt. Als Verarbeiter — Sie, nicht der Engine-Anbieter — müssen Sie informieren, eine gesonderte Einwilligung einholen und einen Transfermechanismus erfüllen (eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung) nach PIPL Artikel 38–40. Wenn Sie ein Betreiber kritischer Informationsinfrastruktur sind oder personenbezogene Daten oberhalb der Mengenschwellen der Regulierer verarbeiten, müssen diese in China erhobenen Daten auch auf dem Festland gespeichert werden (PIPL Artikel 40; Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37) — die Novelle des Cybersicherheitsgesetzes von 2025, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungsartikel von 37 auf 39 um, mit unveränderter Substanz) — eine Residency-Pflicht, die kein Cluster außerhalb Chinas erfüllen kann.
Der Strang, den die meisten Teams übersehen, sind Embeddings. Es ist verlockend, einen Vektor-Index als ausgenommen zu behandeln, weil er Arrays von Gleitkommazahlen statt Namen und Adressen speichert. Dieser Instinkt ist falsch auf die Weise, die hier zählt. Ein Embedding wird direkt aus der Nachricht, dem Ticket oder Dokument einer Person berechnet, und es bewahrt genug vom Original, um Inversion — approximative Rekonstruktion des Quelltexts — und Membership Inference zu unterstützen, zu entscheiden, ob der Datensatz einer bestimmten Person im Trainings- oder Indexsatz war. Ein Speicher von Embeddings der Daten Ihrer China-Nutzer ist daher selbst ein Speicher ihrer personenbezogenen Daten, der dieselben Residency- und Grenz-Pflichten trägt wie der Rohtext; „wir senden nur Vektoren, keine Rohdaten” ist ein falscher Trost. Suchstrings und Suchlogs fallen unter dieselbe Regel, weil auch sie offenbaren, wer wonach gesucht hat.
Den Endpunkt zu erreichen ist nicht die Frage — den Index im Inland zu halten ist es
Ob ein OpenSearch-Endpunkt vom Festland aus erreichbar ist, ist nicht die Achse. Die Achse ist, wo der Index und die Embeddings ruhen dürfen, und OpenSearch gibt Ihnen eine ungewöhnlich klare Antwort: weil die Engine Apache 2.0 und vollständig selbst hostbar ist, können Sie sie auf inländischer Infrastruktur betreiben und den Index und die Embeddings auf dem Festland halten — die ehrliche, starke Form des Hebels. Wo ein Managed Service bevorzugt wird, wird Amazon OpenSearch Service innerhalb der AWS-China-Partition angeboten — die China-(Peking)-Region, betrieben von Sinnet, und die China-(Ningxia)-Region, betrieben von NWCD — was eine echte inländische Residency-Option über einen lizenzierten lokalen Betreiber ist (sie braucht ein separates AWS-China-Konto, und nur einige Instance-Typen sind verfügbar). Behandeln Sie das als Warn-Positiv, keinen sauberen globalen Freifahrtschein, und halten Sie es vom globalen Amazon OpenSearch Service (US, EU und andere Regionen) getrennt, der keine Festlandchina-Region hat. Jeder inländische Pfad wird mit dem Minimieren und Pseudonymisieren dessen gepaart, was Sie indexieren, und dem Regeln jedes verbleibenden Transfers. Was es nicht ist, ist eine verborgene Route, die Abfragen vom Festland beantwortet, während sie die Daten trotzdem offshore verschifft — das hält die personenbezogenen Daten genau dort, wo das Recht sie nicht haben will.
Dies ist eine Risikokarte, kein Urteil: ob eine Lokalisierungspflicht gilt und welcher Grenzmechanismus passt, dreht sich um Ihre Rechtsperson, wie viele personenbezogene Daten Sie halten und wessen sie sind — klären Sie die Einzelheiten mit Rechtsbeistand, bevor Sie bauen.
Der rechtmäßige Pfad — kartieren, lokalisieren, ausliefern
OpenSearch bleibt Ihre Such- und Vektor-Engine; nichts zieht davon weg. Was 21YunBox hinzufügt, ist das Compliance-Overlay um den Stack, den Sie bereits betreiben — kein Neuaufbau, keine zweite Codebasis.
- kartieren — inventarisieren, welche Inhalte Sie indexieren und vektorisieren, welche personenbezogenen Daten sie tragen, ob Embeddings personenbezogener Daten gespeichert werden, wo die Engine läuft (eine globale Managed-Region, ein selbst gehosteter Cluster außerhalb Chinas oder im Inland), die Query-Log-Exponierung und Ihre Einwilligungsgrundlage.
- lokalisieren — die indexierten Inhalte und Embeddings der China-Nutzer im Inland halten: die Apache-2.0-Engine auf Infrastruktur auf dem Festland selbst hosten oder die lizenzierte inländische Managed-Option nutzen, und minimieren und pseudonymisieren, was indexiert wird, mit Regelung jedes verbleibenden grenzüberschreitenden Transfers.
- ausliefern — die App oder Website, die den Index abfragt, trägt eine ICP-Beian-Pflicht und braucht rechtskonforme, inländische Auslieferung (den 21YunBox Optimizer) vor dem Stack, den Sie bereits betreiben.
21YunBox ist ein rechtskonformes Overlay und Partner, kein Konkurrent zu OpenSearch. 21YunBox nutzt oder empfiehlt niemals eine Umgehung jeglicher Art. Das Ergebnis, auf das wir abschließen, ist schlicht: OpenSearch läuft für Ihre Nutzer in China legal und rechtskonform.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- Chinas Maßnahmen zur Datenausfuhr-Sicherheitsbewertung
- Wie man eine ICP-Beian für China erhält
Häufige Fragen
Sind unsere OpenSearch-Daten ein Problem nach chinesischem Recht, wenn es „nur ein Index von Vektoren" ist?
Behandeln Sie es als personenbezogene Daten, denn das ist es. OpenSearch speichert die ursprünglichen indexierten Dokumente, den darüber gebauten invertierten Index und — über seine k-NN-Engine — Embeddings plus Payload und Metadaten, alle abgeleitet aus dem Text, den Tickets und Profilen Ihrer Nutzer. Ein Embedding unterstützt Inversion (approximative Rekonstruktion der Quelle) und Membership Inference, es ist also nicht anonymisiert. Ein aus der Aktivität Ihrer China-Nutzer gebauter Index hält daher ihre personenbezogenen Daten in transformierter Form, und ihn in einem Cluster außerhalb Chinas zu halten ist ein grenzüberschreitender Transfer nach PIPL — Benachrichtigung, gesonderte Einwilligung und ein Transfermechanismus fallen auf Sie als Verarbeiter.
Macht uns Amazon OpenSearch Service in den AWS-China-Regionen rechtskonform?
Es hilft, aber es ist ein Warn-Positiv, kein automatisches Ja. Amazon OpenSearch Service wird in den AWS-China-(Peking)- und (Ningxia)-Regionen angeboten, betrieben von lizenzierten lokalen Partnern (Sinnet und NWCD) — eine echte inländische Residency-Option, die ein separates AWS-China-Konto braucht und nur einige Instance-Typen bietet. Den Index im Inland zu halten adressiert die Residency-Frage, aber Sie schulden weiterhin Benachrichtigung und gesonderte Einwilligung, Datenminimierung und — wenn irgendwelche Daten weiterhin das Festland verlassen — einen Transfermechanismus. Der globale Amazon OpenSearch Service hat dagegen keine Festlandchina-Region.
Kann 21YunBox helfen, unsere OpenSearch-gestützte App in China funktionieren zu lassen?
Ja. Unser China-Team kartiert, wo Ihre indexierten Inhalte und Embeddings sitzen, arbeitet Ihre PIPL-Grenz- und Data-Residency-Position für Ihre Rechtsperson, Datenmengen und Nutzer aus und stellt den rechtmäßigen inländischen Pfad auf — die Apache-2.0-Engine auf Infrastruktur auf dem Festland selbst hosten oder die lizenzierte inländische Managed-Option nutzen — plus die ICP-eingereichte, inländische Auslieferung, die die öffentliche App braucht, vor dem Stack, den Sie bereits betreiben, ohne Neuaufbau. Nehmen Sie Kontakt auf, um Ihren spezifischen Fall durchzugehen.
