台灣電商 GDPR 與 PIPA 雙軌合規指南

台灣電商只要向歐盟消費者銷售或追蹤其行為，就同時受《個資法》(PIPA) 與 GDPR 管轄。可行做法是建立「一套控制、兩套標籤」：以 GDPR 的高標設計同意、保留與刪除機制，再對應台灣行業別安全維護辦法的通報與稽核要求。

為什麼台灣電商躲不掉 GDPR？

GDPR 第 3 條的域外效力寫得非常直白：只要你「向歐盟境內資料主體提供商品或服務」，或「監測其在歐盟境內的行為」，不論公司設在台北、香港還是新加坡，都在管轄範圍內。對跨境電商來說，觸發條件比多數經營者想像的低——網站提供歐元計價、支援歐盟國家配送、在歐盟投放再行銷廣告、或單純讓 Meta Pixel 在歐盟訪客瀏覽器上落下 cookie，都足以構成「提供服務」或「行為監測」。

罰則的量級差距是第一個該正視的事實。依 GDPR 第 83 條，最高可處 2,000 萬歐元或全球年營業額 4%（取其高者）。根據 CMS GDPR Enforcement Tracker 的統計，自 2018 年施行以來，歐盟各國主管機關累計開出的罰鍰已超過 50 億歐元，其中廣告科技與電商相關的同意機制瑕疵占相當比例。

台灣這一側同樣在升溫。2023 年 5 月修正的《個人資料保護法》第 48 條，將違反安全維護義務的罰鍰上限由新臺幣 20 萬元提高到 200 萬元；若經限期改正而屆期未改正，得按次處 15 萬元至 1,500 萬元罰鍰（條文全文見全國法規資料庫）。同法第 28、29 條的民事損害賠償，則以每人每事件 500 元至 20,000 元計算，同一原因事實總額以新臺幣 2 億元為上限。對一個會員數十萬的電商而言，這不是「可以吸收」的風險。

更結構性的變化是主管機關。台灣過去採「分散式」監理——由各中央目的事業主管機關（經濟部、金管會、數位發展部等）分別管轄；《個人資料保護委員會組織法》完成立法後，台灣將出現專責的個資保護委員會，監理密度與歐盟 DPA（資料保護機關）會更接近。對跨境營運的團隊來說，這代表「以前沒人查」的僥倖期正在結束。

GDPR 與台灣個資法的關鍵落差在哪裡？

兩部法律的骨架相似（告知、特定目的、當事人權利、安全維護），但實作上的落差集中在六個點。

合法處理基礎

GDPR 第 6 條列出六種合法基礎：同意、契約履行、法律義務、重大利益、公共任務、正當利益。台灣個資法則採「特定目的 + 法定事由」架構（第 19、20 條），非公務機關蒐集需符合列舉事由之一。實務差異在於：GDPR 的「正當利益」(legitimate interest) 可支撐部分分析與防詐用途，但必須做 LIA（正當利益評估）書面紀錄；台灣沒有完全對應的概念，多數電商仍以「當事人同意」與「契約必要」為主。

同意的門檻

GDPR 要求同意必須是自由給予、具體、知情且明確的積極表示——預先勾選、cookie wall、「繼續瀏覽視為同意」都不合格（EDPB 同意指引已多次釐清）。台灣個資法第 7 條對同意的要求較寬鬆，書面同意經 2015 年修法後也可用電子方式。若你用台灣標準做歐盟流量，幾乎必然違規。

當事人權利

台灣個資法第 3 條給予查詢、閱覽、複製、補充更正、停止蒐集處理利用、刪除六項權利。GDPR 第 15–22 條多出兩項關鍵權利：資料可攜權（結構化、通用、機器可讀格式）與反對自動化決策權。電商最容易踩到的是後者——用模型決定誰拿到折扣、誰被標記為高風險退貨客，就可能落入第 22 條。

回應期限

GDPR 第 12 條要求「無不當延遲，且最遲一個月內」回應資料主體請求，複雜案件可延長兩個月並須告知理由。台灣個資法第 13 條則是查詢閱覽 15 日內、更正補充 30 日內，各得延長一次。實務建議：把內部 SLA 統一壓到 15 日，一個流程同時滿足兩邊。

外洩通報

