Privacy Filter 是什麼？傳給 ChatGPT、Claude 前先在瀏覽器本地脫敏的免費工具

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

先講結論。

如果你常常把 log、客戶訊息、會議記錄整段貼進 ChatGPT 或 Claude，又總在送出那一刻猶豫一下，Privacy Filter 就是為這個猶豫設計的工具。它在瀏覽器裡跑，把你文字裡的姓名、電話、信箱、地址、API Key、Token 換成占位符，再讓你送出去。整個過程不上傳。

我會把它放進書籤列，而不是當成什麼合規保險。它解決的問題很小、很具體，就是送出前那幾秒。但這幾秒恰恰是個資外洩最常發生的瞬間。

TL;DR：常把真實資料貼給 AI、又怕個資外洩的人，把它加進書籤列，送出前先過一次。它不是合規保險，就是送出前那幾秒的自動關卡。

它真正在解決的問題：把資料丟給 AI 時的個資外洩風險

把一段報錯 log、一封客戶信、一份會議記錄整個貼進 AI，已經是很多開發者、客服、行政人員的日常。問題不在 AI 本身，而在「送出去的那一刻」。一旦內容離開你的裝置，你就失去了對它的控制：它可能被對方儲存、被用來訓練模型、被留在某個你查不到的 log 裡。

這不只是技術風險，還有法律風險。《個人資料保護法》把姓名、電話、地址、帳號這類可識別特定自然人的資料都納管。你把客戶的聯絡資訊未經同意貼到國外的 AI 服務，嚴格說屬於個資的「利用」行為，責任落在蒐集方身上。

舉個接案工程師常見的情境。客戶傳來一份資料庫連線資訊加幾筆測試訂單，你要請 AI 幫你寫一段匯出腳本。直接貼上去最方便，但那份內容裡可能有真實客戶的姓名電話、加上能連到正式資料庫的帳號密碼。一旦送出，這些東西就進了別人的伺服器，你事後無法回收。Privacy Filter 處理的就是這個環節，先掃掉連線字串裡的密碼與訂單裡的個資，再交給 AI，你拿到答案的同時也把風險降到可接受的範圍。

先把話講清楚：它不上傳，這點在同類工具裡很少見

用一句話定義：它是一個靜態網頁工具，打開瀏覽器就能用，自動偵測文字或截圖裡的個人識別資訊（PII, Personally Identifiable Information），繁中介面會把結果替換成 [電子郵件]、[金鑰] 這類占位符。

它最關鍵的保證只有一條，卻是這類工具最罕見的一條：辨識過程 100% 在你的裝置上完成。官方 GitHub 專案 becoolme/privacyfilter.app（MIT 授權）在說明裡明確標示，沒有伺服器、沒有上傳。介面提供繁體中文，第一次打開還能切換語系。

Pin

這條保證為什麼重要？因為多數「個資偵測」服務是要你把文字傳到它的雲端再幫你處理。說白一點，用那種服務脫敏，等於為了遮掉個資，先把同一份個資再外洩一次給第三個單位，邏輯上就矛盾。Privacy Filter 把整個推理搬進瀏覽器，從根本上避開這件事。

八類個資，夠你日常擋掉大部分手滑

依官方說明，模型會在字詞層級辨識 8 類個資。下面用一段假的聯絡訊息示範，左邊是原文，右邊是脫敏後的結果。

原文：

請在 2026 年 6 月 19 日前聯絡王小明，電子郵件是 [email protected]，電話 0912-345-678，地址是台北市信義區松仁路 7 號。

脫敏後：

請在 [日期]前聯絡[姓名]，電子郵件是 [電子郵件]，電話 [電話]，地址是[地址]

Pin

8 個類別對照：

