隱私權政策與 Cookie 同意怎麼做？台灣個資法、GDPR 與實作範本

三年前我幫一個做手作皂的客戶架站，交件前她問我：「隱私權政策要放嗎？」我當時的回答是「放一下比較保險，我去別的網站複製一份改改」。那份東西上線了兩年，寫著「本公司」——但她根本沒有公司，是個人接案；寫著「客服專線」——那支電話是我隨手貼的範本殘留，打過去是空號。直到她要接一個歐洲的訂單，對方法務把那頁調出來看，我才知道自己當年交的不是一份文件，是一顆定時炸彈。

後來我把台灣隱私權政策這件事重新從法條讀起，才發現中文圈流傳的說法錯得比我想像的離譜。最常見的兩個誤解是：「台灣沒有個資法可以不用寫」和「台灣網站也要做 Cookie 同意橫幅，不然會被罰」。前者少了一整條法定告知義務，後者則是把歐盟的規則整包搬過來，還搬錯了法源——歐盟的 Cookie 同意根本不是 GDPR 規定的。

這篇文章是我把個人資料保護法、施行細則、GDPR、ePrivacy 指令，以及 Google 與 Meta 官方條款一條一條讀完之後整理出來的實作筆記。所有法條我都用全國法規資料庫逐字比對過，而且特別確認過「哪一版是現行有效的」——這件事在 2026 年變得非常重要，因為個資法有一大批條文已經公布但還沒施行，網路上有些新文章已經開始拿還沒生效的條文當現行法在講。查核日是 2026 年 8 月 6 日。

先講結論：台灣網站需要隱私權政策，但理由不是「別人都有」

我看過太多站長把隱私權政策當成「網站的標準配件」，跟 favicon 一樣，有就好。這個心態會讓你寫出一份完全無效的文件，因為你不知道它到底在滿足什麼要求，自然也不知道少寫了什麼。

台灣網站需要隱私權政策的真正法源，是個人資料保護法第 8 條的告知義務。這條的邏輯是：只要你（非公務機關）依第 19 條向當事人蒐集個人資料，你就「應明確告知」六件事。以下是全國法規資料庫的現行條文，逐字引用：

公務機關或非公務機關依第十五條或第十九條規定向當事人蒐集個人資料時，應明確告知當事人下列事項：
一、公務機關或非公務機關名稱。
二、蒐集之目的。
三、個人資料之類別。
四、個人資料利用之期間、地區、對象及方式。
五、當事人依第三條規定得行使之權利及方式。
六、當事人得自由選擇提供個人資料時，不提供將對其權益之影響。

請注意這裡的用字是「應明確告知」，不是「宜」也不是「得」。而且它是六款列舉，不是概括規定——你的隱私權政策要是漏了「利用之期間、地區、對象及方式」，那就是漏了法定應告知事項的一整款。

第 8 條第 2 項確實有六種得免告知的情形，其中跟一般網站比較有關的是第 6 款「個人資料之蒐集非基於營利之目的，且對當事人顯無不利之影響」。但要注意這是「且」——兩個要件都要成立。你的部落格只要掛了聯盟行銷連結或廣告，「非基於營利之目的」這個要件就很難主張。我自己的判斷是：只要網站有任何變現行為，就不要指望免告知例外。

另一半：你憑什麼可以蒐集？第 19 條的八款事由

告知義務解決的是「你有沒有講清楚」，第 19 條解決的是「你有沒有資格蒐集」。條文開頭寫的是「非公務機關對個人資料之蒐集或處理，除第六條第一項所規定資料外，應有特定目的，並符合下列情形之一者」，然後列了八款。對一般網站來說，實際會用到的通常是這三款：

第 19 條第 1 項款次	條文用語（逐字）	典型網站情境
第二款	與當事人有契約或類似契約之關係，且已採取適當之安全措施	電商訂單、接案簽約、付費會員
第五款	經當事人同意	電子報訂閱、活動報名、問卷
第八款	對當事人權益無侵害	純瀏覽統計、不回推到個人的彙總數據

資料來源：全國法規資料庫「個人資料保護法」第 19 條現行條文，查核日 2026-08-06。

這裡有個很多人忽略的細節：第 19 條第 1 項第 2 款的「與當事人有契約或類似契約之關係」後面還接了「且已採取適當之安全措施」。也就是說，如果你靠契約關係蒐集客戶資料，安全措施不是加分項，是這款事由能不能成立的條件之一。我在WordPress 網站安全的基本功那篇寫過的登入防護與更新策略，在這裡就從「技術習慣」升格成「法律要件」了。

「同意」在個資法裡是什麼？第 7 條的推定同意條款

個資法第 7 條對「同意」下了定義，而且第 3 項有一個對網站經營者非常關鍵的推定規定：

公務機關或非公務機關明確告知當事人第八條第一項各款應告知事項時，當事人如未表示拒絕，並已提供其個人資料者，推定當事人已依第十五條第二款、第十九條第一項第五款之規定表示同意。

這一段就是台灣和歐盟最根本的分歧點。台灣現行法允許「明確告知＋未表示拒絕＋已提供資料」推定為同意，而 GDPR 第 4 條第 11 款要求的是「clear affirmative action」——明確的肯定行為，預設勾選和沉默都不算。這個差異一路影響到後面 Cookie 橫幅該不該做、要怎麼做。

但第 7 條第 4 項也提醒你別得意太早：「蒐集者就本法所稱經當事人同意之事實，應負舉證責任。」舉證責任在你身上。所以就算法律允許推定同意，你還是要留得下「我確實有明確告知」的證據——這也是為什麼隱私權政策的版本沿革與生效日期值得認真標注。關於電子紀錄的證明力，我在談電子簽章法的那篇整理過同樣的邏輯：留存方式決定舉證強度。

動筆之前：你的網站到底蒐集了哪些個資？

我看過的爛隱私權政策有一個共同特徵：作者從來沒有真的盤點過自己的網站在收什麼。他們是先找到一份範本，再去想「這條我好像也有吧」。順序反了。正確做法是先盤點，再照盤點結果寫。

個資法第 2 條第 1 款對「個人資料」的定義是列舉加概括，範圍比多數人想的寬：

個人資料：指自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動及其他得以直接或間接方式識別該個人之資料。

結尾那句「及其他得以直接或間接方式識別該個人之資料」才是重點。「間接方式識別」意味著單獨看起來不像個資的欄位，只要能跟其他資料組合起來指向特定的人，就落入定義。這正是 Cookie ID、裝置指紋、IP 位址在台灣法下該怎麼看待的關鍵。

一份自架站的實際盤點清單

下面是我幫自己站台盤點時實際用的表。每一列都要能回答「這個東西存在哪裡、存多久、誰看得到」。

