AI Agent 治理的起點，不是再寫一份「AI 應負責任使用」政策，而是把每個 actor 能讀什麼、能呼叫什麼工具、何時要人核准、事後留下什麼證據畫清楚。先完成 capability map，再把政策逐條綁到 scope、approval、telemetry、recovery 與明確 owner，治理才會進入產品與日常流程。
為什麼只有原則，擋不住一個 tool call
聊天工具主要產生文字；Agent 則可能連續讀資料、呼叫工具、建立檔案、送出結果或修改設定。風險不只來自惡意行為，也可能來自目標含糊、資料誤讀、工具描述受污染，或模型把「可以做」誤認成「應該做」。
政策若只寫「需有人類監督」，實作者仍不知道：哪種查詢可以自動跑？誰核准？核准看到哪些參數？出錯時能否撤銷？同樣地，「保留 audit trail」也不等於把所有 prompt 與資料全文寫入 log；那可能創造另一份敏感資料副本。
NIST AI RMF Core 將 AI 風險管理分成 Govern、Map、Measure、Manage，並要求清楚界定人與 AI 的角色、持續監控及定期檢視。AI RMF 1.0 目前正在修訂，因此適合當作組織風險語言，而不是把單一版本當成永遠不變的合規清單。
六格能力地圖：把抽象治理翻成可測試問題
為一個具體 use case 填完以下六格，比從「全公司的 AI」開始更有效。
1. Scope：它在哪裡工作？
列出資料來源、workspace、專案、使用者群與環境。不要只寫「公司資料」，要具體到 schema、資料夾或客戶範圍。
測試問題： Agent 能否在沒有明確選擇的情況下跨 workspace？能否看到任務無關的敏感欄位？
2. Capability：它被允許做什麼？
把能力拆成 read、analyze、write artifact、export、external action、admin。權限應由執行層強制，不靠 prompt 要求模型自律。
測試問題： 唯讀角色呼叫寫入工具時，後端是否拒絕？正式分析工具是否能在未核准狀態使用？
3. Approval：哪些決定由誰核准？
核准點應和影響匹配。欄位探索可能不需逐次批准；會進財務、客戶或主管會議的正式數字，應先審口徑；對外傳送、管理設定或不可逆動作則需更強確認。
測試問題： 審閱者看得到目的、資料範圍、參數與副作用嗎？拒絕後是否 fail closed？
4. Telemetry：怎麼知道它真的做了什麼？
至少記錄 actor、時間、workspace、tool、policy／approval 結果、受影響 artifact 與執行狀態。輸出摘要要能連回正式 evidence，而不是只保存 Agent 的自述。
測試問題： 三天後能否回答「這個數字由哪個查詢產生」？Credential 與敏感正文是否有遮蔽？
5. Recovery：出錯後怎麼停、怎麼復原？
Recovery 包含終止 session、撤銷 credential、回退可逆內容、重新執行與事件通報。要區分文字變更與真正的外部副作用；不是所有動作都能 Undo。
測試問題： 異常迴圈能否中止？後續已有人工修改時，回退是否會因 conflict 被阻擋？
6. Accountability：誰擁有結果與控制？
為 use case 指定業務 owner、資料 owner、技術 owner 與 incident owner。Human approval 不會把所有責任神奇地轉給「最後按按鈕的人」；界面與資料不足時，核准本身也可能失效。
測試問題： 指標口徑誰簽、權限誰開、事故誰處理、多久 review 一次？
實例：把「分析上月轉化率」分成三級
同一句任務可以依影響分級，而不是一律自動或一律封鎖：
| 風險級別 | 任務 | 自動化範圍 | 人類控制 |
|---|---|---|---|
| 低 | 看 schema、空值、日期範圍 | 在指定 workspace 內自動探索 | 可隨時中止；保留查詢活動 |
| 中 | 計算內部週會漏斗 | Agent 草擬 Plan 與 SQL | 審分母、時間窗、排除條件後 Execute |
| 高 | 對外揭露或修改資料／設定 | 不直接授權 | 獨立確認、限定目的地、額外 owner 核准 |
這個分級的關鍵不是 SQL 長度，而是錯誤影響與可恢復性。查詢只有十行，也可能產生財報用數字；一個長達數十步的 schema 盤點，若只讀且不外傳，反而可能是低風險。
三種常見「有治理外觀、沒治理效果」的設計
每一步都讓人按 Allow
確認疲勞會把核准降格成節奏障礙。把同一 Plan 範圍內、可追溯的查詢整合成一次有意義的授權；對超出範圍的高影響動作再獨立確認。
有 log 就叫 audit
若 log 看不到 workspace、工具參數與 artifact，只留下自然語言摘要，就難以調查。反過來，若把 token 與完整資料全部寫入 log，也不是安全的 audit。
把 Admin 當預設便利模式
Admin 不是「比較不會卡住」，而是允許更高信任的組織與設定操作。第一次試用應從最小能力開始，以實際阻礙證明升權的必要。
OWASP AI Agent Security Cheat Sheet 將 tool misuse、privilege escalation、memory poisoning、excessive autonomy 與 sensitive data exposure 分開處理，也說明 Agent 治理不能只防 prompt injection；身份、工具、記憶與資料流都要有控制。
Lantide Data 如何把治理嵌進分析工作流
Lantide Data 是 local-first 的 SQL 分析 IDE 與 Agent runtime。正式 Project Analysis 將治理放進 Plan → review／annotation → user-approved Execute → Report：Plan 先承載問題、分母、grain 與 checkpoints，Execute 後的正式 evidence 留在 execution progress，Report 再連回證據與 limitations。流程見 Plan → Execute → Report 指南。
外部 Agent 透過本機 MCP Server 連入時，Observe／Execute／Admin 是 connection 的能力上限；Plan approval 只授權該 Plan，不會升級 connection。GUI 的 External MCP Activity 可核對 tool call、policy／review 與 artifact 變更；支援回退的文字修改仍會做 hash conflict 檢查。連線、recovery 與 client compatibility 需按實際版本驗證。詳見 外部 Agent 整合。
這些機制降低的是「能力與證據不可見」的風險，不保證模型結論正確，也不代替組織的資料分類、法遵判斷與事件處理。Local-first 也不等於所有外部模型和 connector 都把資料留在裝置上。
結語：用一個真實 use case 完成第一張圖
選一個資料明確、會被追問、但錯誤影響可控的分析，在一頁內填完六格：Scope、Capability、Approval、Telemetry、Recovery、Accountability。接著各設計一個拒絕測試與復原測試。當團隊能證明「不該做的做不到、做過的查得到、出錯時停得下來」，政策才真正變成治理。