台灣個資法 2026：舊有名單重新取得同意的合規操作流程

台灣所謂「PIPA 2026」實際是《個人資料保護法》(PDPA) 的執法升級：個人資料保護委員會成立後，行銷同意的舉證責任會落在企業身上。舊名單合規化的核心是四件事——分級盤點、重新告知、double opt-in 再同意、可稽核的同意紀錄。本文提供可直接執行的步驟與程式碼。

先釐清：台灣的「PIPA」其實是個資法（PDPA）

很多跨境團隊在內部文件寫「Taiwan PIPA」，是因為韓國有 PIPA、日本有 APPI、中國大陸有 PIPL，習慣性套用了同一套命名。台灣的法律正式名稱是《個人資料保護法》，英文官方譯名為 Personal Data Protection Act（PDPA），法規全文可在法務部「全國法規資料庫」查得。

名稱不重要，但你在寫 Data Processing Agreement、跟歐洲客戶做 vendor due diligence、或在 Notion 建合規知識庫時，用錯名稱會導致條文對不上。建議在內部一律以「個資法 + 條號」標註，例如「個資法 §20 I 目的外利用」，避免與韓國 PIPA 的條文混淆。

2026 年前後真正在變的三件事

1. 主管機關集中化。 依《個人資料保護委員會組織法》（立法院 2024 年底三讀通過），台灣將設立獨立的個人資料保護委員會。在此之前，個資執法分散在各中央目的事業主管機關（電商多由經濟部、數位發展部與地方政府分管），實務上稽查密度低且標準不一。
2. 罰則已經先加重。 2023 年 5 月修正公布的個資法第 48 條規定：非公務機關違反第 27 條安全維護義務，經令限期改正而屆期未改正者，處新臺幣 2 萬元至 200 萬元罰鍰；情節重大者，直接處 15 萬元至 1,500 萬元，並得按次處罰（資料來源：全國法規資料庫，個人資料保護法第 48 條）。也就是說，罰則升級不必等 2026。
3. 舉證重心轉移。 一旦有專責機關受理申訴，實務上最常被要求提供的就是「你憑什麼寄這封行銷信給我」的同意紀錄。沒有紀錄 = 沒有同意，這是所有資料保護法域的共通實務。

注意：委員會的成立時程與後續個資法大修草案內容，以官方公告為準，請不要把任何部落格（包含本文）當作生效日期依據。

為什麼舊有名單是最大的風險集中點

電商的舊名單通常混雜了七、八年的多種來源：早期沒有 checkbox 的訂單匯入、線下展場紙本、抽獎活動、KOL 名單交換、第三方廣告的 lead form、以及 CSV 手動上傳。這些來源在個資法下的合法性完全不同。

個資法第 19 條要求非公務機關蒐集個資須有特定目的及法定事由；第 20 條第 1 項規定目的外利用須符合法定要件，而首次行銷時應提供當事人表示拒絕接受行銷之方式，並支付所需費用（資料來源：全國法規資料庫，個人資料保護法第 19、20 條）。實務上，「履行買賣契約」蒐集的 email 不等於「可以持續寄促銷」的同意基礎。

再加上台灣電商規模：依經濟部統計處零售業營業額統計，零售業網路銷售額占整體零售業營業額比重已達約一成，且長期上升——這代表大量企業手上都握有數十萬筆以上的歷史會員資料。名單越老，來源越不可考，風險越集中。

對照歐盟，GDPR 第 83 條的行政罰上限為 2,000 萬歐元或全球年營業額 4%（取高者），依 gdpr-info.eu 彙整之條文。如果你的品牌同時在台灣與 EU/UK 銷售，重新取得同意這件事本來就得做一次，順手把兩套法域的證據需求一起滿足，成本遠低於分兩次做。

前置準備：開工前要備齊的六項

在寫任何一行程式前，先確認以下條件成立，否則後面每一步都會回頭重做。

• 資料來源清冊（Data Inventory）。 每一批名單至少記錄：來源系統、取得年月、當時的表單截圖或條款版本、是否有勾選紀錄。
• 當年的隱私權政策版本。 從網站備份、Wayback Machine 或 Git 歷史撈出各版本，這是判斷「原始特定目的」的唯一依據。
• 權限。 Shopify Admin API（read_customers, write_customers）、Klaviyo Private API Key、資料倉儲（BigQuery / Snowflake / MySQL）寫入權限。
• 一個獨立的 consent 資料表位置。 不要塞在 CRM 的自訂欄位裡；同意紀錄需要 append-only。
• 法務或外部律師的一次性審閱窗口。 分級規則與告知文案必須由具台灣執業資格者確認。
• 寄送信譽基礎。 SPF / DKIM / DMARC 已設定完成。重新同意信的退訂與投訴率會高於平常，網域信譽差會直接進垃圾桶。