• 人名（private_person）：王小明、陳大文這類姓名，含上下文判斷。
• 信箱（private_email）：標準格式與變形都能抓。
• 電話（private_phone）：市話、手機、含國碼的寫法。
• 地址（private_address）：實體地址到路段層級。
• 帳號與卡號（account_number）：銀行帳號、信用卡號。
• 日期（private_date）：生日、交易日期這類欄位。
• 網址（private_url）：含 query string 的連結，常夾帶 token。
• 密鑰（secret）：開發者最容易手滑外洩的 API Key、Token、連線字串。

它還內建 tesseract.js 做 OCR。你丟一張聊天軟體的對話截圖進去，它能在本地把圖裡的文字轉出來，再給敏感字打碼，整張圖的內容同樣不離開你的裝置。

跟手動改、正則、雲端 DLP 差在哪：抓得到非標準格式

不少人會問：我用編輯器的搜尋取代自己改就好，為什麼要裝這個？差別在「能不能抓到非標準格式的東西」，還有「要不要把資料交給別人」。

方法	能抓到的東西	會不會外洩	主要限制
手動搜尋取代	你記得要改的欄位	不會	幾百行 log 必漏，疲勞時一定遺漏
正則表示式	固定格式的信箱、電話、卡號	不會	抓不到口語化人名、自訂金鑰、變形格式
Privacy Filter	8 類個資，含上下文判斷	不會（本地）	模型仍會漏報，非企業級
雲端個資偵測 API	多類個資，規則完整	會（要上傳）	為了脫敏反而先把資料傳出去
企業 DLP	全流程權限、稽核、合規	看架構	要導入成本與 IT 治理，個人用不到

判斷原則很直接。你只是想把日常要分享的東西先清洗一下，Privacy Filter 夠用；你要的是組織級的資料外洩防護與稽核軌跡，那它不是答案，乖乖走 DLP。而在「不外傳資料」這個前提上，Privacy Filter 是少數能同時做到自動偵測又不上傳的選項。

為什麼能在瀏覽器裡跑（而且不外傳）

多數人對「在瀏覽器跑 AI」的印象還停留在跑不動。這幾年的關鍵改變是 Transformers.js 這個函式庫，它把 Hugging Face 的模型搬進瀏覽器，用 WebGPU 或 WebAssembly 直接在使用者的機器上推理。

Privacy Filter 用的模型是 OpenAI 開源的 openai/privacy-filter，專門訓練來在字詞層級辨識個資。它不是靠幾條正則，而是真的讀懂上下文，所以能判斷「王小明」是人名、「7號」在地址脈絡裡是門牌、hX8-pW2k 在連線字串裡是密鑰。

實際流程是這樣。第一次打開網頁，瀏覽器會從 Hugging Face 下載模型檔（數十 MB 等級）並快取在本地。載入完成後，你之後貼進去的文字都是在自己的機器上處理，不會再把內容送到伺服器跑一遍。第一次用要等一下、後續很快，原因就在這。

這裡有個值得說明的設計選擇。openai/privacy-filter 是 OpenAI 開源、專門為個資偵測調整過的小型模型，體積刻意壓在能讓瀏覽器跑得動的範圍。小模型的好處是下載快、推理輕量、適合部署到任何靜態主機；代價是它不可能像大型模型那樣理解所有長文脈絡，所以在超長文件或高度技術性的內容上，準確率會打折。所以它把自己定位成「送出前的快速初篩」，而不是企業級的精準分類引擎。

再給一個客服情境的例子，感受它處理非技術內容的效果。原文是一段客訴對話：「我上週三在門市辦的手機續約，門市人員叫我留電話 0988-123-456，說張雅婷專員會回電，結果到現在都沒消沒息，我的會員編號 A77291」。脫敏後會變成「我上週三在門市辦的手機續約，門市人員叫我留電話 [PHONE]，說 [PERSON] 專員會回電，結果到現在都沒消沒息，我的會員編號 [ACCOUNT_NUMBER]」。電話、人名、會員編號被遮掉，但投訴的事實脈絡完整保留，你照樣能拿這段去問 AI 怎麼回覆客戶。

