香港 PDPO 跨境數據傳輸中國大陸合規指南 2026

香港企業將個人資料傳到中國大陸,必須同時處理兩套制度:香港 PDPO(《個人資料(私隱)條例》)雖然第 33 條至今未生效,但 DPP1、DPP3 與 DPP4 仍全面適用;而資料一旦落地內地,《個人信息保護法》(PIPL)與數據出境規則同樣會反向約束回流與再傳輸。本文拆解 2026 年的實際操作路徑。

2026 年的監管底線是什麼?

很多香港公司法務到今天仍停留在一個錯誤印象:「第 33 條未生效,所以跨境傳輸在香港不受管。」這句話只對了一半。

香港:PDPO 第 33 條未生效,但責任沒有消失

《個人資料(私隱)條例》(第 486 章)第 33 條限制將個人資料移轉至香港以外地方,但該條文自 1996 年條例生效以來一直未被實施——香港個人資料私隱專員公署(PCPD)在其跨境資料轉移指引中亦明確說明此點。然而,即使第 33 條未生效,以下條文對跨境場景仍然有效:

• 保障資料第 1 原則(DPP1):收集時須以合法公平方式進行,並在收集時告知資料可能轉移的類別承讓人。
• 保障資料第 3 原則(DPP3):未經訂明同意,不得將資料用於收集時所述以外的新目的——「把客戶資料送到深圳的集團總部做集中分析」,如果當初的收集聲明沒有涵蓋,就是新目的。
• 保障資料第 4 原則(DPP4):資料使用者須採取切實可行的步驟保障資料安全,包括資料交由代理人或處理者處理時。資料流出香港,法律責任不會跟著流走。

PCPD 於 2014 年 12 月發出《保障個人資料:跨境資料轉移指引》,並於 2022 年 5 月補充發布建議使用的跨境轉移示範合約條款(Recommended Model Contractual Clauses),這份示範條款是目前香港方最實用的合約模板。

內地:三條合法出境路徑與一組豁免

如果資料主體在內地、或資料是在內地收集的,那麼適用的是 PIPL 第 38 條。國家互聯網信息辦公室(CAC)於 2024 年 3 月 22 日公布《促進和規範數據跨境流動規定》,把門檻大幅調整:

1. 安全評估:向境外提供重要數據;關鍵信息基礎設施運營者出境個人信息;自當年 1 月 1 日起累計向境外提供 100 萬人以上非敏感個人信息,或 1 萬人以上敏感個人信息。
2. 標準合同備案或保護認證:累計 10 萬至 100 萬人非敏感個人信息,或不足 1 萬人敏感個人信息。
3. 豁免:累計不足 10 萬人非敏感個人信息;以及為訂立/履行個人作為一方的合同(如跨境購物、酒店預訂、簽證辦理)、跨境人力資源管理、緊急情況保護生命健康等必需的出境。

同一份 2024 年規定亦把數據出境安全評估結果的有效期由 2 年延長至 3 年,並允許期滿前申請延長。另外,《網絡數據安全管理條例》自 2025 年 1 月 1 日起施行,把出境義務、數據分類分級與事件報告要求進一步細化到行政法規層級。

大灣區標準合同便利化措施值得用嗎?

2023 年 12 月,CAC 與香港特區政府創新科技及工業局簽署合作備忘錄,推出《粵港澳大灣區(內地、香港)個人信息跨境流動標準合同》(俗稱「大灣區標準合同」),首階段聚焦銀行、徵信與醫療等行業試行。

它的實際好處有三點:

• 免除出境安全評估與標準合同備案的部分前置要求,改以備案制簡化流程(適用於非重要數據、非關鍵信息基礎設施運營者)。
• 合同模板本身已獲雙方監管機構認可,減少逐案法律談判成本。
• 適用範圍限定在大灣區九市與香港之間——這也是它最大的限制。