步驟一：建立可稽核的同意資料模型

先有資料表，再談流程。以下是最小可用的 append-only 結構（MySQL 8 / PostgreSQL 均可微調使用）：

1CREATE TABLE consent_events (
2  id              BIGINT AUTO_INCREMENT PRIMARY KEY,
3  subject_hash    CHAR(64)     NOT NULL,          -- SHA256(lower(email) + salt)
4  email           VARCHAR(320) NOT NULL,
5  market          CHAR(2)      NOT NULL,          -- TW / HK / SG / AU
6  purpose_code    VARCHAR(40)  NOT NULL,          -- MKT_EMAIL / MKT_SMS / PROFILING
7  event_type      ENUM('GRANT','WITHDRAW','REFRESH','EXPIRE') NOT NULL,
8  legal_basis     VARCHAR(40)  NOT NULL,          -- PDPA_ART19_CONSENT / CONTRACT
9  notice_version  VARCHAR(20)  NOT NULL,          -- 告知文案版本，如 tw-2026-01
10  policy_version  VARCHAR(20)  NOT NULL,
11  collected_via   VARCHAR(40)  NOT NULL,          -- reconsent_email_doi / checkout / pos
12  ip_address      VARBINARY(16),
13  user_agent      TEXT,
14  proof_token     CHAR(64),                       -- double opt-in 驗證 token 的 hash
15  occurred_at     DATETIME(3)  NOT NULL,
16  created_at      DATETIME(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
17  INDEX idx_subject (subject_hash, purpose_code, occurred_at)
18);

關鍵設計原則：

1. 一個目的一列。 email 行銷、SMS 行銷、跨品牌共享、自動化剖析（profiling）要分開。個資法的同意是綁在「特定目的」上的，不是綁在人身上。
2. 只新增不更新。 目前狀態用 view 算出來，不要 UPDATE 覆蓋歷史。
3. 存告知版本，不只存 true/false。 被申訴時要能還原「當時他看到的字」。

目前有效同意的查詢：

1CREATE VIEW consent_current AS
2SELECT c.subject_hash, c.purpose_code, c.event_type, c.occurred_at, c.notice_version
3FROM consent_events c
4JOIN (
5  SELECT subject_hash, purpose_code, MAX(occurred_at) AS mx
6  FROM consent_events GROUP BY subject_hash, purpose_code
7) l ON l.subject_hash = c.subject_hash
8   AND l.purpose_code = c.purpose_code
9   AND l.mx = c.occurred_at;

預期輸出：每位當事人每個目的僅一列，event_type = 'GRANT' 者才可納入行銷發送對象。

步驟二：把舊名單分成三桶

不要對整份名單一視同仁地寄「請重新訂閱」。這樣做會把本來合法的名單也一起打掉。

A 桶：有明確同意紀錄（保留）

條件：有時間戳、有勾選紀錄或 double opt-in 記錄、當年的告知內容涵蓋現在的行銷用途。處理方式是回填而非重新徵求——把歷史證據寫進 consent_events，event_type='GRANT'、collected_via 標註原始來源。

B 桶：有交易關係但無行銷同意（重新取得同意）

條件：是曾下單客戶，email 來自結帳流程，但當年結帳頁沒有行銷勾選欄位。這一桶是本文流程的主體。可以寄一次重新同意信（依個資法第 20 條，首次行銷須提供免費拒絕方式，故信中必須有一鍵拒絕），但不得在未回應的情況下持續促銷。

C 桶：來源不明或第三方提供（停止使用）

條件：買來的名單、活動交換名單、無法還原來源的 CSV、或是原始蒐集目的與行銷完全無關。誠實面對：這一桶原則上不該再寄行銷信，包括「重新同意信」本身。對無合法事由的名單寄信徵求同意，等於再犯一次目的外利用。正確作法是封存後刪除。

分桶的 SQL 骨架（依你的欄位調整）：

1SELECT
2  customer_id,
3  CASE
4    WHEN consent_ts IS NOT NULL AND consent_source IN ('checkout_checkbox','doi_email')
5      THEN 'A_KEEP'
6    WHEN last_order_at IS NOT NULL AND consent_ts IS NULL
7      THEN 'B_RECONSENT'
8    ELSE 'C_SUPPRESS'
9  END AS bucket
10FROM crm_customers
11WHERE market = 'TW';

預期輸出：三桶筆數。實務上舊系統遷移過的品牌，B 桶通常是最大的一塊；C 桶若超過兩成，代表過去的表單治理有系統性問題，要一併修結帳頁與活動頁。

步驟三：撰寫符合告知義務的重新同意文案

個資法第 8 條要求蒐集時應明確告知蒐集者名稱、蒐集目的、個資類別、利用期間地區對象與方式、當事人權利與行使方式，以及不提供的影響（資料來源：全國法規資料庫，個人資料保護法第 8 條）。一封只寫「按此繼續收到優惠」的信，不符合告知義務。

最小可用文案骨架（放在 email 內文 + 落地頁，不要只放在超連結後面）：

1【蒐集機關】○○股份有限公司（統一編號 xxxxxxxx）
2【蒐集目的】行銷（代號 040）、消費者、客戶管理與服務（代號 090）
3【個資類別】C001 辨識個人者、C011 個人描述、C102 約定或契約
4【利用期間】自您同意之日起 3 年，或至您撤回同意時止
5【利用地區】台灣、香港、新加坡、澳洲（雲端服務所在地）
6【利用對象】本公司及本公司委外之電子郵件與雲端服務供應商
7【利用方式】以電子郵件、簡訊、網站個人化推薦方式進行
8【您的權利】得查詢、閱覽、複製、補充更正、請求停止蒐集處理利用或刪除
9【不同意之影響】不影響您既有訂單與售後服務，僅不再收到行銷訊息

特定目的代號請對照法務部公告的「個人資料保護法之特定目的及個人資料之類別」附表填寫，不要自創。若名單中含健康、醫療等個資法第 6 條特種個資（保健食品、醫美、寵物醫療電商常見），同意要求更嚴格，應個別處理並取得書面同意；依個資法施行細則第 14 條，書面意思表示得依電子簽章法以電子文件為之。

三個常見文案地雷

• 綁定條件。 「不同意行銷就無法查詢訂單」是無效同意。
• 一鍵全包。 把 email、SMS、跨品牌共享塞進同一個 checkbox，日後無法舉證各目的的同意。
• 預先勾選。 落地頁的 checkbox 預設不得為勾選狀態。

步驟四：用 double opt-in 執行重新取得同意

流程設計：寄出告知信 → 當事人點擊「我同意」→ 產生一次性 token 的落地頁 → 落地頁勾選各目的 → 送出 → 寫入 consent_events → 同步回 Shopify / Klaviyo。

落地頁後端（Node.js / Express）示意：

1import crypto from 'crypto';
2
3app.post('/reconsent/confirm', async (req, res) => {
4  const { token, purposes } = req.body;           // purposes: ['MKT_EMAIL','MKT_SMS']
5  const record = await db.tokens.findValid(token); // 未使用且未過期（建議 14 天）
6  if (!record) return res.status(410).json({ error: 'TOKEN_EXPIRED' });
7
8  const proof = crypto.createHash('sha256').update(token).digest('hex');
9  const now = new Date();
10
11  for (const purpose of purposes) {
12    await db.consentEvents.insert({
13      subject_hash: record.subjectHash,
14      email: record.email,
15      market: 'TW',
16      purpose_code: purpose,
17      event_type: 'GRANT',
18      legal_basis: 'PDPA_ART19_CONSENT',
19      notice_version: 'tw-2026-01',
20      policy_version: 'pp-2026-01',
21      collected_via: 'reconsent_email_doi',
22      ip_address: req.ip,
23      user_agent: req.get('user-agent'),
24      proof_token: proof,
25      occurred_at: now,
26    });
27  }
28  await db.tokens.consume(token);
29  res.json({ ok: true, granted: purposes });
30});

同步回 Shopify（Admin GraphQL API，注意 marketingOptInLevel 要標 CONFIRMED_OPT_IN，這是 double opt-in 的欄位語意）：

1mutation ReConsent($id: ID!, $at: DateTime!) {
2  customerEmailMarketingConsentUpdate(input: {
3    customerId: $id
4    emailMarketingConsent: {
5      marketingState: SUBSCRIBED
6      marketingOptInLevel: CONFIRMED_OPT_IN
7      consentUpdatedAt: $at
8    }
9  }) {
10    customer { id emailMarketingConsent { marketingState marketingOptInLevel } }
11    userErrors { field message }
12  }
13}

同步回 Klaviyo（Profile Subscription Bulk Create Job，記得帶 revision header）：

1curl -X POST https://a.klaviyo.com/api/profile-subscription-bulk-create-jobs/ \
2  -H "Authorization: Klaviyo-API-Key $KLAVIYO_PRIVATE_KEY" \
3  -H "revision: 2024-10-15" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "data": {
7      "type": "profile-subscription-bulk-create-job",
8      "attributes": {
9        "profiles": { "data": [{
10          "type": "profile",
11          "attributes": {
12            "email": "[email protected]",
13            "subscriptions": { "email": { "marketing": { "consent": "SUBSCRIBED" } } }
14          }
15        }] },
16        "historical_import": false
17      },
18      "relationships": { "list": { "data": { "type": "list", "id": "YOUR_LIST_ID" } } }
19    }
20  }'