GDPR 第 33 條是知悉後 72 小時內通報監管機關，高風險時另須通知當事人。台灣個資法第 12 條只寫「查明後以適當方式通知當事人」，沒有明定時數；但行業別辦法補上了——經濟部發布的《零售業等個人資料檔案安全維護管理辦法》等規範，普遍要求事故發生後 72 小時內通報中央目的事業主管機關。兩邊時鐘其實一樣緊。

跨境傳輸

這是台灣電商最大的單一風險點。截至目前，台灣不在歐盟執委會的適足性認定清單上（清單由歐盟執委會公布，現含日本、韓國、英國、瑞士等）。這代表從歐盟把會員資料傳回台灣的伺服器，必須依 GDPR 第 46 條採用標準契約條款（SCC）並完成移轉影響評估（TIA）。反方向，台灣個資法第 21 條則授權中央目的事業主管機關得限制國際傳輸。

「一套控制、兩套標籤」的合規架構

維護兩套平行的隱私流程，成本會翻倍而且必然走樣。比較務實的做法，是以較嚴格的 GDPR 為設計基線，再把台灣法規要求當成「附加標籤」掛在同一組控制上。

具體拆成四層：

1. 資料盤點層：一份 RoPA（GDPR 第 30 條的處理活動紀錄），欄位同時標註台灣的「特定目的代號」（法務部公告的 182 項特定目的及個人資料類別代號）。一張表餵兩套稽核。
2. 同意層：一個 CMP（Consent Management Platform），對歐盟/英國 IP 採 opt-in 預設全關，對台灣流量採告知 + 明示同意，但兩者共用同一組同意事件 schema 與稽核日誌。
3. 權利請求層：一條 DSAR 流程，15 日 SLA，涵蓋 GDPR 八項與台灣六項權利的聯集。
4. 事故應變層：一本 runbook，72 小時時鐘，兩份通報範本（歐盟 DPA、台灣目的事業主管機關）。

這個架構的好處是：當你之後要進入新加坡（PDPA）、澳洲（Privacy Act）或日本（APPI）市場時，只需新增標籤與範本，不必重建流程。對以亞太為營運樞紐、同時服務歐美客戶的團隊，這種「單一控制、多市場對應」的設計是可擴充性的來源。

同意與 Cookie 管理的技術實作

歐盟的執法重心這幾年明顯落在廣告追蹤同意上。技術上最小可行解是 CMP 搭配 Google Consent Mode v2 與平台原生的同意 API。

Google Consent Mode v2 的預設狀態應該是「全部拒絕」，再由 CMP 依地區覆寫：

1<script>
2  window.dataLayer = window.dataLayer || [];
3  function gtag(){dataLayer.push(arguments);}
4
5  // 預設：歐盟/英國訪客全部拒絕
6  gtag('consent', 'default', {
7    'ad_storage': 'denied',
8    'ad_user_data': 'denied',
9    'ad_personalization': 'denied',
10    'analytics_storage': 'denied',
11    'functionality_storage': 'granted',
12    'security_storage': 'granted',
13    'wait_for_update': 500,
14    'region': ['EU', 'GB', 'CH', 'NO', 'IS', 'LI']
15  });
16
17  // 台灣：分析預設開啟，廣告仍待同意
18  gtag('consent', 'default', {
19    'ad_storage': 'denied',
20    'analytics_storage': 'granted',
21    'region': ['TW']
22  });
23</script>

Shopify 商店則應透過 Customer Privacy API 把同意狀態同步給 App 生態與像素，而不是只在前端擋 script：

1await window.Shopify.customerPrivacy.setTrackingConsent(
2  {
3    analytics: true,
4    marketing: false,
5    preferences: true,
6    sale_of_data: false
7  },
8  () => console.log('consent recorded')
9);

三個常被忽略的細節：

• 同意紀錄要可舉證。GDPR 第 7(1) 條要求你能證明同意存在。存下 timestamp、CMP 版本、同意字串（TCF 的 consent string）、政策版本號，保留期間至少與資料保留期一致。
• 撤回要和給予一樣容易（第 7(3) 條）。頁尾必須有常駐的「Cookie 設定」入口。
• 台灣端的告知義務仍在。個資法第 8 條的告知五要件（蒐集目的、個資類別、利用期間地區對象方式、當事人權利、不提供之影響）必須出現在註冊與結帳流程，而非只躲在隱私權政策深處。

跨境傳輸：SCC、TIA 與資料落地怎麼選？