來源	可能取得的資料	是否落入個資法定義	常被漏掉的地方
聯絡表單外掛	姓名、Email、電話、留言內容	是（姓名、聯絡方式為第 2 條列舉）	多數表單外掛預設把送出的信件副本存進資料庫，站長以為只是寄信
文章留言	暱稱、Email、網站、IP、User Agent	是（IP 屬間接識別）	WordPress 原生留言功能預設就會記錄留言者 IP
電子報訂閱	Email、開信與點擊行為	是	開信追蹤像素本身就是行為紀錄，不只是名單
會員／登入	帳號、密碼雜湊、登入時間與 IP	是	密碼雜湊不是個資，但「誰在何時從哪裡登入」是
電商結帳	收件姓名、地址、電話、部分金流回傳欄位	是（含 C002 辨識財務者）	金流商回傳的授權碼與卡號末四碼會存在訂單備註
Google Analytics 4	Cookie ID、事件、粗略地理位置	視情況，Cookie ID 屬間接識別	綁定 Google 訊號後會加入跨裝置資料
Meta Pixel	瀏覽事件、轉換事件、可能的進階配對雜湊	是	進階配對若開啟，會把 Email 雜湊後送出
網站主機存取紀錄	IP、時間、請求路徑	是（間接識別）	幾乎沒有人在隱私權政策裡寫過伺服器日誌

說明：「是否落入個資法定義」欄位依個資法第 2 條第 1 款判斷，查核日 2026-08-06。GA4 的資料項目依 Google 官方說明整理，Meta Pixel 依 Meta Business Tools Terms（生效日 2025 年 11 月 3 日）整理。

盤點做完你會發現，一個「只是寫文章」的部落格，實際上至少有四到五條個資蒐集管道。如果你的站也跟我一樣曾經外掛裝到失控，這一步會特別痛——我在把網站外掛精簡到 11 支的取捨清單裡列的每一支外掛，當時我是用「會不會拖慢網站」在篩，現在回頭看，「會不會多開一條個資管道」應該是同等重要的判準。

電商與電子報是兩個最容易低估的坑

電商的資料種類最雜。除了訂單本身，退換貨紀錄、發票資訊、客服對話都是。如果你跑的是 WooCommerce，我在WooCommerce 開店流程那篇提過金流與物流各自要串接哪些服務——每一個串接的對象，在隱私權政策裡都是「利用之對象」，都要寫出來。

電子報則是「利用期間」最容易寫錯的地方。很多人寫「保存至本公司結束營業為止」，這在個資法第 11 條第 3 項下是有問題的：「個人資料蒐集之特定目的消失或期限屆滿時，應主動或依當事人之請求，刪除、停止處理或利用該個人資料。但因執行職務或業務所必須或經當事人書面同意者，不在此限。」訂閱者退訂那一刻，「行銷」這個特定目的就消失了，你就有主動刪除或停止處理利用的義務——除非你落得進後面那個但書。但書不是萬用免死金牌：施行細則第 21 條把「因執行職務或業務所必須」限縮成三款，分別是「有法令規定或契約約定之保存期限」「有理由足認刪除將侵害當事人值得保護之利益」與「其他不能刪除之正當事由」。電商訂單有稅法上的憑證保存期限，可以靠第一款；一份純粹的電子報名單通常什麼保存義務都沒有，退訂後還留著就很難撐得住。關於名單品質與退訂率，可以參考我寫的電子報訂閱名單從 0 到 1000 的實作紀錄，以及電子報行銷入門的名單建立流程。

隱私權政策裡「法律上必須寫」的六件事，一款一款拆

把第 8 條的六款翻成實作語言，就是下面這張表。我把每一款會被漏掉的細節也標出來了。

第 8 條第 1 項款次	法定用語	實務上要寫成什麼
一	公務機關或非公務機關名稱	你的正式名稱。個人接案就寫本名或工作室名稱，不要憑空寫「本公司」
二	蒐集之目的	建議直接對應法務部公告的特定目的代號，例如 040 行銷、090 消費者、客戶管理與服務
三	個人資料之類別	同樣對應公告的類別代號，例如 C001 辨識個人者、C002 辨識財務者
四	個人資料利用之期間、地區、對象及方式	四個子項都要有。「地區」尤其重要，用 GA4 就等於資料出境
五	當事人依第三條規定得行使之權利及方式	五種權利要列全，而且要寫「方式」——一個可用的聯絡管道
六	當事人得自由選擇提供個人資料時，不提供將對其權益之影響	例如「不填 Email 就無法收到訂單通知」，要具體

資料來源：全國法規資料庫「個人資料保護法」第 8 條現行條文；特定目的與資料類別代號依法務部公告「個人資料保護法之特定目的及個人資料之類別」（民國 101 年 10 月 1 日修正），查核日 2026-08-06。

用官方代號寫「蒐集目的」與「資料類別」，是免費的專業度

這份代號表的授權依據是個資法第 53 條。現行有效條文逐字是：「法務部應會同中央目的事業主管機關訂定特定目的及個人資料類別，提供公務機關及非公務機關參考使用。」請注意主體是法務部，不是個資會——第 53 條也在民國 114 年 11 月 11 日那批尚未施行的修正清單裡。這份公告目前掛在個人資料保護委員會籌備處的主管法規系統上，名稱是「個人資料保護法之特定目的及個人資料之類別」，發布日期民國 85 年 8 月 7 日、最近一次修正民國 101 年 10 月 1 日。

直接引用官方代號有兩個好處：一是你的「特定目的」不會寫得含糊到失去限縮功能，二是主管機關看得懂。對自架站與接案者來說，最常用得到的是這幾組：

特定目的代號	名稱（逐字）	什麼情況會用到
040	行銷（包含金控共同行銷業務）	電子報、再行銷廣告、活動通知
069	契約、類似契約或其他法律關係事務	接案合約、報價、驗收往來
090	消費者、客戶管理與服務	客服信箱、售後支援、客戶名單
136	資（通）訊與資料庫管理	會員系統、網站後台帳號管理
148	網路購物及其他電子商務服務	電商訂單、線上課程販售
152	廣告或商業行為管理	投放廣告、聯盟行銷追蹤
157	調查、統計與研究分析	網站流量分析、問卷調查

資料來源：個人資料保護委員會籌備處主管法規共用系統「個人資料保護法之特定目的及個人資料之類別」，查核日 2026-08-06。

資料類別的部分，一般網站最常涉及的是 C001 辨識個人者（姓名、住址、電子郵遞地址等）、C002 辨識財務者（金融機構帳戶、信用卡號碼等）、C003 政府資料中之辨識者（身分證統一編號、稅籍編號等）、C011 個人描述（年齡、性別、出生年月日等）。如果你的網站根本不收身分證字號，就不要把 C003 抄進去——抄多了不是保險，是自找麻煩。

「利用之地區」是最常被整段跳過的一款

我看過的中文範本裡，「地區」這一款十有八九被寫成「本公司所在地」就結束了。但實際上只要你裝了 GA4、用了 Meta Pixel、把網站放在海外主機、或用了美國的電子報服務，你的資料利用地區就包含境外。

個資法第 21 條確實給了中央目的事業主管機關限制國際傳輸的權力（條文寫的是「非公務機關為國際傳輸個人資料，而有下列情形之一者，中央目的事業主管機關得限制之」），但那是限制的權力，不代表沒有限制命令就不用告知——第 8 條第 1 項第 4 款的告知義務是獨立的。務實的寫法是誠實列出你實際會把資料送到哪些服務商，以及它們的資料處理地區。如果你正在選主機，我在WordPress 虛擬主機的比較文裡列的每一家，機房位置都會影響這一欄怎麼寫；共享、VPS 與託管型主機的取捨那篇也提過託管型主機通常會有自己的備份異地存放地點，那同樣算是利用地區。