換句話說,如果你的數據流是「香港 ↔ 深圳 / 廣州 / 珠海」,大灣區標準合同通常是成本最低的路徑;如果對端在上海、北京或成都,你仍需回到 PIPL 的標準合同備案或安全評估軌道。對於把香港當成亞太總部、同時在新加坡、台北與越南設有交付團隊的集團而言,這意味著不能只設計一條跨境通道,而要設計一張通道地圖。

怎樣判斷你的數據流屬於哪一檔?

實務上 90% 的爭議來自同一個原因:公司根本不知道自己有多少條跨境數據流。先做清單,再談機制。

第一步:建立跨境數據流清單

把每一條跨境流動當成一個可版本控制的紀錄,而不是 Excel 表格裡的一行字。以下是我們在實作中常用的 YAML 結構,可直接納入 Git repo 並接上 CI 檢查:

1# data-flows/crm-sync-hk-to-sz.yaml
2flow_id: FLOW-2026-014
3name: CRM 會員資料同步至深圳數據倉
4source:
5  jurisdiction: HK
6  system: Salesforce Sales Cloud
7  legal_entity: HK-OPCO
8destination:
9  jurisdiction: CN
10  system: MaxCompute (阿里雲 華東2)
11  legal_entity: CN-TECHCO
12  role: processor        # processor | controller | joint
13data_subjects:
14  categories: [customers, loyalty_members]
15  estimated_volume_annual: 420000
16  includes_minors: false
17data_elements:
18  - field: full_name
19    sensitive_cn: false
20  - field: mobile_number
21    sensitive_cn: false
22  - field: id_card_number
23    sensitive_cn: true     # PIPL 敏感個人信息
24  - field: purchase_history
25    sensitive_cn: false
26purpose: 集團層級會員分析與補貨預測
27pdpo_basis:
28  dpp1_notice_covers_transfer: true
29  dpp3_new_purpose_consent: required
30cn_mechanism: standard_contract_filing   # exempt | standard_contract_filing | security_assessment | gba_contract
31retention_months: 36
32safeguards:
33  encryption_in_transit: TLS1.3
34  encryption_at_rest: AES-256
35  pseudonymisation: id_card_number -> HMAC-SHA256
36  access_control: RBAC + 行級權限
37review_due: 2026-09-30
38owner: [email protected]

第二步:用腳本做閾值彙總,而不是靠記憶

內地的閾值是自當年 1 月 1 日起累計計算,所以它是一個滾動數字,不是一次性判斷。把清單丟進 jq 或任何 CI job,每月跑一次:

1# 彙總年度累計出境人數,按機制分組
2yq -o=json '.' data-flows/*.yaml | \
3  jq -s 'group_by(.cn_mechanism)
4         | map({mechanism: .[0].cn_mechanism,
5                total_subjects: (map(.data_subjects.estimated_volume_annual) | add),
6                flows: length})'

當 total_subjects 逼近 1,000,000,或任何含敏感欄位的流動逼近 10,000 人,就要啟動安全評估準備——這類申報通常需要數月,臨急抱佛腳沒有意義。

第三步:決策順序

1. 資料是否包含內地定義的重要數據?是 → 安全評估,無其他選項。
2. 傳輸方是否為關鍵信息基礎設施運營者?是 → 安全評估。
3. 是否落入合同履行、跨境人資管理等豁免情形?是 → 記錄理據,無需機制,但仍須做告知與影響評估。
4. 年度累計是否低於 10 萬人非敏感?是 → 豁免。
5. 兩端是否都在大灣區範圍內且屬試行行業?是 → 考慮大灣區標準合同。
6. 其餘 → PIPL 標準合同 + 個人信息保護影響評估(PIPIA)備案。

合約與技術控制怎樣才算「切實可行」?

DPP4 用的是「切實可行的步驟」(practicable steps)這種彈性措辭,PCPD 的執行案例中,判斷重點通常落在三件事:資料是否超出必要範圍、加密與存取控制是否與敏感度相稱、以及處理者是否受合約約束。

合約層面的最低配置

• 採用 PCPD 2022 年示範合約條款(控制者對控制者、或控制者對處理者兩個版本),或在內地標準合同之外加簽香港側附錄。
• 明確再轉移(onward transfer)限制:內地實體不得在未經書面同意下再傳給第三方或其他境外地區。
• 加入審計權與協助義務:當香港側收到查閱資料要求(DSAR)或外洩事故,內地側須在約定時限內配合。
• 處理政府查閱條款:內地法律可能要求企業配合有權機關調取資料。誠實的做法是在合約中約定「在法律允許範圍內通知對方」,而不是寫一條根本無法履行的絕對禁止條款。

技術層面的三個高回報控制

1. 欄位級最小化:集團分析通常不需要身份證號碼。把識別欄位在出境前以 HMAC 做假名化,保留關聯能力但降低敏感度等級——這可能直接把你從「安全評估」降檔到「標準合同」。
2. 區域化部署而非全量同步:把需要留港的資料留在香港節點,只把聚合後的指標送往內地 BI。
3. 可證明的日誌:出境記錄、存取日誌至少保留與法規一致的期限,並確保可按資料主體檢索。

AI 工作流有沒有製造新的跨境數據流?

這是 2026 年最容易被忽略的風險面。當團隊用 LLM 加速營運——客服摘要、合約審閱、報表生成——每一次 API 呼叫都可能是一次未登記的跨境傳輸。

需要在清單裡明確記錄的問題:

• 模型端點部署在哪個區域?把 Azure OpenAI 的 endpoint 設在 East Asia(香港)與設在美東,法律後果完全不同。
• 供應商是否使用你的 prompt 做模型訓練?零保留(zero data retention)設定是否已實際開啟,還是只在銷售簡報裡出現?
• RAG 檢索層抓的是哪個資料庫?很多團隊把向量庫架在便宜的區域,等於把原始個人資料複製了一份到未評估的司法管轄區。

PCPD 於 2024 年 6 月發布《人工智能(AI):個人資料保障模範框架》,為採購、治理、風險評估與人手監督提供了具體建議;公署其後亦就僱員使用生成式 AI 發出指引。把 AI 用量納入既有的跨境數據清單,比另起一套 AI 治理文件務實得多。

一個具體做法:在 gateway 層強制標記每個 LLM 請求的資料分類,拒絕未分類流量。

1# 以反向代理攔截未標記分類的 LLM 請求
2location /v1/llm/ {
3    if ($http_x_data_classification = "") { return 400 "missing X-Data-Classification"; }
4    if ($http_x_data_classification = "personal-sensitive") { return 403 "sensitive PII blocked on this route"; }
5    proxy_set_header X-Region-Pin "eastasia";
6    proxy_pass https://llm-gateway.internal;
7}

2026 年還有哪些相鄰法規會影響你?

跨境合規不會孤立存在。三項時間點值得放進日程:

• 香港《保護關鍵基礎設施(電腦系統)條例》:該條例於 2025 年由立法會通過,並於 2026 年 1 月 1 日起生效,對獲指定的關鍵基礎設施營運者施加電腦系統安全管理、事故通報與演習義務。若你的客戶是銀行、電訊、能源或運輸業的指定營運者,他們會把要求沿供應鏈傳遞給你。
• PDPO 修訂方向:香港政府與 PCPD 已公開表示正研究修例,方向包括強制資料外洩通報機制、訂明資料保留期、以及賦予專員直接施加行政罰款的權力。即使草案尚未落實,提前建立 72 小時內可完成的外洩應變流程是低風險投資。
• 內地《網絡安全法》修正:全國人大常委會通過的修正案自 2026 年 1 月 1 日起施行,整體提高了違法成本並與 PIPL、《數據安全法》的罰則銜接。

以香港為亞太樞紐的架構選項

對美國、英國與歐盟企業來說,香港的價值不在於成本,而在於它是少數能同時貼近內地監管現實、又維持普通法制度與資料自由流通的節點。常見的三種架構:

選項一:香港主控,內地只做處理者

香港實體持有控制者角色,內地子公司或 BPO 僅作為受託處理者。優點是資料主體關係清晰、DSAR 由香港統一回應;缺點是內地側任何自主分析用途都會觸發角色變更。

選項二:雙控制者 + 區域隔離

香港與內地各自持有本地資料,只交換聚合或假名化結果。合規負擔最低,但集團層面的單一客戶視圖(single customer view)會被犧牲,需要以 ID graph 或聯邦查詢補償。

選項三:新加坡作為第三地中樞

把分析與資料科學工作負載放在新加坡,受 PDPA 管轄,再分別與香港、內地建立受控通道。對於同時覆蓋東南亞市場的集團,這個設計能避免把內地法規要求擴散到馬來西亞、印尼與越南的業務線。

我們為一間在大灣區設有生產基地、同時在香港與東南亞經營零售的消費品集團做資料流梳理時,最終採用的是選項二的變體:門店 POS 與會員資料按地域分庫,只有經假名化的商品層銷售數據跨境,供應鏈預測模型則在兩地各訓練一次。技術上不比全量同步優雅,但它讓法務能用一頁紙說明清楚資料去了哪裡——這在監管問詢時的價值遠高於架構美感。

落地時最常見的五個錯誤

1. 把 PIPL 標準合同當成一次性文件:標準合同需附 PIPIA 報告備案,且處理目的、方式或接收方發生實質變更時須重新評估。
2. 忽略員工資料:跨境人資管理雖可能屬豁免情形,但豁免的是出境機制,不是告知義務與安全義務。
3. 用供應商的合規聲明替代自己的評估:雲端供應商的區域合規認證不會自動覆蓋你的使用方式。
4. DSAR 流程斷在邊界:香港客戶要求查閱資料,但資料實際存在內地倉庫,而合約沒有規定配合時限。PDPO 的 40 日回應期不會因此延長。
5. 清單與現實脫節:架構改了,YAML 沒改。把資料流清單納入變更管理流程(例如在 PR template 加一個「本次變更是否新增跨境資料流?」勾選項)比每年做一次審計有效。

未來 12 個月的行動順序

1. 第 1–4 週:盤點所有跨境資料流,包括 SaaS、BI、AI API 與備份複本。輸出可版本控制的清單。
2. 第 5–8 週:按年度累計人數與敏感欄位分檔,標記每條流的所需機制。
3. 第 9–16 週:補齊合約(PCPD 示範條款 + 內地標準合同或大灣區合同),完成 PIPIA。
4. 第 17–24 週:實施技術控制——欄位最小化、區域鎖定、日誌保留。
5. 持續:每月跑閾值彙總;每季複核 AI 供應商的資料保留設定;每年或在重大變更時重做影響評估。

跨境合規做得好的團隊,不是法務最嚴格的那一隊,而是能把合規狀態用機器可讀格式維護起來的那一隊。清單一旦活起來,後面所有事情都只是查表。

如果你正在設計橫跨香港、內地與東南亞的資料架構,Branch8 在香港、新加坡、台北與東南亞各地都有交付團隊,熟悉 PDPO、PIPL 與 PDPA 三套制度下的實際工程取捨——歡迎帶著你的現有架構圖來談,我們從資料流清單開始。

Sources

• 香港個人資料私隱專員公署 — Office of the Privacy Commissioner for Personal Data
• 香港電子版香港法例 — 《個人資料(私隱)條例》第486章
• 國家互聯網信息辦公室 — Cyberspace Administration of China
• 中國人大網 — 中華人民共和國個人信息保護法
• 香港特別行政區政府創新科技及工業局 — Innovation, Technology and Industry Bureau
• 香港特別行政區政府保安局 — 保護關鍵基礎設施(電腦系統)條例
• 新加坡個人資料保護委員會 — PDPC Singapore
• IAPP — International Association of Privacy Professionals