這或許不是最完美的解法，但任何打造 AI Agent、API Gateway 或 MCP Server 的人，都必須先回答三個問題：怎麼做 PII（個人可識別資訊，例如姓名、電話、Email）的偵測與遮蔽？怎麼用規則與 Regex（描述文字樣式的寫法）做偵測，它在真實世界又會碰到哪些限制？還有，信任邊界到底畫在哪裡？

我覺得這是每個想打造 AI Agent 的人，最先要做、也最避不開的一件事。這篇用我做名片自動化的經驗來談，對應的是 OWASP 大型語言模型十大風險中的 LLM02：敏感資訊揭露。

名片自動化要做的，就是把名片上的姓名、電話、傳真、Email 整理進總表。換句話說，這個任務本身就是在處理個資。如果為了安全把個資全部擋掉，功能就直接癱瘓了。

所以第一步不是寫程式，而是先決定哪裡可以碰真實資料、哪裡不行。我把本機端視為可信的地方：它持有真實資料、在本地執行，也負責寫入最終的總表。外部的雲端 LLM API 則視為不可信的地方：它只被當作整理排版的工具，從頭到尾不接觸明文個資。

具體做法是「代號化加對照表」，分成四步：

1. 本地抽取：本機程式讀取名片內容，找出姓名、電話、傳真、Email。
2. 建對照表：把個資換成代號，例如 [NAME_1]、[PHONE_1]、[FAX_1]，對照表只存在本機。
3. 遮蔽上雲：把代號連同其他內容送給雲端 API，讓模型整理成結構化的欄位。
4. 查表還原：API 回傳結果後，在交給使用者或寫入 Google Sheet 之前，用對照表換回真實資料。

舉個例子。名片在本機是這樣：

王小明
電話：02-2345-6789
傳真：02-2345-6790

送到雲端的則是這樣：

[NAME_1]
電話：[PHONE_1]
傳真：[FAX_1]

整個過程中，雲端模型看不到真實的姓名和號碼，但使用者最後看到的仍是完整的資料。

實際做下去，還是踩到了一些坑。第一個是格式相同、意思不同：傳真和電話的格式一模一樣，單靠 Regex 分不出來，只能看號碼前面的標籤（電話、傳真、Tel、Fax）和排版位置來判斷。第二個是中英文姓名的順序相反：名片上常同時印著「王小明」和「Ming Wang」，姓氏一個在前、一個在後。如果沒有考慮雙語的上下文，就很容易辨識失敗，或把名字誤當成姓氏。

最後留兩個問題給讀者想想：為什麼不直接把個資刪掉，而要用「代號化＋對照表」？當傳真和電話的格式完全一樣時，本地抽取又該看什麼特徵，才能正確分流？