用了雲端 AI，文件裡的個資怎麼辦？我們的三層遮蔽設計
想讓 AI 讀懂組織的 PDF 文件，但文件裡有人名、身分證字號、電話。直接丟上雲端不行，全部遮掉 AI 又讀不懂。這篇拆解我們怎麼用三層遮蔽機制，在保護個資和保留文件可讀性之間找到平衡。
用了雲端 AI，文件裡的個資怎麼辦？我們的三層遮蔽設計
越來越多組織想用 AI 處理內部文件——從 PDF 中找答案、做摘要、產報告。問題來了：文件裡有人名、身分證字號、電話、Email，送上雲端 AI 處理，安全嗎？
這不是技術問題，是信任問題。
就算雲端供應商承諾「不會用你的資料訓練模型」，很多組織仍然不放心。尤其是政府機關、醫療機構、金融業——他們處理的文件裡，敏感資訊的密度特別高。
最近我們在設計一套 AI 文件知識庫時，拿公開的政府公文來做技術驗證。政府公文是很好的測試素材——格式多樣（純文字、表格、簡報）、人名密度高（會議紀錄裡動輒幾十位出席者）、而且是公開資訊，不涉及客戶機密。這篇文章記錄我們的設計過程，核心思路只有一句話：敏感資料在離開自己的伺服器之前就遮蔽掉，雲端 AI 永遠看不到原始個資。
為什麼不能「全遮」或「不遮」
先釐清兩個極端方案為什麼都不行。
不遮，直接送雲端。 最省事，但風險太大。就算雲端 AI 供應商（如微軟 Azure OpenAI）白紙黑字簽了合約，承諾不會用企業客戶的資料訓練模型，資料在傳輸過程中仍然離開了組織的控制範圍。對於受法規約束的機關，這條路走不通。
全部遮掉再送。 最安全，但 AI 讀不懂了。把所有人名、地名、機構名都換成 <MASKED>，一段話變成「<MASKED> 在 <MASKED> 召開 <MASKED> 會議，決議 <MASKED> 應改善 <MASKED>」——AI 看到這段文字，什麼有用的回答都生成不出來。
真正的問題是：怎麼在保護個資和保留文件可讀性之間找到平衡。
中文個資遮蔽，為什麼特別難
遮蔽英文個資相對容易——社會安全碼固定 9 碼、Email 有 @ 符號、電話有固定格式，電腦靠格式就能認出來。但中文文件有幾個特別麻煩的地方：
第一，中文人名沒有固定格式。 英文名字通常大寫開頭、前後有空格，比較好抓。中文人名兩到三個字，跟一般詞彙混在一起，「林小明」三個字也可以是一句話的一部分。電腦光看字，分不出來哪幾個字是人名。
第二，公開公文有獨特的人名結構。 政府公開的會議紀錄、開會通知單裡，人名不是單獨出現的，而是嵌在職稱裡——「張委員小果」「李主任委員小友」「王小明視察」。這種「姓 + 職稱 + 名」的格式在環評會議紀錄中大量出現，一般的 AI 辨識工具不一定處理得好。
第三，該留的不能遮，該遮的不能漏。 「環境部」是機關名稱，要留；「張小果」是個人姓名，要遮。但 AI 辨識工具有時候會搞混——「台北市中正區延平南路」被判定為人名，遮掉之後地址資訊就消失了。
三層遮蔽：每層做它最擅長的事
我們的設計原則是不靠單一技術解決所有問題，而是讓三層機制各自處理它最擅長的類型，互相補位。
第一層：格式比對——長得像個資的，直接抓
處理格式固定的個資，精準度最高、速度最快。原理很簡單：身分證字號一定是「一個英文字母 + 九個數字」，手機一定是「09 開頭 + 八個數字」。只要定義好這些格式規則，電腦就能一秒掃完整份文件。
| 個資類型 | 怎麼認出來的 | 替換成 |
|---|---|---|
| 身分證字號 | 一個英文字母 + 九個數字 | <ID> |
| 統一編號 | 連續八個數字 + 前後文判斷 | <TAX_ID> |
| 手機 | 09 開頭 + 八個數字 | <PHONE> |
| 含 @ 符號的標準格式 | <EMAIL> | |
| 公文結構化人名 | 「姓+委員+名」「姓+主任委員+名」等固定寫法 | <NAME>委員 |
最後一項是針對公開政府公文做的客製規則。公文裡「張委員小果」出現的頻率，比單獨出現「張小果」高得多。我們把常見的公文職稱結構都寫成比對規則——「X委員OO」「X主任委員OO」「OOO視察」「X執行秘書OO」——直接拆出姓名並遮蔽，保留職稱。
這一層的特點是零誤判、零遺漏（對它覆蓋的格式而言）。但它只能處理格式固定的個資，自由出現在內文中的人名抓不到。
第二層：AI 語意辨識——讀前後文猜人名
第一層靠格式抓，但人名沒有固定格式。這時就需要一個「會讀前後文」的 AI 來幫忙。
比如一份公開的開會通知單裡寫「聯絡人為陳小友，電話⋯⋯」，「陳小友」沒有接職稱，第一層的格式規則抓不到。但 AI 看到「聯絡人為」這個前後文，就能判斷後面接的是人名。
我們用的是中研院開發的繁體中文 AI 辨識模型（CKIP），專門針對中文語境調校，辨識效果比一般多語言模型好。
這一層的特點是覆蓋面廣，能抓到各種位置出現的人名。但它有誤判的可能——有時候會把不是人名的詞判成人名。
第三層：白名單過濾——防止誤殺
白名單預先定義三類「看起來像人名但不應該遮蔽」的詞彙：
- 機關名稱：環境部、環保局、內政部XXX署
- 地名與路名：台北市中正區延平南路
- 專業術語：放流水標準、事業廢棄物清理計畫
前一層 AI 判定為人名的結果，如果出現在白名單裡，就不遮蔽。
這一層的角色是守門員——前兩層負責「盡量多抓」，第三層負責「把誤判放回去」。
實測數據
我們用一份 11 頁的公開政府開會通知單跑完三層流程，結果如下：
| 層級 | 捕捉數量 | 說明 |
|---|---|---|
| 第一層（格式比對） | 43 個人名 + 2 筆格式個資 | 公文結構化人名全數捕捉 |
| 第二層（AI 語意辨識） | 28 個人名 | 補漏內文中散落的人名 |
| 第三層（白名單過濾） | 0 個誤遮修正 | 機關名稱、地名零誤遮 |
| 合計 | 71 個人名 + 2 筆格式個資遮蔽 |
三層機制各有分工：第一層靠規則吃掉大部分，第二層用 AI 補漏，第三層防止矯枉過正。
在更複雜的公開文件上（35 頁環評審查簡報，含 110 張嵌入圖片），文字提取後經遮蔽處理，再送 AI 做結構化重組。AI 全程只接觸遮蔽後的文字，無法還原任何個人資訊。
用一段公開的環評會議紀錄來看實際效果：
遮蔽前（公開公文原文, 姓名調整示意）：
主持人：張委員小果。出席者：李主任委員小友、王委員小明、陳委員小華⋯⋯聯絡人為林小美 02-2311-XXXX
遮蔽後（送往雲端 AI 的版本）：
主持人：
<NAME>委員。出席者：<NAME>主任委員、<NAME>委員、<NAME>委員⋯⋯聯絡人為<NAME><PHONE>
AI 看到的版本保留了完整的會議結構（誰主持、誰出席、誰是聯絡人），但所有個人身分資訊都已替換。當使用者問「這場會議討論了什麼議題？」，AI 照樣能從內文找到答案。
遮蔽之後，AI 還能正常運作嗎
這是很多人會問的問題。答案是：可以，但要設計好替換標記。
我們不是把人名換成空白或星號，而是換成有意義的代號——<NAME>委員、<NAME>視察。這樣 AI 讀到「<NAME>委員指出應加強改善⋯⋯」，仍然能理解這段話的意思：有一個委員提出了要求，要求的內容是什麼。
AI 不需要知道委員叫什麼名字，就能正確回答「委員會上提出了哪些改善要求？」這類問題。
換句話說，遮蔽的目標不是「把資訊刪掉」，而是**「把 AI 不需要知道的部分替換掉，保留 AI 需要理解的部分」**。
這套設計適用於什麼場景
只要你的組織同時符合這兩個條件，就會遇到同樣的問題：
- 文件含敏感資訊：人名、個資、商業機密、病歷、法律案件細節
- 想用雲端 AI 處理這些文件：問答、摘要、分析、報告生成
具體來說：
- 政府機關：公文、會議紀錄、稽查報告裡滿是人名和聯絡資訊
- 醫療機構：病歷摘要、臨床報告、研究資料含病患個資
- 法律事務所：判決書、合約、訴訟文件含當事人資訊
- 金融機構：法遵文件、客戶報告、內部稽核報告含個資
- 工程顧問：環評報告、調查紀錄含受訪者與土地所有人資訊
每個領域的「結構化人名」長不一樣，但三層遮蔽的架構是通用的——第一層針對該領域的特定格式客製、第二層用 AI 補漏、第三層白名單防誤判。客製化的工作量集中在第一層和第三層的規則維護，核心架構不用動。
如果你的組織也在考慮用 AI 處理含敏感資訊的文件，帶著你的場景來聊，我們一起評估最合理的做法。
或直接聯繫專人 cy.hsu@goyo-tech.com