預期輸出：Shopify 回傳 marketingOptInLevel: CONFIRMED_OPT_IN 且 userErrors 為空；Klaviyo 回 202 並可在 profile 上看到 consent timestamp。若你在做歷史資料回填（A 桶），historical_import 才設為 true，並且必須帶原始同意時間。

寄送節奏建議：分批（每日 10–20% 名單）、間隔 7 天最多提醒兩次、第二次提醒後未回應即停止。連續轟炸重新同意信本身就會製造申訴。

步驟五：把同意變成可稽核的證據鏈

合規的判準不是「我們有做」，而是「我們證明得出來」。至少要能在 24 小時內針對任一 email 產出：

• 同意時間（含時區）與來源頁面 URL
• 當時的告知文案版本全文（存快照，不要只存版本號）
• double opt-in token 的 hash 與確認 IP / User-Agent
• 後續所有變更事件（撤回、更新、到期）

實作上建議把 notice_version 對應的 HTML 快照存進物件儲存（S3 / GCS）並開啟版本控管與 object lock，避免行銷同事改文案時把歷史證據一起改掉。同意紀錄的保存期限應該長於名單使用期限，因為爭議通常發生在刪除之後。

步驟六：處理未回應名單的封存與刪除

個資法第 11 條第 3 項規定，個人資料蒐集之特定目的消失或期限屆滿時，應主動或依當事人請求刪除、停止處理或利用（資料來源：全國法規資料庫，個人資料保護法第 11 條）。所以未回應者不能永久躺在 CRM 裡當「以後再說」。

