用 AI 又不怕資料外洩：EMILY.RPA「個資遮蔽」模組上線
9月29日
讀畢需時 4 分鐘
先遮蔽，再上傳；AI 處理完，再一鍵還原。讓大型雲端模型放心進入你的日常作業。
AI 很好用，但資料能丟上去嗎？
這兩年，大型雲端語言模型幾乎成了每個人的工作夥伴：摘要會議記錄、整理客戶來信、撰寫回覆草稿、分析合約條款……效率提升是實實在在的。
但只要你真的想把 AI 放進日常作業，就會撞上同一面牆：
客服信件裡有客戶的姓名、手機、地址
合約裡有公司名稱、統一編號
人事資料裡有身分證字號、居留證號
內部報告裡有還沒公開的專案代號
要用雲端模型，就得把這些資料上傳。資料一旦離開公司，外洩的風險與資安、法遵上的疑慮就跟著來。結果常見的兩種做法都不理想：一是乾脆不用，錯失效率；二是硬著頭皮貼上去，祈禱沒事。
有沒有第三條路？有。這就是我們推出「個資遮蔽」模組的原因。
核心概念：遮蔽 → 處理 → 還原
個資遮蔽模組的做法很直觀，全程在本機端執行：
遮蔽（REDACT）：掃描文字，把姓名、電話、地址等敏感資訊換成佔位符，例如 {{TW_MOBILE_1}}，同時產生一份「對照表」留在本機。
交給 AI 處理：上傳到雲端模型的，只有遮蔽後的文字。明文個資不會隨 request 送出。
還原（RESTORE）：AI 回覆之後，模組依照對照表，把佔位符逐一換回原本的內容。
用一個例子來看：
階段 | 內容 |
原文 | 王小明的手機是 0912-345-678，信箱 xiaoming@example.com，請協助擬一封道歉信。 |
遮蔽後（上傳給 AI） | {{BLOCKED_1}}的手機是 {{TW_MOBILE_1}}，信箱 {{EMAIL_1}}，請協助擬一封道歉信。 |
AI 回覆 | 親愛的{{BLOCKED_1}}您好，我們將以 {{EMAIL_1}} 與您聯繫…… |
還原後 | 親愛的王小明您好，我們將以 xiaoming@example.com 與您聯繫…… |
AI 看得懂文字的結構與語意，完成了它該做的工作；而真正的個資，從頭到尾沒有離開過你的電腦。
而且還原是有保證的：對同一份文字先遮蔽、再還原，結果會與原文完全一致。
能遮蔽哪些資訊？
模組內建三組規則集，可依需求啟用：
臺灣規則集（tw）：針對台灣常見的個資格式
地址
身分證字號（含檢查碼驗證，減少誤判）
居留證（新舊式皆支援）
手機號碼、電話號碼
統一編號（必驗檢查碼）
通用規則集（generic）：Email、網址、IPv4
財務規則集（financial）：信用卡號、IBAN
其中身分證與統編都會做檢查碼驗證，一串「長得像」的數字不會被隨便當成個資，遮蔽更精準，AI 需要的上下文也不會被誤殺。
規則抓不到的，用黑名單補上
有些機敏資訊沒有固定格式：客戶名稱、專案代號、內部產品名……正規表達式很難涵蓋。
模組提供 No-Code 黑名單：把這些字串填進去，就是完全比對、命中即遮蔽為 {{BLOCKED_n}}，保證不會流出去。反過來，像公開客服信箱這類不需要遮蔽的內容，可以放進白名單，避免誤報。
黑名單還有一個貼心的設計：如果「王小明」這個名字被包在一整串地址裡，會以較大範圍的地址規則為準，確保整段地址一併被遮蔽，不會只藏了名字、露出其他部分。
小提醒：黑名單的內容本身就是機敏資料，分享技能檔之前記得檢查。
需要客製？Low-Code 自訂規則
每家公司都有自己的編號規則。透過 Low-Code 編輯器，幾行程式就能新增：
// 員工編號
options.rules.push({ type: 'EMP_ID', pattern: /EMP-\d{6}/g })
// 只遮蔽案號的數字，保留「案號：」這個上下文
options.rules.push({
type: 'CASE_NO',
pattern: /案號\s*[:：]\s*(?<redact>\d{6,10})/g,
priority: 60,
})
想關掉某個內建規則（例如網址不需要遮蔽），一行 options.disable.push('URL') 就搞定。
真正的難題：AI 會把佔位符「改壞」
遮蔽不難，難的是還原。語言模型很愛「幫忙」：可能把 {{NAME_1}} 寫成 {{name_1}}，或是換成全形的 ｛｛NAME_1｝｝。
所以還原採用分層比對：先完全比對，再容忍大小寫差異，再處理全形括號與單邊括號；連括號都被拿掉的裸寫格式，則需要明確開啟才會處理。
而我們刻意不做「猜測」：如果模型把 {{NAME_2}} 寫成了模糊不清的樣子，寧可保留原佔位符，也不去猜它是誰。因為把 A 還原成 B，比不還原嚴重得多。
還原完成後，模組會給出三項統計，且不含任何個資，可放心回報：
expected：應該還原的佔位符數
matched：實際還原成功數
orphaned：模型自己編造出來的佔位符
若 expected 與 matched 有落差，通常代表提示詞（system prompt）需要再強調「請原樣保留佔位符」。
另外，如果使用者輸入的文字本身就含有 {{NAME_1}} 這類格式，模組會將它登記為 LITERAL 一併保護，還原時只掃描一次、不遞迴，避免被有心人利用佔位符做注入。
怎麼用？三步驟串起你的 AI 流程
在 EMILY.RPA 中，個資遮蔽是一個獨立模組，參數很單純：輸入檔（FILE）、動作（ACTION：REDACT 或 RESTORE）、輸出檔與對照表檔名。典型流程是：
個資遮蔽模組（ACTION = REDACT）：產生 output.txt 與 redaction-map.json
AI Agent / LLM 模組：讀取 output.txt 交給雲端模型處理
個資遮蔽模組（ACTION = RESTORE）：使用同一份 redaction-map.json，把 AI 的結果還原成完整內容
適合的應用場景
客服與信件：讓 AI 擬回覆、做分類，客戶資料不出門
合約與法務：請 AI 整理條款重點，公司名與統編先遮起來
人資作業：履歷摘要、問卷整理，身分證與聯絡方式不外流
財務行政：對帳說明、報表摘要，卡號與帳號不曝光
會議記錄：逐字稿去識別化後再做摘要與待辦整理
使用前，請知道這幾件事
我們希望大家對能力邊界有清楚的認識：
遮蔽方式只有一種：完整換成佔位符（不做部分遮罩或保留格式）。
規則屬「比對式」偵測，格式固定的個資很準；沒有固定格式的機敏詞彙，請善用黑名單補強。
對照表裡存放的是原始個資，請妥善保管，不要跟遮蔽後的文字一起外送。
留言