當事人的五項權利，和你必須真的提供的行使方式

個資法第 3 條列了五項當事人權利，而且開宗明義寫著這些權利「不得預先拋棄或以特約限制之」：

當事人就其個人資料依本法規定行使之下列權利，不得預先拋棄或以特約限制之：
一、查詢或請求閱覽。
二、請求製給複製本。
三、請求補充或更正。
四、請求停止蒐集、處理或利用。
五、請求刪除。

「不得預先拋棄或以特約限制之」這十四個字，直接讓一大類常見的服務條款寫法無效。你不能在會員條款裡寫「使用者同意放棄查詢與刪除權」，寫了也不生效。

第 8 條第 1 項第 5 款要求你告知的是「得行使之權利及方式」。方式的部分不能只寫「請來信」——你得給一個真的有人看的信箱，而且最好說明你會在多久內回應。個資法第 13 條有處理期限規定，但那是講收到請求後的處理時限，不是講你要不要提供管道。

費用可以收，但有條件

第 14 條規定查詢或製給複製本「得酌收必要成本費用」。注意是「必要成本」，不是隨你開價，而且只限於查詢與複製本這兩項——更正、停止處理利用、刪除都不能收費。這點在範本裡幾乎沒人寫對。

更正與刪除的實作面：你有沒有能力真的刪掉？

第 11 條第 3 項規定特定目的消失或期限屆滿時要主動或依請求刪除（但書留了「因執行職務或業務所必須或經當事人書面同意」的例外，範圍見施行細則第 21 條）。問題是，很多站長根本不知道自己有幾份備份、備份裡有沒有那筆資料。如果你有異地備份，一個「刪除」請求其實牽涉到正式資料庫、主機端快照、以及你自己下載的備份檔三個地方。這也是我在三層備份策略那篇裡沒有講到的一面：備份留得越多，刪除義務越難落實。誠實的做法是在政策裡寫清楚備份輪替週期，例如「備份保留 N 天後自動覆寫」，讓對方知道最遲什麼時候會真正消失。

安全維護措施：施行細則第 12 條給了一份現成的檢查表

個資法第 27 條第 1 項（現行有效版本）規定：「非公務機關保有個人資料檔案者，應採行適當之安全措施，防止個人資料被竊取、竄改、毀損、滅失或洩漏。」什麼叫「適當之安全措施」？母法沒有講，但個人資料保護法施行細則第 12 條講了——這是引用施行細則時一定要指名母法的典型例子。

施行細則第 12 條第 1 項先給定義：「指公務機關或非公務機關為防止個人資料被竊取、竄改、毀損、滅失或洩漏，採取技術上及組織上之措施」，第 2 項再列出十一項可包括的事項，並要求「以與所欲達成之個人資料保護目的間，具有適當比例為原則」。這十一項是：配置管理之人員及相當資源、界定個人資料之範圍、個人資料之風險評估及管理機制、事故之預防通報及應變機制、個人資料蒐集處理及利用之內部管理程序、資料安全管理及人員管理、認知宣導及教育訓練、設備安全管理、資料安全稽核機制、使用紀錄軌跡資料及證據保存、個人資料安全維護之整體持續改善。

對一人網站來說，「適當比例」這四個字是你的救命條款——你不需要真的設個資保護長，但「資料安全管理及人員管理」對你來說至少意味著：後台帳號密碼不共用、外包廠商拿到的權限用完就撤。我在密碼管理器與客戶帳密交接那篇寫的離場撤銷流程，其實就是這一項的最小可行版本。如果你手上有客戶名單要管，接案者的客戶管理與個資責任那篇談的最小可用 CRM 也是同一個思路。

GA4、Meta Pixel、AdSense 各自把哪些義務推回給你

這一節是我認為最多站長吃虧的地方。你以為裝一段追蹤碼只是技術動作，但每一段追蹤碼背後都有一份你已經按下「同意」的合約，而那份合約通常把告知與取得同意的責任推給你。

Google：EU 使用者同意政策

Google 的「EU user consent policy」適用範圍是歐洲經濟區、英國與瑞士。它要求發布商必須就下列事項取得合法有效的同意：「the use of cookies or other local storage where legally required」以及「the collection, sharing, and use of personal data for personalization of ads」。

除了取得同意，這份政策還要求你「clearly identify each party that may collect, receive, or use end users’ personal data」，並且要「retain records of consent given by end users」（保留使用者同意的紀錄），以及「provide end users with clear instructions for revocation of consent」（提供撤回同意的清楚說明）。

換句話說，只要你的網站有歐洲流量而且掛了 Google 的廣告或分析產品，「保留同意紀錄」與「提供撤回方式」就是你的契約義務，不是選配。

AdSense：EEA 與英國流量需要 Google 認證的 CMP

Google 官方說明寫得很直接：「As of 16 January 2024, a certified CMP integrated with the TCF is required when serving personalized ads to users in the EEA and UK.」瑞士的對應要求則從 2024 年 7 月 31 日起適用。

這裡有兩個常被誤解的點。第一，這個要求限於 EEA 與英國（瑞士另有期日），不是全球；台灣流量不在其中。第二，沒有裝認證 CMP 不等於不能放廣告——Google 的說明是非認證 CMP 來的流量只能投放非個人化或有限廣告。所以對一個台灣流量為主、歐洲流量零星的部落格，這是收入取捨問題，不是合法性問題。

Meta：Business Tools Terms 把通知與同意義務寫進條款

Meta 的 Business Tools Terms（頁面顯示的生效日為 2025 年 11 月 3 日）對使用 Pixel 的網站要求的其實是三件事，以下是英文版原文逐字引用：

For websites, a clear and prominent notice on each web page where our pixels are used that links to a clear explanation (a) that you may use pixels, web beacons, and other storage technologies from third parties, including Meta, to collect or receive information from your websites and elsewhere on the Internet and third parties, including Meta, use that information to provide measurement services, target and deliver ads, (b) how users can opt-out of the collection and use of information for ad targeting, and (c) where a user can access a mechanism for exercising such choice.

(b) 和 (c) 是中文範本裡最常被整段漏掉的兩項。大部分人只寫了 (a) 那句「本網站使用 Meta 像素」的說明，既沒有告訴使用者怎麼退出廣告定向，也沒有指出一個真的能操作的管道。照 Meta 自己的條款，缺這兩項就等於通知義務沒做完。

同意的部分寫在另一段，同樣逐字引用：

In jurisdictions that require informed consent for storing and accessing cookies or other information on an end user’s device (such as but not limited to the European Union), you must ensure, in a verifiable manner, that an end user provides all necessary consents before you use Meta Business Tools to enable the storage of and access to Meta cookies or other information on the end user’s device.

注意這兩段的結構差異：通知義務綁的是「每一個放了像素的網頁」，不分地區；同意義務才限於「有知情同意規定的管轄區」，而且要求你以「可驗證的方式」（in a verifiable manner）確認同意是在像素開始運作之前取得的。這個結構跟台灣法的邏輯其實剛好吻合：台灣要求你告知，不要求你取得橫幅式同意——但 Meta 的合約仍然要求你在每一個掛了像素的頁面上放通知。