可執行的三段處置：

1. 抑制（suppression）。 未回應者移入 suppression list，僅保留 subject_hash 與抑制原因，確保不會被下次匯入洗回來。
2. 交易資料與行銷資料脫鉤。 訂單、發票、保固等基於契約與稅務法令保存的資料保留；行銷用的偏好、瀏覽軌跡、剖析標籤刪除。
3. 定期清理任務。 例如每季執行：

1-- 找出 36 個月未再同意、亦無有效契約關係的行銷資料
2SELECT c.subject_hash
3FROM consent_current c
4LEFT JOIN orders o ON o.subject_hash = c.subject_hash
5     AND o.created_at > NOW() - INTERVAL 60 MONTH
6WHERE c.purpose_code LIKE 'MKT_%'
7  AND c.event_type <> 'GRANT'
8  AND o.subject_hash IS NULL;

預期輸出：待刪除清單。先寫入 consent_events 一筆 EXPIRE 事件再刪除行銷欄位，才有「我們何時、依何規則刪除」的紀錄。

用 LLM 加速哪些環節，哪些不能交給它

舊名單合規最花人力的不是法律判斷，是文件考古。這部分適合自動化：

• 表單與政策版本比對。 把歷次隱私政策、結帳頁截圖丟給 LLM，要求輸出「每個版本涵蓋的特定目的清單 + 差異點」，人工只驗結論。
• 來源分類初判。 對數十份歷史 CSV 的欄位命名、備註欄做語意分群，產出分桶建議。
• 多語文案本地化。 同一份告知內容要生出台灣繁中、香港繁中、新加坡英文、澳洲英文版本；用 LLM 產草稿、當地法務審定稿。
• 申訴回覆草稿。 依 consent_events 查詢結果自動組出當事人權利行使回覆信。

不能交給 LLM 的：判斷某桶名單是否有合法事由、決定是否寄送、決定刪除。這些要有人具名簽核。實務上我們在一個同時營運台灣與東南亞市場的美妝零售集團專案裡，就是把 LLM 限制在「產出證據摘要與差異報告」的角色，分桶規則由法務確認後寫成 dbt model，讓判斷邏輯進版控、可回溯，而不是留在對話紀錄裡。

跨境營運的額外檢查點

個資法第 21 條允許中央目的事業主管機關在特定情形下限制個資國際傳輸，包括涉及國家重大利益或接受國對個資保護未有完善法規等情形（資料來源：全國法規資料庫，個人資料保護法第 21 條）。台灣過去已有針對特定產業限制傳輸至中國大陸的行政命令，因此若你的 CDP、客服系統或外包客服座席位於中國大陸，須個別確認。

