先說免責

我不是律師。以下是從資安架構角度整理的對應關係，實際的法規適用與解釋，應由法遵單位與法律顧問判斷。法規也會修訂，實作前請確認現行版本。

個資法：四個關鍵條文

第 6 條：特種個資。

病歷、醫療、基因、性生活、健康檢查、犯罪前科，原則上不得蒐集處理利用，除有法定事由。

架構對應：D4 把特種個資獨立成一類，D9 預設用遮罩（不可還原），D25 的 F7 把「特種個資被設為可還原」列為重大失敗。

這個設計的合規意義是：系統在架構層面就限制了特種個資的利用範圍，而不是靠人員自律。

第 8 條：告知義務。

蒐集個資時應告知蒐集目的、利用期間、地區、對象、方式等。

架構對應：這一條主要由業務流程承擔（客戶簽署的告知同意書），但架構要能支持——特別是「利用對象」如果包含境外的 LLM 服務商，這件事應該在告知內容裡。

去識別化在這裡有一個重要作用：如果送出去的資料已經無從識別特定個人，法律上可能不再屬於個資（第 2 條的定義）。但這個判斷要非常小心，D17 提過結構本身也可能洩漏，所以「去識別化後就不是個資了」不是一個可以隨便主張的立場。

第 11 條：正確性與刪除。

當事人可以請求刪除、停止處理或利用。

架構對應：D12 的 expires_at 與生命週期政策、D18 的 crypto-shredding。

crypto-shredding 在這裡特別有價值：當事人請求刪除時，你需要能證明資料真的沒了——包含備份裡的。逐筆刪除備份幾乎做不到，但銷毀該 scope 的派生金鑰是可證明、可稽核的。

第 27 條：安全維護措施。

非公務機關保有個資檔案者，應採行適當之安全措施防止個資被竊取、竄改、毀損、滅失或洩漏。

這是整套架構的主要法源。施行細則第 12 條列了十一款措施，逐款對應：

這張表在寫合規文件時很好用——它把技術設計逐項對應到法定要求。

金融業的額外要求

金融機構還受金管會的規範拘束，主要是金融機構辦理電腦系統資訊安全評估辦法、各業別的內部控制及稽核制度實施辦法，以及雲端服務委外的相關規定。

實務上會被問到的幾件事：

一、雲端委外的申報與核准。 使用境外雲端服務處理客戶資料，通常需要事前程序。這不是技術問題，但架構設計會影響申報內容——例如「送出的是去識別化資料」和「送出的是原始資料」在申報上是完全不同的事。

二、資料在地化。 部分業務的客戶資料有境內處理要求。這對應到 D29 的地雲邊界設計。

三、委外機構的監督。 需要能證明對雲端服務商有持續監督能力。稽核日誌、SLA、資料處理協議都在這個範疇。

四、業務持續。 如果雲端 LLM 服務中斷，法務作業要能持續。這反過來支持 D13 的分級路由——保留一條地端路徑，不只是為了資安，也是為了 BCP。

幾個容易被問倒的問題

Q：去識別化之後還算個資嗎？

看去識別化的程度。如果保留了還原能力（Token 化 + Vault），那對持有 Vault 的人來說仍然是個資。GDPR 的用詞區分得很清楚：pseudonymisation（假名化）仍屬個資，anonymisation（匿名化）才不是。

台灣個資法沒有這麼明確的區分，但保守的立場應該是：只要你保有還原能力，就當作它還是個資來管理。 這也是為什麼 D9 說「可還原是一個成本，不是一個功能」。

Q：送給 LLM 服務商，算不算「國際傳輸」？

如果服務在境外，是。個資法第 21 條給了主管機關限制國際傳輸的權力。

去識別化能降低風險但不必然改變定性。這個判斷要法遵做。

Q：模型會不會記住我們的資料？

企業版服務通常合約載明不用於訓練。但「不用於訓練」和「不留存」是兩件事——多數服務會有一段時間的留存期（用於濫用偵測）。

這是為什麼去識別化不能省：即使有合約保障，你也應該假設送出去的東西可能被留存。

把架構決策對應到合規論述

最後一個實務建議。當法遵或稽核來問「為什麼這樣設計」，你需要能用他們的語言回答：

把技術決策翻譯成合規語言，是這類專案能不能推動的關鍵。 純技術論述在治理會議上是說服不了人的。

明天談邊界：資料到底出不出境。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。
IG：@aid3fend

有想討論的架構細節或不同意見，留言或私訊都歡迎。