GA4 的 IP 位址：Google 說它不記錄也不儲存

這是一個我自己踩過的坑。Universal Analytics 時代大家在討論的「IP 匿名化」設定，在 GA4 已經沒有意義。Google 官方說明的原文是：「In Google Analytics, IP masking is not necessary since IP addresses are not logged or stored.」

所以如果你的隱私權政策還寫著「我們已啟用 Google Analytics 的 IP 匿名化功能」，那是一句在 GA4 下不成立的話。把它改成描述 GA4 實際的資料處理方式才對。GA4 的安裝與報表判讀我另外寫過一篇新手教學，可以搭配著看你到底開了哪些資料收集選項。順帶一提，Search Console 給的是彙總後的查詢數據、不是個別使用者資料，這一項在政策裡通常不需要單獨列出。

同意模式（Consent Mode）：它是訊號機制，不是同意本身

同意模式的作用，是讓 Google 標記依照使用者的同意狀態調整自己的行為。Google 標記平台的設定文件逐字寫著：「Consent mode was updated in November, 2023 and now contains two additional parameters.」新增的兩個參數是 `ad_user_data`（文件說明為 Sets consent for sending user data related to advertising to Google）與 `ad_personalization`（Sets consent for personalized advertising），加上原有的 `ad_storage` 與 `analytics_storage`，一共四個。

順帶處理一個流傳很廣的說法：中文文章常寫「同意模式 v2 自 2024 年 3 月起強制」。我在查核日把 Google 的同意模式設定文件與 Google Ads 說明中心的 EEA 同意模式更新頁都讀過一遍，兩邊都沒有寫出一個官方標明的強制生效日，只有「強化 EU 使用者同意政策執行」這類敘述。真正有明確日期的是下面 AdSense 那一段的認證 CMP 要求。要把日期寫進客戶的簡報或政策之前，請以官方頁面當日的文字為準。

要講清楚的是：同意模式只是把「使用者選了什麼」這件事傳給 Google 的機制，它本身不會幫你取得同意。取得同意是 CMP 或你自己的介面要做的事。我看過有人在政策裡寫「本站已啟用 Google 同意模式，符合法規要求」——這句話兩個部分都站不住腳。

工具	官方把什麼義務推給網站方	適用範圍	出處
Google 廣告與分析產品	取得同意、揭露每一個會取得資料的對象、保留同意紀錄、提供撤回方式	EEA、英國、瑞士	Google EU user consent policy
AdSense 個人化廣告	使用 Google 認證且整合 TCF 的 CMP	EEA 與英國自 2024-01-16；瑞士自 2024-07-31	Google AdSense 說明中心
Meta Pixel	每個掛了像素的網頁提供明顯通知與說明連結，並說明退出方式與可操作管道；在有知情同意規定的管轄區，須以可驗證方式先取得同意	通知義務不限地區；同意義務限有規定之管轄區	Meta Business Tools Terms（2025-11-03 生效）
Google Analytics 4	—（IP 位址不記錄、不儲存，故無需 IP 匿名化設定）	全球	Google Analytics 說明中心

說明：以上為各服務官方文件於查核日 2026-08-06 的記載，條款可能隨時更新，實作前請以當日官方頁面為準。

Cookie 同意在台灣的法律地位：和歐盟差在哪裡

這一節是我寫這篇文章最主要的動機。中文圈流傳最廣的錯誤說法有兩個：一是「台灣也要做 Cookie 同意橫幅，不然違反個資法」，二是「歐盟的 Cookie 同意是 GDPR 規定的」。兩個都不對。

先看事實：台灣現行法規裡找不到「Cookie」

我在查核日直接抓了個人資料保護法與個人資料保護法施行細則的全文，用程式搜尋「Cookie」與「cookie」。結果是：兩部法規的條文本體都沒有出現這個詞（頁面原始碼裡搜到的兩筆是全國法規資料庫網站自己的 JavaScript 檔名與 Google Analytics 設定，不是條文內容）。

這代表什麼？代表台灣沒有一部法律像歐盟那樣，把「在使用者終端裝置上存取資訊」單獨拉出來當成一個需要事前同意的行為。台灣的路徑是回到個資法本身：如果你用 Cookie 蒐集到的東西構成第 2 條定義的個人資料（包括「間接方式識別」），那就適用第 19 條的合法事由與第 8 條的告知義務；如果沒有構成個人資料（例如純粹記住語言偏好的功能性 Cookie），個資法根本不管。

歐盟為什麼要同意？法源是 ePrivacy 指令，不是 GDPR

歐盟 Cookie 同意的真正法源是 Directive 2002/58/EC（隱私與電子通訊指令），經 Directive 2009/136/EC 修正後的第 5 條第 3 項。以下是 EUR-Lex 合併版（合併日期 2009 年 12 月 19 日）的原文：

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

三個關鍵差異就藏在這段裡：

第一，規範對象是「儲存資訊或取用已儲存資訊」本身，不論那份資訊是不是個人資料。這就是為什麼歐盟連不涉及個資的追蹤技術也要同意，而台灣不會。

第二，只有兩種豁免：純粹為傳輸通訊所必要，或為提供使用者明確要求的服務所嚴格必要。「strictly necessary」這個字很硬——分析用 Cookie 一般不被認為落在這個豁免裡。

第三，同意的品質標準要回頭看 GDPR。指令原文寫的是「in accordance with Directive 95/46/EC」，而 95/46/EC 已經被 GDPR 取代，所以現在實際適用的是 GDPR 第 4 條第 11 款的定義：「any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her」。

GDPR 第 7 條第 3 項還加上了撤回的要求：「The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent.」最後那句「撤回要跟給予一樣容易」，就是「只有『全部接受』沒有『全部拒絕』按鈕」這種設計被歐洲各國主管機關開罰的依據。

那台灣的政府網站在做什麼？告知式，不是同意式

要理解台灣目前的實務標準，最直接的參照就是政府網站自己怎麼寫。我查了全國法規資料庫本身的隱私權保護政策，它的「Cookie 之使用」一節寫的是：

為了提供您最佳的服務，本網站會在您的電腦中放置並取用我們的Cookie，若您不願接受Cookie的寫入，您可在您使用的瀏覽器功能項中設定隱私權等級為高，即可拒絕Cookie的寫入，但可能會導至網站某些功能無法正常執行

請注意這段話的結構：先告知會寫入 Cookie，再告訴你可以用瀏覽器設定拒絕。它沒有任何「請按同意」的動作要求。這就是台灣現行的告知式做法。同一份政策的章節結構也很值得抄：隱私權保護政策的適用範圍、個人資料的蒐集處理及利用方式、資料之保護、網站對外的相關連結、與第三人共用個人資料之政策、Cookie 之使用、隱私權保護政策之修正。

台灣 vs 歐盟：一張表看完