對照歐盟：台灣目前並非歐盟認定的 adequacy 國家（歐盟執委會 adequacy 決定清單公布於歐盟執委會資料保護專頁），因此從 EU 傳資料到台灣營運中心，仍需 SCC 加 transfer impact assessment。反過來說，把 APAC 客服與資料營運放在台灣、香港或新加坡，並用同一套 consent schema 支撐多市場，是可行且常見的架構——差異在於各市場的 legal basis 標註，而不是重建系統。

多市場團隊實作建議：

• market 欄位驅動 legal basis 與保存期限，不要用不同資料表。
• 澳洲 Privacy Act 與 Spam Act 對 opt-out 的要求、新加坡 PDPA 的 DNC registry 檢核、香港 PDPO 第 VIA 部對直接促銷須事先取得不反對的規定，都可以掛在同一份同意模型上，用規則檔區分。
• 時區一律存 UTC，展示時再轉當地時間；跨時區的 consent timestamp 爭議比想像中常見。

疑難排解：最常撞到的六個問題

Shopify 回傳 userErrors: "marketingOptInLevel is invalid"

通常是把 marketingState 設為 NOT_SUBSCRIBED 卻同時給 CONFIRMED_OPT_IN，或是 API 版本過舊。確認使用的 Admin API 版本支援該欄位，並確保 state 與 level 語意一致。

Klaviyo 顯示已訂閱但實際未寄送

檢查該 profile 是否在 global suppression（曾標記 spam 或 hard bounce）。suppression 優先於 consent，這是正確行為，不要用 API 硬解——曾投訴者本來就不該再寄。

重新同意信投遞率崩掉

舊名單中常有大量已失效 email。先跑一次 email validation，剔除語法錯誤與已知無效網域，再分批寄送並監控 DMARC 報告。單日寄量暴衝是最常見的信譽殺手。

同一 email 有多筆衝突同意

這是 append-only 的正常現象，用 consent_current view 取最新事件即可。若同一秒有兩筆，加序號欄位做決勝，並回頭修前端的重複提交（加 idempotency key）。

客戶說「我從來沒同意過」但系統顯示有

調出 proof_token、IP、User-Agent 與告知快照。若證據不完整，務實作法是直接停止行銷並記錄 WITHDRAW——為一筆名單爭辯的代價遠高於失去一筆名單。

未回應者被下一次 CSV 匯入洗回來

在匯入管線加上強制 join suppression list 的檢查，並讓 CI 在缺少該檢查時擋下 pipeline 部署。這是流程問題，不是資料問題。

上線前檢查清單

1. 三桶分級規則已由具台灣執業資格的法律專業人員審閱並留存簽核紀錄。
2. 告知文案含蒐集者、目的代號、個資類別、期間地區對象方式、權利行使方式、不同意之影響。
3. 落地頁 checkbox 預設未勾選，且各目的可分別勾選。
4. 每封行銷信都有免費且一鍵可用的拒絕方式。
5. consent_events 為 append-only，且告知文案快照已開啟物件版本控管。
6. Shopify / Klaviyo / CDP 三邊 consent 狀態有每日對帳任務與差異告警。
7. suppression list 已接入所有匯入與寄送路徑。
8. 資料當事人權利請求（查詢、更正、刪除）有指定收件信箱與處理 SLA。
9. 委外處理者（email 平台、客服外包、雲端）契約含個資法第 27 條要求的安全維護與監督條款。
10. 跨境傳輸路徑（含客服座席所在地）已盤點並記錄。

這件事沒有捷徑：名單會變小。但一份 8 萬筆、有明確同意與完整證據的名單，在營運上比 40 萬筆來源不明的名單更值錢——投遞率、網域信譽、廣告平台的 customer match 品質都會反映這一點。

Branch8 以香港為總部，並在台灣、新加坡、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，協助 APAC、美國、英國與歐洲品牌把跨市場的同意管理、CDP 與電商後台整合成一套可稽核的資料流。如果你正在盤點台灣舊名單、或需要一套能同時對應台灣個資法、香港 PDPO、新加坡與澳洲要求的 consent 架構，歡迎與我們的團隊談談你的現況與時程。

Sources

• 全國法規資料庫 — 個人資料保護法
• 法務部 — 全國法規資料庫
• 個人資料保護委員會籌備處
• 立法院 — 法律案審議資訊
• 經濟部 — 統計資訊
• GDPR-Info — Article 83 GDPR: General conditions for imposing administrative fines
• European Commission — Data protection: adequacy decisions
• Shopify.dev — Admin GraphQL API reference
• Klaviyo Developers — API documentation