隱私與信任邊界
目前狀態
Planned（已規劃）的架構。不是正式環境的資安邊界。
這份文件描述：未來如何把「本地／隱私處理路徑」加入目前的協作架構，同時避免把整個專案擴張成新的資安 Framework（框架）。
目標
當雲端 Agent 的能力更強、工具更完整，而且確實值得使用時，盡量減少不必要的資料揭露；同時確保某些資料類型永遠不離開本地環境。
整體模式是：
本地分類 → 本地最小化 → 適合時進行假名化 → 選擇性使用雲端 → 本地還原
它不是：
「把任意機密資料加密成密文，再期待雲端模型直接理解密文內容。」
信任分類
| 類別 | 例子 | 預設處理方式 |
|---|---|---|
| Public（公開） | 公開文件、公開程式碼、一般研究資料 | 可使用雲端 |
| Internal（內部） | 姓名、內部識別碼、一般業務脈絡 | 先在本地最小化／遮蔽；Policy 允許時才上雲 |
| Sensitive（敏感） | 專有專案名稱、技術識別碼、可抽象化的設計細節 | 可逆假名化；Policy 允許時才上雲 |
| Restricted（限制） | Secrets、Credentials、Private Keys、政策／合約禁止外傳資料，或「內容本身的意義」就是機密的資料 | 僅限本地 |
實際分類方式一定會因組織而異。這張表是架構示例，不是法遵政策。
建議處理流程
原始輸入
↓
Secret / deterministic scan
（祕密／確定性掃描）
↓
資料分類
├─ Restricted ─────────> 僅限本地
├─ Public ─────────────> 雲端 Agent
└─ Internal / Sensitive
↓
Context 最小化
↓
假名化
↓
再次外洩掃描
↓
雲端 Agent
↓
輸出掃描
↓
本地還原
實際 Pipeline（處理管線）可以依 Policy 簡化；不是每一筆請求都需要經過所有步驟。
優先使用成熟元件
本專案不應重新發明通用 PII（個人可識別資訊）偵測。
Presidio 是成熟的開源專案，可以偵測、遮蔽、Mask（遮罩）與 Anonymize（匿名化）多種敏感資訊。這裡把它視為確定性偵測／匿名化能力的參考元件。
另一個過去常見的專案 LLM Guard，示範過：
- LLM Input / Output scanner（輸入／輸出掃描）；
- Anonymize / Deanonymize（匿名化／還原）模式。
但它的 Repository 目前已封存，因此比較適合作為設計先例，不適合作為長期核心依賴。
為什麼本地模型仍有價值
傳統 PII 偵測擅長辨認：
- 姓名；
- Email；
- IP；
- 其他有固定格式或常見特徵的識別資訊。
但組織內還會有許多只有在特定 Context 裡才敏感的概念，例如：
- 內部專案名稱；
- 專有設備或製程識別碼；
- 尚未公開的設計術語；
- 客戶代稱；
- 內部 Code name（代號）；
- 會洩露架構資訊的 Source symbol（原始碼符號）。
本地的 Qwen 類模型可以作為 Semantic classifier（語意分類器），補充確定性偵測看不到的組織語境。
但它不能是唯一的 Policy authority（政策裁決者）。
建議責任分工：
確定性規則／Secret scanner
-> 決定硬性禁止／明確允許的類別
本地語意分類器
-> 提供額外風險訊號
Policy
-> 做最後的路由決定
可逆假名化
敏感值可以先替換成本地穩定代號：
真實設備名稱 -> <EQUIPMENT_A>
專案代號 -> <PROJECT_B>
內部參數名稱 -> <PARAM_C>
對照表只保留在 Local vault（本地保管區）：
<EQUIPMENT_A> -> 原始值
<PROJECT_B> -> 原始值
<PARAM_C> -> 原始值
簡單工作流程可以只把 Mapping（對照）放在暫時性的本機記憶體裡。
如果真的需要保存，也應留在本地 Vault，而不是把它變成需要跨系統同步的分散式狀態。
這樣可以避免只是為了「之後還原代號」，就另外引入狀態同步機制。
Vault 本身仍應使用一般本地資安控制，例如：
- 作業系統保護的 Credentials；
- Encryption at rest（靜態資料加密）。
重要區別
Pseudonymization（假名化）不是 Encryption（加密）。
雲端模型仍會看到可讀、可推理的語意結構，只是識別資訊被換成代號。
因此：
假名化可以降低直接暴露，但不能讓雲端處理變成零風險。
剩餘風險
就算識別資訊都被拿掉，剩餘 Context 還是可能透過以下線索反推出原始主體：
- 獨特技術特徵；
- 多個事實的組合；
- 日期與地點；
- 不尋常的製程描述；
- 程式碼結構；
- 特定領域術語。
這就是 Semantic re-identification（語意再識別）風險。
因此，有些任務即使技術上「可以換代號」，仍然應該維持 Local only（只在本地）。
資安邊界
信任邊界應由本地 Policy 與工具強制執行。
不要依賴：
- 只在 Prompt 裡告訴雲端 Agent「不要洩漏資料」；
- 假設本地 LLM 每次都會判對；
- 只靠假名化；
- 假設服務提供者永遠不會保留或檢視資料；
- 一個籠統的「Enterprise-safe（企業安全）」標籤。
驗證方向
在把這一層從 Planned（已規劃）提升到 Implemented（已實作）之前，至少應測試：
- 敏感實體的漏判；
- Secret 外洩；
- 語意再識別案例；
- Token／還原正確率；
- 輸出端外洩；
- Local-only Policy 是否真的會阻擋外傳。
在上述測試建立之前，不應做正式環境資安能力的宣稱。