面向	台灣（個資法）	歐盟（ePrivacy 指令＋GDPR）
Cookie 是否有專門條文	無。個資法與施行細則全文均未出現該詞	有。Directive 2002/58/EC 第 5 條第 3 項
規範觸發點	只有當蒐集到的資料構成個人資料時才適用	只要在終端裝置儲存或取用資訊即適用，不論是否為個資
對使用者的基本要求	告知（第 8 條「應明確告知」六款）	同意（事前、知情、明確肯定行為）
沉默算不算同意	第 7 條第 3 項有推定同意規定：明確告知後未表示拒絕並已提供資料者，推定同意	不算。GDPR 第 4 條第 11 款要求 clear affirmative action
撤回的要求	個資法第 3 條第 4 款有請求停止處理利用的權利	GDPR 第 7 條第 3 項：撤回應與給予同樣容易
是否需要橫幅	法律未強制；用政策頁面告知即可	實務上需要，且須提供有效的拒絕途徑

資料來源：全國法規資料庫個人資料保護法第 3、7、8 條現行條文；EUR-Lex Directive 2002/58/EC 合併版第 5 條第 3 項；EUR-Lex Regulation (EU) 2016/679 第 4 條第 11 款與第 7 條。查核日 2026-08-06。

那我到底該不該做橫幅？我的實際判斷

我的建議是：台灣流量為主的網站，把力氣放在把隱私權政策寫對，而不是急著加一個攔路的橫幅。理由有三個。第一，法律沒要求，橫幅換不到合規性。第二，橫幅是 Core Web Vitals 的重災區，後面會講。第三，做半套的橫幅比不做更糟——如果你放了一個「同意」按鈕但不管使用者按不按都照樣載入追蹤碼，那不只是無效，還是明確的誤導。

但如果你有以下任一情況，橫幅就從「可選」變成「該做」：網站對歐洲使用者提供服務、你的 AdSense 收入有明顯比例來自歐洲、或你的客戶是歐洲企業而他們的法務會來看。第三種情況在接案圈越來越常見，我在台灣接案者服務歐美客戶的實戰指南裡談過對方的內部流程通常比我們想的嚴格。

什麼時候台灣網站會被 GDPR 打到？看 Article 3(2) 的兩個要件

先破除一個都市傳說：「網站在歐洲連得上就要遵守 GDPR」是錯的。這句話在 GDPR 的官方立法理由書裡被明文否定了。

GDPR 第 3 條（Territorial scope）第 2 項的原文是：「This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union.」

(a) 款中間那句「irrespective of whether a payment of the data subject is required」常在中文轉述時被省略，但它對內容站特別重要：免費提供的東西一樣算「offering of goods or services」，你沒跟讀者收錢，不影響這一款的判斷。

要件一：你是否「預期」向歐盟境內的人提供商品或服務

Recital 23 是判斷標準。歐洲資料保護委員會（EDPB）在《Guidelines 3/2018 on the territorial scope of the GDPR》裡引用的原文是：

whereas the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.

翻成白話：網站在歐盟看得到、有一個 Email、用你自己國家的語言寫——這三件事都不足以認定你在鎖定歐盟。但如果你用了某個歐盟會員國常用的語言或貨幣，而且可以用那個語言下單，或者你在網站上列出歐盟的客戶，那就可能被認定為「預期」向歐盟提供服務。

EDPB 還特別強調：「the fact of processing personal data of an individual in the Union alone is not sufficient to trigger the application of the GDPR… The element of “targeting” individuals in the EU, either by offering goods or services to them or by monitoring their behaviour… must always be present in addition.」

這對要不要做多語系網站是個直接的提醒：你多開一個德文版、開始收歐元，就等於主動把自己拉進 GDPR 的射程。這不是不能做，但要知道代價，而且要一併把 GDPR 的告知義務（第 13 條）做起來。

要件二：你是否監控歐盟境內的行為

這一項對部落格與內容站更致命，因為它不需要你有任何「鎖定意圖」。Recital 24 說判斷標準是「whether natural persons are tracked on the internet including potential subsequent use of personal data processing techniques which consist of profiling a natural person, particularly in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences, behaviours and attitudes.」

EDPB 明確列出可能構成監控的活動，其中前三項就打中一般網站：

• Behavioural advertisement（行為式廣告）
• Geo-localisation activities, in particular for marketing purposes（地理定位，尤其用於行銷目的）
• Online tracking through the use of cookies or other tracking techniques such as fingerprinting（透過 Cookie 或指紋等追蹤技術進行線上追蹤）

不過 EDPB 也留了餘地：「The EDPB does not consider that any online collection or analysis of personal data of individuals in the EU would automatically count as ‘monitoring’. It will be necessary to consider the controller’s purpose for processing the data and, in particular, any subsequent behavioural analysis or profiling techniques involving that data.」關鍵在於你有沒有把資料拿去做後續的行為分析或剖析。

情境	是否落入 GDPR Article 3(2)	依據
純中文部落格，只有 GA4，偶爾有歐洲讀者	鎖定要件不成立；監控要件視你有無做行為分析而定，風險偏低	Recital 23（單純可連線不足）＋ EDPB 對「監控」須有特定目的之說明
加開英文／德文版並可用歐元結帳	很可能成立（鎖定）	Recital 23 明列語言、貨幣與可下單能力
在網站上列出歐盟客戶名單或案例	可能成立（鎖定）	Recital 23「mentioning of customers or users who are in the Union」
投放行為式再行銷廣告給歐盟使用者	成立（監控）	EDPB 監控活動清單第一項
用 Cookie 或指紋技術做線上追蹤與剖析	成立（監控）	EDPB 監控活動清單第三項

資料來源：EUR-Lex Regulation (EU) 2016/679 第 3 條與 Recital 23、24；EDPB Guidelines 3/2018 on the territorial scope of the GDPR。查核日 2026-08-06。

如果真的被 GDPR 涵蓋，還有一個代表人義務

EDPB 指引提到，落入 Article 3(2) 的控管者依 GDPR 第 27 條原則上須在歐盟境內指定代表人。這對一人網站是一筆實際成本，也是我認為「不要為了流量隨便開歐盟市場」的主要理由。順帶一提，台灣個資法自己也有域外效力——第 51 條第 2 項規定：「公務機關及非公務機關，在中華民國領域外對中華民國人民個人資料蒐集、處理或利用者，亦適用本法。」邏輯跟 GDPR 是同一套。

2026 年這三個「還沒生效」的變動，千萬別寫進你的政策

這是我認為這篇文章最有價值、也最容易被寫錯的一節。個人資料保護法目前處於「已公布但大部分修正條文尚未施行」的狀態，全國法規資料庫的頁面上會直接標示：「※本法規部分或全部條文尚未生效，最後生效日期：未定」。

變動一：民國 114 年 11 月 11 日的大修正，尚未施行

全國法規資料庫記載的施行註記逐字是：「一百十四年十一月十一日修正第 1-1、12、18、21、22～26、41、47～49、52、53、55 條條文；增訂第 1-2、20-1、21-1～21-5、51-1、53-1 條條文及第三章之一章名、第一節節名、第二節節名；刪除第 27 條條文，施行日期，由行政院定之。」

「施行日期，由行政院定之」而且生效狀態欄標示「未定」，就代表截至查核日 2026 年 8 月 6 日，這批條文全部還沒生效。這裡有幾個陷阱：