台灣電商處理歐盟資料，實務上有三條路：

路線 A：SCC + TIA（最常見）

與歐盟端的控制者/處理者簽署歐盟執委會 2021 年版標準契約條款，並完成移轉影響評估，說明台灣法制下政府存取資料的範圍與救濟管道，再加上補充措施（傳輸與靜態加密、金鑰由歐盟端或第三地保管、政府調取通知程序）。成本低，但文件功夫不能省——EDPB 的第 01/2020 補充措施建議就是 TIA 的實質審查標準。

路線 B：歐盟區域落地

把歐盟客戶的個資存放在法蘭克福或都柏林的區域（AWS eu-central-1、Shopify 的歐盟資料中心選項），台灣團隊透過權限控管的介面存取。注意：遠端存取本身就是傳輸，所以 SCC 通常還是要簽，但風險面縮小很多。

路線 C：假名化 / 不傳原始識別資料

分析與 BI 只接收假名化後的資料集，原始識別欄位留在歐盟。這對 AI 模型訓練特別重要，後面會談。

反向的台灣側限制也要看：個資法第 21 條允許主管機關在「涉及國家重大利益」或「接受國對個資保護未有完善法規」等情形下限制國際傳輸，金融、電信等特許行業已有具體函令。電商若同時經營金融科技或電信加值服務，必須逐業別確認。

資料主體請求（DSAR）如何用自動化消化？

雙軌合規最吃人力的就是 DSAR。手動處理一筆跨系統的刪除請求——Shopify、ERP、電子報平台、客服系統、資料倉儲、備份——往往要協調四五個負責人。

可行的自動化骨架：

1. 單一入口：一個 /privacy/request 表單，驗證身分（登入態或 email 一次性驗證碼），產生工單。
2. 平台 webhook 接線：Shopify 的 customers/data_request、customers/redact、shop/redact 三個 GDPR webhook 必須有實際 endpoint，而不是回 200 了事。
3. 下游扇出：工單觸發各系統的刪除/匯出 job，回寫完成狀態。
4. 可攜格式輸出：JSON 或 CSV，含訂單、瀏覽、同意、客服紀錄。

1# 驗證 Shopify GDPR webhook 已註冊
2curl -s -X GET \
3  "https://your-shop.myshopify.com/admin/api/2025-01/webhooks.json" \
4  -H "X-Shopify-Access-Token: $SHOPIFY_TOKEN" \
5  | jq '.webhooks[] | select(.topic | startswith("customers/")) | {topic, address}'

資料保留同樣該程式化，而不是靠人記得。例如以排程作業清理逾期的訪客層級資料：

1-- 每日執行：刪除逾 26 個月未再互動的未成交訪客事件
2DELETE FROM analytics.visitor_events
3WHERE last_seen_at < NOW() - INTERVAL '26 months'
4  AND customer_id IS NULL;

這類刪除作業的執行紀錄要留存，因為當主管機關問「你如何落實保留期限」時，cron log 比政策文件有說服力。

我們在一個經營歐洲與台灣雙市場的台灣消費品牌專案中，就是把 DSAR 工單引擎建在既有的工單系統上，用 Shopify Admin API 2025-01、Klaviyo API 與資料倉儲的刪除程序串成一條扇出流程；重點不在技術難度，而在於把「誰負責哪個系統」寫進資料盤點表，否則每次請求都要重新找人。

AI 功能為雙軌合規帶來哪些新風險？

2025 年以後，多數電商都已經把 LLM 用在客服摘要、商品文案、推薦排序與退貨風控上。這三件事會同時觸發兩部法律：

• 自動化決策：GDPR 第 22 條限制「完全自動化且產生法律效果或類似重大影響」的決策。動態定價、自動拒絕退款、風險評分封鎖帳號，都可能落入範圍，須提供人工介入管道。
• 目的外利用：把客服對話紀錄拿去微調模型，在台灣個資法下屬於特定目的外利用（第 20 條），需另取得同意或符合法定事由；在 GDPR 下則需重新評估目的相容性（第 6(4) 條）。
• 第三方傳輸：呼叫 OpenAI、Anthropic 或 Google 的 API，就是把資料交給處理者。必須簽 DPA、確認資料不被用於訓練、確認處理地區。

最務實的控制是在送進模型之前就做遮罩：