實際操作：從打開到拿到脫敏結果

整個流程不用註冊、不用登入、不用付費。

1. 打開官方網頁版 privacyfilter.app，第一次等待模型下載與載入完成，畫面會提示正在初始化。

2. 把要處理的內容貼進輸入框，或是上傳對話截圖。

3. 讓模型掃描，它會把偵測到的敏感欄位標示出來，並顯示替換成占位符後的結果。

4. 檢查一遍標示是否合理，確認無誤後複製脫敏後的內容。

5. 把清洗過的版本貼進 ChatGPT、Claude，或你要分享的論壇與工單。

一個實務提醒。模型標示完一定要親自看一遍，尤其是密鑰與帳號這類高風險欄位。它會漏報，盲信自動結果等於把合規風險交給一個你沒看過的模型。把「自動掃描」當成「人工複檢前的初篩」，會是比較安全的用法。

瀏覽器與效能：WebGPU 與 WebAssembly

跑得快不快，取決於你的瀏覽器有沒有支援 WebGPU。

瀏覽器	推理路徑	速度
Chrome、Edge	WebGPU	最快
Safari 17+	WebAssembly	較慢
Firefox	WebAssembly	較慢

WebGPU 能直接呼叫顯示卡的運算資源，處理大批文字時差距會拉開。WebAssembly 是退路，相容性高但處理時間長一些。對一般幾百到幾千字的文章，兩者都還在可接受的範圍。

給點具體預期。一兩千字的會議記錄或客服對話，在 WebGPU 上通常幾秒內跑完，跑完的當下你幾乎不用等。換成幾萬字的完整 log，WebAssembly 機器可能要拉長到十幾秒甚至更久，這時把要處理的範圍先縮小、只貼真正需要脫敏的那一段，會比硬丟整份檔案實際。記憶體也是瓶頸，處理超大文字時瀏覽器分頁可能變頓，分批處理是比較穩的做法。

一個部署上的技術細節。模型推理需要 SharedArrayBuffer，而這個功能要求站台設定兩個安全標頭：COOP（Cross-Origin-Opener-Policy）與 COEP（Cross-Origin-Embedder-Policy）。你用官方網頁版不用管，但如果你要自己架，這兩個標頭沒設好，模型會載入失敗。

適合誰，不適合誰

適合的人有幾種清楚的面孔。

接案工程師與維運。把伺服器 log、Bug 報告貼上 GitHub Issue 或論壇求救前，先清掉連線字串裡的密碼、Token、內部帳號。這是 API Key 外洩最常見的管道，一次手滑就出事。常做這類求助的話，也能參考 TechMoon 的 Cloudflare Turnstile 教學 顧好表單安全那一端。

重度 AI 用戶。把會議記錄、客戶回饋、合約摘要丟給 ChatGPT 或 Claude 之前先脫敏。這兩個工具的基本操作，可以參考 TechMoon 的 ChatGPT 完整教學 與 Claude 介紹。

客服、行政、人資。處理聊天記錄、客訴截圖、訂單資料、員工聯絡清單時，先遮掉姓名、電話、地址、身分證字號這類欄位。人資尤其要注意，員工資料屬於高敏感個資，外洩代價很高。

不適合的情境也講清楚。生產環境的主密碼、客戶原始資料庫、合約全文、財報數字，這類東西就算跑過脫敏，也不該過任何第三方工具，更不該送進外部 AI。模型會漏報，這類內容的漏報代價你承受不起，直接鎖在內部環境處理。

個資法：用 AI 處理個資的合規底線

《個人資料保護法》的適用範圍比很多人想像的廣。只要是可識別特定自然人的資料就適用，姓名、電話、地址、帳號、甚至組合起來能指認某人的資料都算在內。把這類資料未經當事人同意送到國外 AI 服務，屬於個資的利用行為。