• 第 27 條被刪除，但目前仍有效。如果你去全國法規資料庫的條文頁看第 27 條，看到的是「（刪除）」——那是還沒施行的版本。現行有效的是民國 112 年 5 月 31 日版：「非公務機關保有個人資料檔案者，應採行適當之安全措施，防止個人資料被竊取、竄改、毀損、滅失或洩漏。」
• 第 20-1 條（新的安全維護義務）目前不存在。它是增訂條文，現行法裡查無此條，不得引用為現行法。
• 第 12 條的資料外洩通報制度還是舊版。現行有效的第 12 條只有一句：「公務機關或非公務機關違反本法規定，致個人資料被竊取、洩漏、竄改或其他侵害者，應查明後以適當方式通知當事人。」新版增加的「向主管機關通報」與「保存相關紀錄以備查驗」等義務尚未生效。

變動二：個人資料保護委員會目前仍是籌備處

個資法第 1-1 條的內容只有一句：「本法之主管機關為個人資料保護委員會。」但這條是民國 112 年 5 月 31 日增訂、民國 114 年 11 月 11 日又修正過一次，兩次的施行註記都是「施行日期，由行政院定之」；而全國法規資料庫再往前一版的舊條文（民國 104 年 12 月 30 日版）中查無此條。換句話說，現行法沒有第 1-1 條。

我另外去查了個資會的官方網站，網站標題目前仍是「個人資料保護委員會籌備處」，也就是還在籌備階段。這帶來一個很實際的後果：現行有效的裁罰主體仍然是「中央目的事業主管機關或直轄市、縣（市）政府」，不是個資會。你可以從現行有效的第 48 條看出來，它的開頭是「由中央目的事業主管機關或直轄市、縣（市）政府限期改正」；而尚未施行的新版第 48 條才把主體改成「主管機關」。

變動三：歐盟的 ePrivacy 規則提案已經被撤回

很多中文文章（包括幾年前的我）都寫過「ePrivacy 規則即將取代現行指令」。這件事在 2025 年畫下句點：歐盟執委會在 2025 年 7 月 16 日的第 2533 次會議通過撤回該提案，並於 2025 年 10 月 6 日在官方公報公告撤回。這是歐洲議會立法追蹤系統的記載，狀態欄標示為「Withdrawn」。

取而代之的方向是把 Cookie 同意規則移進 GDPR 處理的「Digital Omnibus」立法包裹，但那目前是提案，不是已通過的法律。所以現在的正確表述是：歐盟 Cookie 同意的法源仍然是 Directive 2002/58/EC 第 5 條第 3 項，同意品質標準看 GDPR。

項目	現行有效（2026-08-06）	已公布但尚未施行
主管機關	中央目的事業主管機關或直轄市、縣（市）政府	個人資料保護委員會（第 1-1 條，施行日期由行政院定之）
安全維護義務條文	第 27 條（民國 112-05-31 版）	第 27 條刪除、改由增訂之第 20-1 條規範
外洩通報	第 12 條舊版：僅「以適當方式通知當事人」	第 12 條新版：加上向主管機關通報、應變措施與紀錄保存
罰鍰上限（違反安全維護義務且情節重大）	新臺幣 1,500 萬元（現行第 48 條第 3 項）	新臺幣 1,500 萬元（新版第 48 條第 4 項，罰則架構重編）

資料來源：全國法規資料庫「個人資料保護法」條文頁與舊版條文（民國 112-05-31 版）；個人資料保護委員會籌備處官方網站。查核日 2026-08-06。施行日期一旦由行政院公告，本表即需更新。

寫政策時的具體建議：不要在文件裡寫「依個人資料保護委員會規定」或「依個資法第 20-1 條」。寫現行條文，並且在政策末尾標注版本日期，等行政院公告施行日期後再改。

Cookie 橫幅的實作：別讓它賠掉你的 Core Web Vitals

就算你決定要做橫幅，做法也有好壞之分。Google 有一篇專門講 Cookie 通知最佳實務的文件，我把裡面的重點整理成可執行的順序。

三個指標都會被橫幅影響

LCP：Google 的說法是「Most cookie consent notices are fairly small and therefore typically don’t contain a page’s LCP element. However, this can happen—particularly on mobile devices.」在手機上橫幅可能大到變成最大內容繪製元素，那你的 LCP 就被它綁架了。

CLS：「Cookie consent notices are a very common source of layout shifts.」這句話沒有轉圜餘地。Google 對 CLS 的目標是「sites should strive to have a CLS of 0.1 or less for at least 75% of page visits」——注意是 75% 的造訪，不是平均值。

INP：Google 的說法是「Cookie notices can often be a cause for high INP as they typically add a lot of third-party scripts when accepted.」而按下「接受」那一刻最痛：「The main issue is often to do the Accept interaction as that results in a lot of processing to add those third-party scripts all at once.」使用者做了一個動作，你一次把所有第三方腳本塞進去，互動延遲就爆掉了。

五個具體做法

1. 版面用固定頁尾或彈窗，不要用頂部橫幅推擠內容。Google 的建議原文是「consider using a sticky footer or modal to display the cookie notice. Because both of these alternative approaches display the cookie notice as an ‘overlay’ on top of the rest of the page, the cookie notice shouldn’t cause content shifts when it loads.」
2. 腳本直接寫進 HTML，不要透過代碼管理工具載入。「Cookie notice scripts should be loaded ‘directly’ by placing the script tag in the HTML of the main document—rather than loaded by a tag manager or other script.」這一點跟很多人的直覺相反。
3. 加 async 屬性。「Cookie notice scripts should be loaded asynchronously. To do this, add the `async` attribute to the script tag.」
4. 第三方來源要加資源提示。「All sites that load their cookie notice scripts from a third-party location should use either the `dns-prefetch` or `preconnect` resource hints.」
5. 接受之後分批載入第三方腳本，不要一次全放。這是針對 INP 的直接對策。

另外還有一個 Google 那篇沒講、但我實際踩過的坑：如果你的橫幅是用 JavaScript 動態插入 DOM 的，即使它是 fixed 定位，插入的那一刻仍可能觸發一次 CLS，特別是當它同時改變了 body 的 padding 或 overflow。測的時候要用真實裝置在無快取狀態下測，不要只看桌機版。CLS、LCP 與 INP 的實際修法我在Core Web Vitals 三項指標一次修好那篇拆解過完整流程。

別忘了可及性

橫幅是覆蓋在內容上的互動元件，鍵盤要能操作、焦點要能被困在彈窗裡、關閉後焦點要回到原處。一個做壞的 Cookie 橫幅會讓依賴鍵盤或螢幕閱讀器的使用者完全無法使用你的網站。我在網站無障礙設計那篇談過覆蓋層工具的爭議，Cookie 橫幅是同一類問題的縮影：一個為了合規而加的東西，很容易變成另一個層面的障礙。

一份可以直接改的隱私權政策骨架

先講清楚：以下是骨架，不是法律意見，也不是可以原封不動貼上去的範本。方括號裡的內容一定要換成你網站的實際情況——照抄不改的後果，就是我開頭講的那個空號客服專線。

骨架結構

【網站名稱】隱私權保護政策

本政策版本：v1.0
最後更新日期：【西元年月日】
適用網址：【https://你的網域/ 及其所有子頁面】

一、適用範圍
   1. 本政策適用於您在本網站瀏覽、填寫表單、留言、訂閱電子報、
      註冊會員或完成交易時所提供之個人資料。
   2. 本網站可能連結至第三方網站，該等網站不適用本政策，
      請您另行參閱各該網站之隱私權政策。

