Didomi는 중국에서 작동하나요? EU 호스팅 동의·PIPL 국경 간·동의 체제 간극
Didomi는 동의·선호 관리 플랫폼입니다 — 그러나 자사 하위 처리자 목록은 그 동의·선호·DSAR 데이터를 EU(독일 프랑크푸르트)에, 중국 본토 리전 없이 호스팅합니다. 중국에 그것은 그것이 귀사 사용자에 대해 보관하는 동의 기록을 PIPL상 국경 간 이전으로 바꾸고, ICP 비안 기반도 국내 저장도 없습니다 — 그리고 GDPR용으로 지어진 동의 흐름은 스스로 PIPL의 별도 동의 체제를 충족하지 않습니다. 데이터 레지던시·동의 노출과 합법적 국내 경로를 컴플라이언스 우선으로 봅니다.
Didomi는 중국에서 작동하나요?
아이러니가 답입니다: Didomi는 동의·선호 플랫폼으로, 본토 중국에 있는 그대로 돌면, 그 자체의 컴플라이언스 노출이 될 수 있습니다. 배너에 닿는 것이 문제가 아니라 — 그것이 귀사 중국 사용자의 동의 기록을 어디 보관하는지, 그리고 그 동의가 어느 법을 위해 지어졌는지가 문제입니다.
Didomi 자사 하위 처리자 목록(2026년 7월 갱신)은 그 호스팅을 EU에 둡니다: AWS "Data centers located in the European Union (Frankfurt, Germany),"이고, 클라이언트 분석에 Snowflake 서버가 "located in the AWS eu-central-1 region (Frankfurt, Germany)" — 중국 본토 리전 없이. 그러니 그것이 중국 방문자로부터 포착하는 모든 동의 기록·선호·데이터 주체 요청이 해외에 보유된 개인정보입니다 — PIPL이 규율하는 국경 간 이전(고지, 별도 동의, 이전 메커니즘, 제38~40조), 핵심정보인프라 운영자나 대량 취급자에는 국내 저장 의무와 함께(PIPL 제40조; 사이버보안법 제39조(구 제37조)). 그 위에, Didomi의 동의는 GDPR 체제 — 중국 PIPL이 거울하지 않는 — 를 위해 지어졌으므로, GDPR·TCF식 옵트인은 스스로 PIPL의 별도의 구체적 동의를 충족하지 않습니다. 배너는 또한 해외에서 가져와지므로, 중국 안에서 느리게 로드되거나 실패할 수 있습니다 — 그리고 로드되지 못하는 동의 게이트는 그것이 지키는 페이지를 붙잡을 수 있습니다.
이는 판정이 아니라 리스크 지도입니다 — 귀사가 지는 것은 귀사 데이터 볼륨, 취급자로서의 역할, 사용자가 누구인지로 갈리고, 자문과 정할 가치가 있습니다. 저희 중국 팀이 귀사 노출을 함께 매핑해 드립니다 →
컴플라이언스 스냅샷
- ! 동의·선호·DSAR 기록이 EU(프랑크푸르트)에, 본토 밖에 저장됨
- ! 그 기록은 국경을 넘는 중국 사용자의 PI — PIPL 적용
- ✕ Didomi는 중국 본토 호스팅 리전을 지명하지 않음(EU만 — 프랑크푸르트/벨기에)
- ! GDPR·TCF식 옵트인은 스스로 PIPL의 별도의 구체적 동의를 충족하지 않음
- ! 해외(EU)에서 제공되는 동의 배너는 중국 안에서 멈추거나 로드 실패할 수 있음
- ! 핵심정보인프라 운영자/대량 취급자는 Didomi가 제공 못 하는 국내 저장을 짐
Didomi 공식 문서가 중국에 대해 말하는 것
| 사실 | 1차 출처 |
|---|---|
| Didomi는 그 동의·선호·DSAR 데이터를 EU에 호스팅합니다 — 중국이 아니라. 자사 하위 처리자 목록(2026년 7월 갱신)은 그 AWS 호스팅이 CMP·PMP·DSAR 서비스의 원시 데이터에 "Data centers located in the European Union (Frankfurt, Germany)"에 앉는다 기재합니다. 동의 플랫폼에 그것은 거꾸로의 요점입니다: 중국 사용자가 동의했음을 증명하는 기록 자체가 해외에 보유된 개인정보 — PIPL상 개인정보의 국경 간 이전(고지, 별도 동의, 이전 메커니즘, 제38~40조)입니다. | Didomi — Our sub-processors as a data processor, retrieved 2026-10-09; PIPL Articles 38–40 |
| 클라이언트 데이터·분석도 프랑크푸르트에 앉습니다 — 여전히 중국 본토 리전 없이. 같은 하위 처리자 목록은 "The Snowflake servers used by Didomi are located in the AWS eu-central-1 region (Frankfurt, Germany),"라 기재하고, 나머지 하위 처리자를 EU(벨기에)에 둡니다. 목록 어디에도 국내 리전이 없으니, 동의·선호 데이터가 살 본토 호스팅 리소스도, ICP 비안을 붙일 것도 없습니다. | Didomi — Our sub-processors as a data processor, retrieved 2026-10-09 |
| Didomi의 동의는 중국 PIPL이 거울하지 않는 GDPR 체제를 위해 지어졌습니다. Didomi는 그 CMP를 "GDPR, CCPA, and all major global regulations"를 다룬다 기술합니다 — 중국 PIPL을 지명하지 않는 목록. GDPR·TCF식 옵트인은 스스로 PIPL을 충족하지 않는데, PIPL은 여러 목적에 별도의 구체적 동의를, 그리고 해외 이전 자체에 구별된 동의를 요구합니다(PIPL 제38~40조). 유럽에서 유효한 배너가 중국 사용자에 중국이 요구하는 것에 여전히 못 미칠 수 있습니다. | Didomi (didomi.io) product description, retrieved 2026-10-09; PIPL Articles 38–40 |
| 일부 취급자에게 데이터는 중국에 머물러야 하고 — 본토 안에서 제공하는 것은 ICP 비안을 유발합니다. 취급자가 핵심정보인프라 운영자이거나 개인정보를 볼륨으로 옮기는 곳에서, 중국에서 수집된 개인정보는 본토에 저장되어야 하고(PIPL 제40조; 사이버보안법 제39조(구 제37조)) — EU 동의 저장소가 충족할 수 없는 의무 — 특정 기준을 넘으면 그 이전이 중국 데이터 수출 안전성 평가를 요구할 수 있습니다. 그리고 중국 안에서 실제로 제공되는 어떤 공개 사이트든 Didomi가 제공하지 않는 본토 호스팅 리소스에 묶인 ICP 비안(국무원령 제292호; 공업정보화부령 제33호)을 지녀야 합니다. | PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37); State Council Order No. 292; MIIT Order No. 33 |
21YunBox 컴플라이언스 팀이(가) 2026년 10월 9일에 출처를 확인했습니다.
본토 중국 청중에, Didomi는 스스로에게 되접히는 질문과 함께 옵니다. Didomi는 동의·선호 관리 플랫폼 — 회사가 데이터 수집을 프라이버시 법의 올바른 쪽에 두기 위해 설치하는 소프트웨어 — 이지만, 배송되는 그대로 중국을 향하면 그 자체의 노출로 변할 수 있습니다. 결정적 쟁점은 배너가 로드되느냐가 아닙니다. 그것은 한꺼번에 두 가지입니다: Didomi가 귀사 중국 사용자로부터 모으는 동의 기록·선호 프로파일·데이터 주체 요청이 유럽연합 안의 인프라에 와서 쉰다는 것, 그리고 동의 로직 자체가 중국이 아니라 유럽의 규칙을 위해 쓰였다는 것. 첫째는 중국 법상 데이터 레지던시·국경 간 질문입니다; 둘째는 중국 PIPL이 GDPR과 매우 다르게 답하는 동의 체제 질문입니다. 둘 다 성능 앞에 앉습니다 — 그리고 Didomi는 첫째를 자사 하위 처리자 목록에 문서화합니다.
한눈에 보는 중국에서의 Didomi
| 무엇이 결정하나 | Didomi 자신의 표현으로 — 그리고 중국 법으로 |
|---|---|
| Didomi가 돌리는 것 | Didomi 플랫폼은 동의 관리 플랫폼(CMP), 선호 관리 플랫폼(PMP), 데이터 주체 요청(DSAR) 처리에 걸칩니다. 그러니 누가 무엇에 동의했는지의 상시 기록, 각 방문자의 저장된 선호, 그 배너가 읽는 기기·IP 신호, 그리고 귀사 중국 사용자가 제기하는 요청 — 그 모든 항목이 개인정보 — 을 보관합니다. |
| 기록이 사는 곳 | 그 하위 처리자 목록은 호스팅을 EU에 둡니다: AWS "Data centers located in the European Union (Frankfurt, Germany),"이고, 클라이언트 데이터·분석에 Snowflake 서버가 "located in the AWS eu-central-1 region (Frankfurt, Germany)"이며, 나머지 하위 처리자는 벨기에에. 어느 것도 중국 본토 안이 아닙니다. |
| 귀사 중국 사용자의 기록 | 중국의 사람에게서 수집되어 EU에 보유된 동의 기록·선호·DSAR 데이터는 PIPL이 규율하는 개인정보의 국경 간 이전입니다(제38~40조): 고지, 별도 동의, 이전 메커니즘 하나. |
| 엉뚱한 체제용으로 지어짐 | Didomi는 그 CMP를 "GDPR, CCPA, and all major global regulations"를 다룬다 기술합니다 — 중국 PIPL을 지명하지 않는 목록. GDPR·TCF식 옵트인은 스스로 PIPL의 별도의 구체적 동의도, 데이터가 해외로 보내지기 전에 PIPL이 요구하는 구별된 동의도 충족하지 않습니다. |
| 레지던시 & 공중에 제공하는 것 | 핵심정보인프라 운영자나 대량 취급자에, 중국에서 수집된 개인정보는 본토에 머물러야 합니다(PIPL 제40조; 사이버보안법 제39조(구 제37조)) — EU 저장소가 할 수 없는 것. 중국 안에서 제공되는 사이트도 Didomi가 제공하지 않는 본토 호스팅 리소스에 묶인 ICP 비안이 필요합니다. |
동의 기록 자체가 개인정보다 — 그리고 Didomi는 그것을 EU에 보관한다
어색한 부분은 가장자리의 세부가 아니라 구조적입니다. Didomi는 귀사가 개인정보를 합법적으로 수집했다는 증거 — 방문자가 준 동의, 그들이 설정한 선호, 데이터 주체 요청 뒤의 문서 자취 — 를 포착하고 보관하려 존재합니다. 그러나 2026년 7월 갱신된 Didomi 자사 하위 처리자 목록은 그 증거를 프랑크푸르트에 둡니다: 그 AWS 호스팅은 *“Data centers located in the European Union (Frankfurt, Germany),“*에 앉고, 클라이언트 데이터·분석에 “Snowflake servers used by Didomi are located in the AWS eu-central-1 region (Frankfurt, Germany).” 그러니 중국 사용자가 동의했다는 증거가 유럽에 보유됩니다 — 이는 동의 도구가 조용히, 귀사를 지켜 주려던 바로 그 국경 간 이전을 생산했다는 뜻입니다.
중국 개인정보 보호법상 그것은 국경 간 이전이고, 의무는 개인정보 취급자 — Didomi가 아니라, 귀사 — 에 앉습니다. 귀사는 고지, 해외 이전의 별도 동의, 그리고 이전 메커니즘 하나를 집니다: CAC 안전성 평가, CAC 표준계약, 또는 인증(PIPL 제38~40조). 동의를 기록하는 플랫폼이 그 동의가 그 뒤 저장되는 곳에 붙는 의무를 떠맡지는 않습니다.
GDPR용으로 지어진 동의 흐름은 PIPL 동의 흐름이 아니다
여기가 Didomi에 특유한 부분입니다. 그것은 유럽 CMP이고, 그 동의 경험을 *“GDPR, CCPA, and all major global regulations”*를 다룬다 기술합니다 — 뚜렷하게도, 중국 PIPL을 지명하지 않는 줄. 그것이 중요한 것은 중국 동의 규칙이 GDPR의 방언이 아니라 자체 체제이기 때문입니다. PIPL은 자발적이고 명시적인 동의를 요구하고, 여러 목적에 하나의 포괄 옵트인이 아니라 별도의 구체적 동의를 요구합니다 — 개인정보가 본토 밖으로 보내지기 전의 구별된 동의를 포함해(PIPL 제38~40조). GDPR 합법적 근거와 Didomi가 열거하는 서구 동의 프레임워크 둘레에 지어진 배너는 유럽에서 완벽히 유효하면서도 중국 사용자에 PIPL이 요구하는 것에 못 미칠 수 있습니다. 그러니 Didomi가 로드되고 배너가 깔끔히 렌더링되는 곳에서도, 그것이 포착하는 동의는 중국 법이 실제로 요구하는 동의가 아닐 수 있습니다 — 배송 위에 올릴 가정이 아니라, 자문과 정할 질문입니다.
본토 리전이 없으니, 국내 저장도 ICP 기반도 없다
Didomi는 AWS·Snowflake·Addingwell을 하위 처리자로 지명하고 그 하나하나를 EU — 프랑크푸르트와 벨기에 — 에 둡니다; 중국 본토 리전은 발행하지 않습니다. 그 지리가 속도가 그림에 들기 전에 두 질문을 더 정합니다.
첫째, 레지던시. 귀사가 핵심정보인프라 운영자나 대량 취급자이면, 중국에서 수집된 개인정보는 본토에 저장되어야 합니다(PIPL 제40조; 사이버보안법 제39조 — 데이터 국내화 조항은 2026년 1월 1일 발효된 2025년 사이버보안법 개정으로 제37조에서 재번호됐고, 실질은 불변). EU 동의·선호 저장소는 어떻게 구성하든 그 의무를 충족할 수 없고, 특정 볼륨 기준을 넘거나 기록이 중요 데이터로 치는 곳에서는 그 이전이 무엇이 떠나기 전에 중국 데이터 수출 안전성 평가를 그 자체로 요구할 수 있습니다. 둘째, 라이선스. 중국 안에서 본토 방문자에게 실제로 제공되는 공개향 사이트는 국무원령 제292호와 공업정보화부령 제33호상 ICP 비안(ICP 备案)으로 갈리고, 그 비안은 물리적으로 본토에 있는 호스팅 리소스에 붙어야 합니다. Didomi는 아무것도 제공하지 않으므로, Didomi 위에는 비안할 대상이 없습니다. “우리는 이미 동의를 위해 Didomi를 돈다”는 국경을 넘어 여행하지 않습니다; 플랫폼이 귀사에 건네야 할 깔끔한 컴플라이언스 이야기가 바로 그것이 중국에서 열어 두는 것입니다.
해외에서 제공되는 동의 게이트는 페이지를 붙잡을 수 있다
전달 절반도 실재하고, 동의 게이트에는 평범한 스크립트보다 더 세게 뭅니다. 쿠키 동의 경험은 클라이언트 측에서 가져와지고, 흔히 방문자가 선택할 때까지 페이지를 붙잡도록 배선됩니다. Didomi 인프라가 EU 리전에 앉으므로, 그 스크립트와 그 구성이 본토 밖에서 끌어와집니다 — 모든 해외 자산이 중국의 사용자에 닿으려 하는 같은 국경 간 홉.
그러니 해외에서 제공되는 동의 게이트가 중국 안에서 느리게 로드되거나 실패하면, 그것은 조용한 구석에서 실패하지 않습니다 — 그것이 앞에 서 있는 바로 그 콘텐츠를 멈춰 세울 수 있습니다. 그것은 법적 문제가 아니라 전달 문제이지만, 중국향 사이트에서 둘은 서로를 강화합니다: 전달하기 가장 어려운 게이트가 또한 국경 간 노출을 나르는 것입니다. 저희는 여기서 Didomi에 대한 어떤 일차 중국 지연 수치도 발행하지 않습니다, 속도가 이 결정이 갈리는 축이 아니고, 방법·샘플·날짜 없는 수치는 오도할 뿐이기 때문입니다. 그리고 21YunBox가 결코 하지 않는 것 — 그리고 어떤 합법적 제공자도 제공할 수 없는 것 — 은 중국의 데이터 수출 규칙이나 어떤 네트워크 제한을 둘러 가는 것입니다: 저희는 어떤 형태의 우회도 결코 쓰거나 권하지 않습니다.
이는 판정이 아니라 리스크 지도입니다. 귀사가 별도 동의, 이전 메커니즘, 국내 저장, 데이터 수출 평가, ICP 비안, 또는 그 조합을 지는지는 귀사 데이터 볼륨, 취급자로서의 역할, 그리고 사용자가 누구인지에 달려 있으니 — 그것에 기대기 전에 자문과 정할 가치가 있습니다.
합법적 경로 — 매핑, 로컬라이즈, 전달
중국향 청중을 위해 Didomi를 돌리는 규정에 맞는 방법이 있고, 그것은 분명한 형태를 갖춥니다. 먼저, 매핑: 저희 중국 팀이 Didomi가 기록하는 동의·선호·요청 데이터에 붙는 PIPL 국경 간·데이터 레지던시 의무를 — 귀사 법인, 귀사 데이터 볼륨, 사용자가 누구인지에 대고 — 짚고, 어디서 데이터 수출 평가, 제39조 저장 의무, 또는 PIPL의 별도 동의 규칙이 실제로 무는지 표시합니다. 법적 결론은 자문과 도달합니다; 저희는 그에 먹이는 기술 그림을 짓습니다.
그 다음 로컬라이즈: 나라에 남아야 하는 기록과 중국 자체 규칙을 충족해야 하는 동의에, 저희는 ICP 비안 국내 기반 위에 중국 거주 저장소와 PIPL 정합 동의 흐름을 세우고 통합합니다 — 동의된 국내 처리·저장의 합법적 국내 패턴 — 그래서 합법적으로 떠날 수 없는 것이 더 이상 떠나지 않고, 귀사는 Didomi를 이미 돕는 시장에 그대로 둡니다.
그 다음 전달: 동의 게이트를 제시하는 중국향 사이트나 앱은 그 자체로 본토의 공개 서비스이므로, ICP 비안 의무를 지고 규정에 맞는 국내 전달이 필요합니다. 21YunBox가 그것을 국내 전달합니다 — 21YunBox Optimizer — 귀사가 이미 돌리는 것 앞단에, 재구축도 재플랫폼도 없이. 그 결과는 중국의 사용자를 위해 합법적으로 그리고 규정에 맞게 도는 동의·선호 설정입니다.
함께 읽기:
자주 묻는 질문
Didomi는 중국 사용자의 동의 데이터를 중국에 저장하나요?
아니요. Didomi 자사 하위 처리자 목록(2026년 7월 갱신)으로, 그 호스팅은 EU에서 돕니다 — 독일 프랑크푸르트의 AWS 데이터센터, AWS eu-central-1(프랑크푸르트) 리전의 Snowflake 서버, 그리고 벨기에의 나머지 하위 처리자 — 중국 본토 리전 없이. 그것이 중국 방문자로부터 포착하는 동의 기록·선호·데이터 주체 요청이 해외에 보유되고, 그것이 그것을 PIPL상 개인정보의 국경 간 이전으로 만듭니다: 취급자(Didomi가 아니라 귀사)가 고지·별도 동의·이전 메커니즘을 집니다.
Didomi가 동의 도구라면, 어떻게 중국에서 컴플라이언스 리스크일 수 있나요?
두 방식으로. 첫째, 중국의 컴플라이언스는 도구가 무엇을 위한 것이 아니라 데이터가 어디 사는지로 갈립니다: 중국 사용자가 동의했다는 증거가 EU에 저장되면, 귀사는 PIPL이 규제하는 바로 그 국경 간 이전을 만들었고, 더하여 핵심정보인프라 운영자나 대량 취급자에 해외 저장소가 충족 못 하는 데이터 레지던시 의무를 만들었습니다. 둘째, Didomi의 동의는 PIPL이 아니라 GDPR과 유사 서구 체제를 위해 지어졌고, GDPR·TCF식 옵트인은 스스로 PIPL의 별도의 구체적 동의 — 데이터가 해외로 가기 전에 중국이 요구하는 구별된 동의 포함 — 를 충족하지 않습니다. 둘 다 자문과 풀어 갈 리스크로 다루십시오.
21YunBox가 우리 Didomi 설정을 중국에서 작동하게 도울 수 있나요?
예. 저희 중국 팀이 귀사 노출 — Didomi가 수집하는 동의·선호 데이터에 붙는 PIPL 국경 간·데이터 레지던시·동의 의무를, 귀사 법인·데이터 볼륨·사용자에 대해 — 을 매핑한 뒤, 나라에 남아야 하는 기록을 PIPL 정합 동의 흐름을 갖춘 중국 거주 저장소로 로컬라이즈하고, 규정에 맞는 중국 존재가 필요로 하는 ICP 비안 국내 전달을 세웁니다, 귀사가 이미 돌리는 Didomi 스택 앞단에. 문의하기 주시면 귀사의 구체적 사례를 짚겠습니다. 그것은 결코 중국의 규칙을 둘러 가는 경로가 아닙니다.