兩個實務原則。第一，能用脫敏後的內容達成任務，就別送原始資料。Privacy Filter 不能幫你免除法律責任，但它能降低操作面的外洩風險。第二，真的非得用真實資料測試時，優先在自己架的環境跑。本地推理正好符合這個需求，這也是 Privacy Filter 相對於雲端偵測服務的合規優勢。

要特別提醒的是，個資法對「敏感個資」（健康、病歷、犯罪記錄等）有更嚴格的規定。如果你的內容涉及這類資料，自動脫敏遠遠不夠，請走正式的合規流程，不要依賴任何單一工具。

再細一點看條文。第 19 條列出蒐集處理個資的合法事由，多數非公務機關是靠「當事人同意」或「契約關係」這類前提。你把客戶資料送進 AI 前，要先確認當初取得這些資料時的同意範圍有沒有涵蓋這種利用方式。很多時候答案是沒有。

第 6 條更嚴格。病歷、醫療、基因、健康檢查、犯罪前科這類敏感資料，原則上禁止蒐集處理利用，除非有特別例外事由。這類資料更要避免進入任何外部 AI 工具。

讀這些條文不是要你變成法律專家，而是讓你在「這份內容能不能送 AI」的判斷上，有一個比憑感覺更可靠的依據。

自己架一份：部署到 Cloudflare Pages

它是靜態站、MIT 授權，原始碼在 GitHub。想在團隊內部用、或不想依賴官方網域，可以自己部署。前置需求是 Node.js 20 以上與 pnpm 9 以上。

基本步驟（依官方 README）：

1. git clone 專案，pnpm install 安裝相依套件。

2. pnpm dev 在本機跑起來預覽，第一次會下載 openai/privacy-filter 模型。

3. pnpm build 產出靜態檔。

4. pnpm deploy 部署到 Cloudflare，或把 build 產出丟到任何靜態主機。

部署前有兩件事必須確認。第一是前面提過的 COOP 與 COEP 安全標頭，沒設好模型載入會失敗。第二是模型檔的載入來源，預設從 Hugging Face 拉，若你的內部網路對外受限，要確認能連到模型來源或自行托管模型檔。

如果還不熟 Cloudflare，先看 TechMoon 的 Cloudflare 免費 CDN 與 DNS 教學 打底，部署觀念會接得上。想知道自己電腦跑本地模型順不順，也能參考 Can I Run AI 本地模型檢測教學。團隊要長期用 Cloudflare Workers 做邊緣運算，這個專案也支援部署到 Workers。

它做不到的事：別拿來當合規保險

它依賴模型辨識，而模型不是萬能。幾種會漏報或誤判的情況要心裡有數。

非常口語化的人名。綽號、罕見姓名、英文暱稱在缺乏上下文時可能抓不到。非標準格式的自訂金鑰。你自己拼湊的 token 如果長得不像常見格式，模型未必認得。中英混雜、夾雜程式碼註解的內容，辨識難度也會上升。

把它定位成送出前的輕量檢查步驟，而不是完整的資料安全方案。要企業級的權限管理、稽核軌跡、合規審核，乖乖走 DLP 與內部規範。它沒有稽核 log、沒有權限分級、沒有復原機制，這些都是它刻意不做的。

進階用法：把脫敏固定成工作流

單次用 Privacy Filter 清洗一段文字不難，難的是讓它變成你或團隊每天都會做的習慣。幾個把它嵌進既有流程的做法。

第一，把它設成瀏覽器的搜尋引擎捷徑或書籤列按鈕，做到「複製原文、點一下、貼上、清洗、複製結果」的肌肉記憶。摩擦越低，越容易養成習慣。第二，建立一份「必脫敏欄位清單」，例如你的工作常碰到的客戶電話、訂單編號、內部帳號，跑完自動掃描後對照清單再人工看一遍，比單純信任模型穩當。第三，團隊場景自架一份內部版本，統一大家用同一個入口，避免有人用官方網頁、有人用別的來路不明工具，造成處理標準不一致。