二、蒐集者名稱（個資法第 8 條第 1 項第 1 款）
   蒐集者：【正式名稱／本名／工作室名稱／公司全銜】
   統一編號：【若有稅籍或營業登記則填，無則刪除本行】
   聯絡信箱：【真的有人看的信箱】
   聯絡地址：【若不願公開住家地址，可寫「詳見聯絡表單」但需確保可聯繫】

三、蒐集之目的（第 2 款）
   本網站蒐集個人資料之特定目的如下（代號依法務部公告）：
   【040 行銷】【069 契約、類似契約或其他法律關係事務】
   【090 消費者、客戶管理與服務】【148 網路購物及其他電子商務服務】
   【157 調查、統計與研究分析】
   ※ 請只保留你實際有的項目。

四、個人資料之類別（第 3 款）
   【C001 辨識個人者】【C002 辨識財務者】【C011 個人描述】
   具體欄位：【姓名、電子郵件、聯絡電話、收件地址、
              瀏覽器 Cookie 識別碼、連線 IP 位址】

五、利用之期間、地區、對象及方式（第 4 款）
   1. 期間：自蒐集之日起至【特定目的消失或您請求刪除】為止。
      備份檔另保留【N】日後自動覆寫。
   2. 地區：【中華民國境內】及下列服務商之資料處理所在地：
      【服務商名稱／用途／資料處理地區】
   3. 對象：本網站、【網站主機商】、【電子報服務商】、
      【金流服務商】、【分析與廣告服務商】。
   4. 方式：以電子檔或紙本形式，於前述特定目的必要範圍內處理與利用。

六、您依個資法第 3 條得行使之權利及方式（第 5 款）
   您得就本網站保有之您的個人資料，行使下列權利：
   1. 查詢或請求閱覽 2. 請求製給複製本 3. 請求補充或更正
   4. 請求停止蒐集、處理或利用 5. 請求刪除
   行使方式：來信【信箱】，本網站將於【N】個工作日內回覆。
   依個資法第 14 條，查詢及製給複製本得酌收必要成本費用。

七、不提供個人資料之影響（第 6 款）
   您可自由選擇是否提供個人資料，但若未提供【Email】，
   將無法【接收訂單通知／使用會員功能／收到電子報】。

八、Cookie 之使用
   1. 本網站會在您的裝置中寫入及讀取 Cookie，用途包括：
      【維持登入狀態】【記住語言與顯示偏好】【流量統計與分析】
      【廣告成效衡量】。
   2. 您可於瀏覽器設定中拒絕或刪除 Cookie，
      但可能導致本網站部分功能無法正常運作。
   3. 本網站使用之第三方服務及其 Cookie 用途：
      【服務名稱／用途／該服務之隱私權政策連結】

九、資料之保護
   本網站依個人資料保護法第 27 條及同法施行細則第 12 條，
   採行下列安全措施：【HTTPS 加密傳輸】【後台兩步驟驗證】
   【定期更新與弱點修補】【最小權限原則】【定期異地備份】。

十、與第三人共用個人資料之政策
   本網站不會將您的個人資料出售、出租或以其他方式提供予第三人，
   但下列情形除外：【經您同意】【依法令或司法機關要求】
   【為履行契約所必要而委外處理（如金流、物流）】。

十一、未成年人
   若您未滿【年齡】歲，請由法定代理人陪同閱讀本政策後再提供資料。

十二、歐盟使用者（僅在你確實鎖定歐盟或監控歐盟行為時保留本節）
   若您位於歐盟境內，您另享有 GDPR 所定之權利，
   包括資料可攜權與向監理機關申訴之權利。
   本網站處理之法律依據為：【契約履行／同意／正當利益】。

十三、本政策之修正
   本政策如有修正，將於本頁公告並更新版本與日期。
   重大變更將另以【電子報／網站公告】方式通知。

骨架用完之後的三個檢查動作

第一，把每一個方括號都消滅掉。沒有例外。留一個方括號在線上，等於公告你根本沒讀過自己的文件。

第二，逐項回頭對第 8 條的六款。把條文和你的政策並排放，六款一款一款打勾。這一步花不到十分鐘，但它是這份文件有效與否的分水嶺。

第三，測試你寫的聯絡方式真的能用。用另一個信箱寄一封測試信，確認你收得到、也回得了。這聽起來很蠢，但我開頭講的那個空號案例，就是死在這一步。

如果你的網站涉及客戶委外處理（例如你幫客戶架站並碰得到他們的使用者資料），那就不只是隱私權政策的問題了——那是委外處理關係，要在合約裡處理。接案合約必備條款那篇與NDA 的機密定義那篇都可以拿來對照條款結構。至於蒐集者名稱要寫本名還是行號，跟你有沒有做稅籍登記直接相關，選擇獨資行號或一人有限公司也會影響這一欄。

我看過最常見的六個寫法錯誤

錯誤一：寫「本公司」但你不是公司。個資法第 8 條第 1 項第 1 款要的是「名稱」，個人接案就寫本名。寫錯的後果不只是不專業，而是這一款根本沒滿足。

錯誤二：把「蒐集目的」寫成「為提供更好的服務」。這句話沒有限縮任何東西。特定目的的功能就是劃界線——第 20 條規定利用「應於蒐集之特定目的必要範圍內為之」，如果你的目的寫得無邊無際，這條的保護就失效了，而且主管機關看得出來。

錯誤三：整段抄歐盟範本，寫了「資料保護長（DPO）」。台灣個資法沒有 DPO 制度。你不需要指定資料保護長，寫了反而是虛偽陳述。

錯誤四：寫「本網站使用 Cookie，繼續瀏覽即視為您同意」。這句話在台灣不必要（法律沒要求同意），在歐盟則無效（GDPR 第 4 條第 11 款要求明確肯定行為，繼續瀏覽不算）。兩邊都不討好。

錯誤五：漏掉伺服器日誌與第三方服務。幾乎沒有人寫。但第 8 條第 1 項第 4 款要求告知「利用之對象」，你的主機商、CDN、電子報服務商全都是對象。

錯誤六：政策上線後就沒再動過。你換了電子報服務商、加了新的分析工具、把主機搬到別的地區——這些都會讓政策失真。我的建議是把它跟年度稅務或網域續約排在同一個時間點檢查，一年一次。

另外提醒一個廣告投放者常犯的：如果你有跑 Google Ads 或其他關鍵字廣告，再行銷受眾名單的建立本身就是行為資料的利用，要寫進政策。這部分的帳戶設定邏輯可以參考關鍵字廣告新手的帳戶結構那篇。

常見問題

我的部落格沒有表單也沒有留言，還需要隱私權政策嗎？

要看你有沒有其他蒐集管道。如果你裝了 GA4、掛了廣告、或主機保留存取日誌（幾乎都會），那你仍然在蒐集可間接識別的資料。個資法第 8 條的告知義務不看你有沒有表單，看的是你有沒有依第 19 條蒐集個人資料。務實答案是：只要網站掛了任何分析或廣告工具，就寫一份。

台灣網站不做 Cookie 同意橫幅，真的不會被罰嗎？