1import re
2
3PATTERNS = {
4    "email": r"[\w.+-]+@[\w-]+\.[\w.]+",
5    "tw_phone": r"09\d{2}[- ]?\d{3}[- ]?\d{3}",
6    "tw_id": r"[A-Z][12]\d{8}",
7    "card": r"\b(?:\d{4}[- ]?){3}\d{4}\b",
8}
9
10def redact(text: str) -> str:
11    for label, pattern in PATTERNS.items():
12        text = re.sub(pattern, f"[{label.upper()}]", text)
13    return text
14
15# 送入 LLM 前一律經過 redact()

歐盟《人工智慧法》(AI Act) 已於 2024 年生效並分階段適用，依歐盟執委會公布的時程，禁止性 AI 行為與 AI 素養義務自 2025 年 2 月起適用，通用型 AI 模型義務自 2025 年 8 月起適用。對電商而言，多數應用屬低風險，但透明度義務（讓使用者知道正在與 AI 互動）已經是現在就要做的事。

90 天雙軌合規落地路線圖

第 1–30 天：盤點與止血

1. 完成資料盤點與 RoPA，涵蓋所有 SaaS、像素、App、第三方物流。
2. 掃描網站上實際載入的第三方 script——幾乎每次盤點都會找到沒人記得安裝的追蹤碼。
3. 對歐盟/英國流量立即改為 opt-in 預設，這是風險最高、修復最快的一項。
4. 檢查 Shopify / 自建站的 GDPR webhook 是否有真實 endpoint。

第 31–60 天：文件與契約

1. 改寫隱私權政策為雙軌版本：GDPR 第 13/14 條告知要件 + 台灣個資法第 8 條告知五要件。
2. 與所有處理者簽 DPA；對台灣母體與歐盟實體之間簽 SCC，並完成 TIA 書面紀錄。
3. 建立保留期程表，並把刪除作業排程化。
4. 評估是否需指定 GDPR 第 27 條的歐盟代表（非歐盟企業在特定情形下為強制）。

第 61–90 天：流程與演練

1. 上線 DSAR 工單流程，設 15 日 SLA。
2. 寫好外洩應變 runbook，做一次桌上演練，確認 72 小時內誰下判斷、誰送件。
3. 對客服與行銷團隊做訓練——多數外洩事件起於人員操作，而非系統被攻破。
4. 建立年度複查節奏，把隱私檢查放進新功能上線的 checklist。

最常見的五個錯誤

• 把隱私權政策當成合規本身。政策是輸出，不是控制。主管機關查的是你是否「真的」在 26 個月後刪除資料。
• CMP 只擋前端 script，後端仍照送。Server-side tagging 普及後，這個漏洞特別常見。
• 忘記台灣的行業別安全維護辦法。零售、電商、旅遊、金融各有專屬辦法，罰則依附在個資法第 27 條與第 48 條上。
• 把資料全量倒進 BI 與 LLM。分析需求幾乎都能用假名化資料滿足。
• 以為沒有歐盟公司實體就沒事。GDPR 第 3(2) 條管的是行為，不是註冊地。

跨市場團隊的結構性優勢

對把亞太當作營運樞紐的品牌，雙軌合規其實可以變成資產而非成本。台灣、香港、新加坡的團隊在亞洲時區完成資料處理與客服，歐洲時區由自動化與事先設定好的保留政策接手；DSAR 與外洩通報的 72 小時時鐘，在跨時區編制下反而更容易達成，因為時鐘走的時候總有人醒著。

反過來，歐美品牌若要把亞洲營運設在台灣或香港，同一套架構也能向下相容——因為你已經用最嚴格的標準設計了控制，新增一個市場只是多一組標籤與一份通報範本。

Branch8 以香港為總部，在台灣、新加坡、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，協助跨境電商把資料盤點、同意管理、DSAR 自動化與跨境傳輸文件整合成單一可維運的架構。若你正在同時面對歐盟與台灣的合規要求，歡迎與我們談談你的資料流現況。

Sources

• EUR-Lex — Regulation (EU) 2016/679 (GDPR)
• European Commission — Data protection
• European Data Protection Board
• 全國法規資料庫 — 個人資料保護法
• 個人資料保護委員會
• 數位發展部
• CMS — GDPR Enforcement Tracker
• Shopify Developers — Privacy and compliance APIs
• Google — Consent Mode documentation