一個常見的誤解是把脫敏當成萬無一失的保險。它有點像便當打包前再瞄一眼有沒有附餐具，能擋掉大部分粗心，但不保證什麼都不漏。把它放在「自動初篩」這一層，後面接你自己的人工複檢，才是比較務實的疊法。

替代方案

如果你評估後覺得 Privacy Filter 不符需求，幾個方向的替代。

正則為主的脫敏函式庫。適合你明確知道要遮哪些固定格式欄位（信用卡、身分證、電話），輕量、可嵌入既有的程式流程，但抓不到語意型的個資，遇到變形格式就失效。代表是各語言生態裡常見的 redactor 套件，你自己寫幾條規則也能上手。

雲端個資偵測服務。Google Cloud DLP、AWS Macie 這類是代表，規則完整、支援分類與風險評分，能處理結構化與非結構化資料。代價是要把資料上傳到它的雲端，在「不外傳」這點上與 Privacy Filter 完全相反。適合已經把資料放在同一個雲端生態、且通過合規評估的組織。

企業 DLP 套裝。功能最完整，涵蓋端點、網路、儲存的全方位防護與稽核，但導入成本高、需要專職 IT 治理，個人與小團隊通常用不到，也不該為了單純的 AI 投餘風險而硬上。

選擇的關鍵問題只有一個：你能不能接受把待脫敏的內容傳給第三方。能，雲端服務規則更強；不能，Privacy Filter 是少數務實的本地選項。

3 個下一步

1. 把 privacyfilter.app 加到書籤列，養成「貼給 AI 前先過一次」的習慣。預期花不到 10 秒就能拿到脫敏版本，長期下來能擋掉絕大多數手滑外洩。

2. 盤點你常送出的內容類型，確認 8 類偵測涵蓋你最怕外洩的欄位。涵蓋不到的，補上人工複檢，別讓自動掃描成為唯一關卡。

3. 如果是團隊需要，clone 專案自架到 Cloudflare Pages，把脫敏步驟固定成內部流程，順便處理好 COOP 與 COEP 標頭。

如果你常需要把真實資料丟給 AI 又不放心，不妨試試看 Privacy Filter，把它當成送出前的那一道自動檢查。如果你喜歡這篇文章，歡迎分享給可能有同樣困擾的朋友。

常見問題

第一次用為什麼要等一下？

瀏覽器要從 Hugging Face 下載 openai/privacy-filter 模型檔並快取在本地，之後就不用重抓。

我的文字會被上傳嗎？

不會。依官方說明，推理 100% 在你的裝置上完成，沒有伺服器接收內容。

它抓得到自訂的 API Key 嗎？

模型會偵測密鑰類，但非標準格式的自訂金鑰仍可能漏抓。高敏感內容請務必再人工檢查一遍。

手機上能用嗎？

它是網頁工具，手機瀏覽器能開，但 WebGPU 支援與記憶體有限，處理大量文字時桌機體驗較穩定。

模型下載完之後，沒有網路也能用嗎？

可以。模型快取在本地後，推理不需要連網。第一次下載需要網路，之後離線也能跑脫敏，這對在受限網路環境或重視氣隙安全的工作場景是加分。

能取代企業 DLP 嗎？

不能。它是個人與小團隊的輕量脫敏輔助，沒有權限控管、稽核軌跡與合規審核機制。

處理過的內容會被留存嗎？

因為推理在本地，官方設計上不留存你的內容。但若你自架，留存與否取決於你自己的部署與 log 設定，這點要自行把關。

中英混雜、夾雜程式碼的內容辨識準嗎？

純中文或純英文的辨識較穩。中英夾雜、或文字裡嵌了大段程式碼與註解時，模型要把程式碼裡的字串與真正的個資分開，難度較高，誤判與漏報都會增加。這類內容建議先手動把程式碼區塊與敘述文字分開，針對敘述部分脫敏，再把程式碼另外處理，準確率會比整段丟進去好。