就「沒做橫幅」這件事本身，台灣目前沒有可據以裁罰的條文——個資法與施行細則全文都沒有 Cookie 相關規定（我在 2026 年 8 月 6 日實際查證過）。但這不代表你可以什麼都不做：如果 Cookie 蒐集到的資料構成個人資料而你沒有依第 8 條告知，那違反的是告知義務。現行第 48 條第 1 項第 1 款就把「違反第八條或第九條規定」列為裁罰事由，由中央目的事業主管機關或直轄市、縣（市）政府限期改正，屆期未改正者按次處新臺幣二萬元以上二十萬元以下罰鍰。要罰的是沒告知，不是沒橫幅。

我從網路上抄一份隱私權政策來改，會有問題嗎？

技術上可以當起點，但有兩個風險。第一，多數流傳的中文範本是從歐盟範本翻譯來的，會出現台灣法沒有的制度（DPO、資料可攜權），也會漏掉台灣法特有的要求（特定目的代號、第 8 條第 6 款的不提供影響）。第二，範本描述的是別人網站的實際做法，不是你的。比較安全的做法是：用本文的骨架照第 8 條六款自己填，而不是拿一份完整範本回頭刪。

個資會成立之後，我的政策要重寫嗎？

會需要調整，但不是現在。截至 2026 年 8 月 6 日，個資法第 1-1 條（主管機關為個人資料保護委員會）仍是「施行日期，由行政院定之」且未定，個資會官網目前仍標示為籌備處。等行政院公告施行日期，同一批未施行條文（含刪除第 27 條、增訂第 20-1 條、新版第 12 條通報義務）會一起生效，那時再一次改完比較有效率。現在就把未生效的條號寫進政策，反而會讓文件出錯。

我用 WordPress 的隱私權政策產生器就好了吧？

WordPress 內建的隱私權政策草稿只是提示大綱，它是為國際通用情境寫的，不會幫你對應台灣個資法第 8 條的六款，也不會知道你裝了哪些第三方服務。把它當成「別忘了寫這幾個段落」的提醒可以，當成成品不行。比較有用的做法是先跑一次本文第二節的盤點表，再回頭填骨架。

如果真的發生資料外洩，我現在有什麼義務？

現行有效的個資法第 12 條規定：「公務機關或非公務機關違反本法規定，致個人資料被竊取、洩漏、竄改或其他侵害者，應查明後以適當方式通知當事人。」重點是「查明後」與「通知當事人」——現行法沒有對非公務機關規定向主管機關通報的一般義務（新版第 12 條有，但尚未施行；部分行業另有其中央目的事業主管機關訂定的辦法要求通報，要看你的行業別）。損害賠償部分適用第 29 條，除非你能證明無故意或過失，否則要負賠償責任；第 29 條第 2 項寫的是「依前項規定請求賠償者，適用前條第二項至第六項規定」，也就是套用第 28 條第 3 項在被害人不易證明實際損害額時，由法院依侵害情節以每人每一事件新臺幣五百元以上二萬元以下計算的方式。

資料來源

• 全國法規資料庫－個人資料保護法：本文引用的第 2、3、5、6、7、8、9、10、11、19、20、28、29、51 條現行條文皆逐字取自此處，並確認這些條文不在未施行清單內。
• 全國法規資料庫－個人資料保護法第 1-1 條：證明「本法之主管機關為個人資料保護委員會」是民國 112 年 5 月 31 日增訂、施行日期由行政院定之且尚未施行的條文，現行法無此條。
• 全國法規資料庫－個人資料保護法民國 112 年 5 月 31 日版：這是第 12、27、41、48 條目前現行有效的版本，證明第 27 條尚未真的被刪除、第 12 條的通報義務仍是舊版。
• 全國法規資料庫－個人資料保護法施行細則第 12 條：證明「適當之安全措施」的定義與十一項可包括事項，並確立「適當比例為原則」。
• 個人資料保護委員會籌備處－個人資料保護法之特定目的及個人資料之類別：本文表格中的 040、069、090、136、148、152、157 特定目的代號與 C001、C002、C003、C011 類別代號皆出自此公告（民國 101 年 10 月 1 日修正）。
• 個人資料保護委員會籌備處官方網站：證明個資會於查核日仍處於籌備處階段，尚未正式成為個資法的主管機關。
• 全國法規資料庫－隱私權保護政策：作為台灣政府網站「告知式」Cookie 說明的實例，其第六節逐字說明只提供瀏覽器設定拒絕的途徑，沒有任何同意按鈕要求。
• EUR-Lex－Regulation (EU) 2016/679（GDPR）合併版：本文引用的第 3 條域外效力、第 4 條第 11 款同意定義、第 7 條同意條件、第 13 條第 1 項告知事項皆出自此處。
• EUR-Lex－Directive 2002/58/EC 合併版（2009-12-19）：第 5 條第 3 項是歐盟 Cookie 同意的真正法源，證明該要求不是來自 GDPR。
• EDPB Guidelines 3/2018 on the territorial scope of the GDPR：證明「網站在歐盟連得上」不足以觸發 Article 3(2)，並列出 Cookie 追蹤屬於「監控行為」的官方清單。
• 歐洲議會立法追蹤系統－ePrivacy Regulation 提案：證明該提案狀態為「Withdrawn」，執委會於 2025 年 7 月 16 日通過撤回、2025 年 10 月 6 日於官方公報公告。
• Google EU user consent policy：證明 Google 要求發布商取得同意、揭露每一個取得資料的對象、保留同意紀錄並提供撤回說明，適用範圍為 EEA、英國與瑞士。
• Google AdSense 說明中心－認證 CMP 要求：證明 EEA 與英國自 2024 年 1 月 16 日、瑞士自 2024 年 7 月 31 日起，投放個人化廣告須使用 Google 認證且整合 TCF 的 CMP。
• Google Analytics 說明中心－IP 遮蔽：證明 GA4 不記錄也不儲存 IP 位址，因此不需要 IP 匿名化設定。
• Google 標記平台－同意模式：證明同意模式的四個參數定義，以及它是傳遞同意狀態的機制而非取得同意的工具。
• Meta Business Tools Terms：證明使用 Pixel 的網站在每一個掛了像素的網頁都須提供明顯通知與說明連結（含退出方式與可操作管道），並在有知情同意規定的管轄區以可驗證方式取得同意（頁面顯示生效日 2025 年 11 月 3 日）。
• web.dev－Best practices for cookie notices：本文引用的固定頁尾／彈窗建議、腳本直接寫入 HTML、加 async、加資源提示等作法皆出自此文。
• web.dev－Optimize Cumulative Layout Shift：證明 CLS 目標為「至少 75% 的造訪達到 0.1 以下」，以及不要在無使用者互動下插入新內容的原則。

免責聲明：本文為網站經營與技術實作的整理筆記，不構成法律意見，也不能取代律師針對個案的專業判斷。文中所引法條均以全國法規資料庫及 EUR-Lex 於 2026 年 8 月 6 日的公開版本為準，並已逐條確認施行狀態；法規、主管機關解釋與各服務商條款均可能變動，實際適用請以查閱當日的官方版本為準。若您的網站涉及特種個人資料、大量個資、跨境傳輸或特定行業的目的事業主管機關規範，請務必諮詢執業律師。