企業在評估 AI Agent 資料安全時，第一步不是先選模型，而是界定它代表誰、能讀取哪些資料、可以呼叫哪些工具、哪些結果需要人工負責，以及每次行動如何被追溯。模型能力只是執行條件；資料安全、身份、權限、驗證與稽核才決定 Agent 能否進入正式流程。
下一步：還在找第一條流程，先做 20 題 AI Agent 適用度自評；如果已能說出流程、任務量與現用系統，再申請 15 分鐘 AI 工作流程適配篩選。
企業不應先追求完全自主，而應依任務風險逐步開放讀取、草稿、受限寫入與高影響操作。任何無法回復、會影響客戶、金流、個資、法規或公開聲譽的行動，都需要更嚴格的授權與人工核准。
- AI Agent治理要同時管理任務、資料、身份、工具、輸出與責任。
- 使用者、Agent Workload、Client與Resource Server應有可區分的身份與授權紀錄。
- 資料必須標示擁有者、版本、敏感度、允許用途與保存期限。
- 讀取、草稿、寫入、發布、付款與刪除不能共用同一權限層級。
- 稽核紀錄要能回答誰要求、Agent做了什麼、使用哪些資料，以及誰核准結果。
治理主頁責任：資料、身份、權限、人工核准、稽核、事件回復與持續評估。攻擊面另看 AI Agent 資安風險與 Red Team；權限 rollout 另看 Shadow Mode。
\n
企業AI Agent治理包含哪些範圍？
| 治理面向 | 核心問題 |
|---|---|
| 任務 | Agent負責什麼，什麼不在範圍內？ |
| 資料 | 能讀哪些來源，能否保存、轉傳或再利用？ |
| 身份 | Agent代表誰行動，使用哪個Workload Identity？ |
| 權限 | 可以使用哪些工具、資源與操作層級？ |
| 驗證 | 結果如何被測試、抽查與人工確認？ |
| 稽核 | 行動、來源、費用、錯誤與核准能否重建？ |
| 事故 | 出錯後如何停止、撤銷、通報與修正？ |
治理不應只由法務或資安部門在上線前審查一次。任務、資料來源、模型、工具與使用方式都會改變，治理需要跟著版本與實際錯誤持續更新。
先建立清楚的責任分工
| 角色 | 主要責任 |
|---|---|
| 業務負責人 | 定義任務價值、完成條件與可接受風險 |
| 資料擁有者 | 管理資料版本、品質、權限與保存期限 |
| 技術負責人 | 模型、工具、狀態、監控、回復與成本 |
| 領域專家 | 提供規則、例外、驗收標準與錯誤判斷 |
| 資安／法遵 | 審查身份、資料、供應商與高風險操作 |
| 實際使用者 | 回報誤判、流程摩擦與人工修改 |
小型團隊可以由同一人兼任多個角色，但責任仍要能被說清楚。技術團隊不能自行決定業務結果是否正確，業務團隊也不能忽略權限與資料風險。
資料治理要進入Agent的每一步
- 來源：資料來自哪個系統或文件，是否為正式版本。
- 擁有者：誰負責更新、修正與批准用途。
- 敏感度：公開、內部、機密、個資或受管制資料。
- 用途：可否用於摘要、決策、外部輸出或模型改善。
- 保存：輸入、Session、Artifact與Trace保存多久。
- 刪除：使用者撤回或資料過期後如何移除。
Agent產出的摘要、分類、推論與草稿也是企業資料。系統要區分原始事實、模型生成內容與人工確認結果，避免未驗證輸出被其他系統當成正式資料再次使用。
身份與委派權限如何設計？
能代表使用者行動的Agent，需要可識別身份。系統應知道哪個使用者啟動任務、哪個Agent或Workload執行、使用哪個Client連接資源，以及實際Resource Server接受了什麼Scope。
- 使用短效Token，不使用永久共享憑證。
- 按任務授予最小Scope，完成後撤銷。
- 不同Agent、環境與客戶使用不同Credential Namespace。
- 對外寫入保留Delegation與核准紀錄。
- 禁止Agent把Token寫入Prompt、Memory、Artifact或日誌。
只需讀取報表的Agent不應取得刪除或付款能力；能建立草稿的Agent也不必直接發布。完整身份與OAuth設計，可延伸閱讀AI Agent身份與授權完整指南：OAuth、Delegation、Scope與審計。
工具權限應按風險分級
| 層級 | 操作 | 建議控制 |
|---|---|---|
| 低風險 | 搜尋、查詢、內部摘要 | 來源限制、Read-only、抽樣檢查 |
| 中風險 | 建立草稿、測試分支、內部分類 | 版本、Schema、人工抽查 |
| 高風險 | 寫入正式資料、寄信、對外更新 | 明確核准、冪等、回退與日誌 |
| 重大風險 | 付款、刪除、權限與合約承諾 | 雙重核准、限額、強身份與人工執行 |
權限必須由Runtime、API Gateway、資料庫與外部系統強制執行，不能只在Prompt裡要求模型「不要做」。Prompt Injection或模型誤判都可能越過文字規則，但不能越過真正的系統權限。
稽核紀錄至少要回答六個問題
- 誰啟動任務，代表哪個組織或使用者。
- 使用哪個模型、Prompt版本與工作流版本。
- 讀取哪些資料、來源與時間範圍。
- 呼叫哪些工具，使用什麼參數與Scope。
- 哪些節點由人核准、拒絕或修改。
- 最終結果、費用、錯誤與回復狀態是什麼。
Trace需要足以重建事故，但不應無限制保存完整個資、Secrets與敏感輸出。遮罩、分級保存、存取角色與保留期限本身也要接受稽核。
驗證與持續評估怎麼做？
- 建立正常、缺漏、矛盾、越權與工具失敗案例。
- 分別測試模型、Prompt、Tool、Workflow與權限版本。
- 追蹤通過驗收率、人工推翻率、錯誤影響與回復成功率。
- 供應商或模型更新後重跑相同Eval。
- 把真實事故與人工修改加入回歸測試。
治理指標不能只看生成速度或Token價格。每個有效任務的總成本還包括工具、人工覆核、錯誤修正、監控、法遵與維護。
事故發生後的處理順序
- 立即停止相關Agent、Token與高風險工具。
- 保存任務ID、Trace、資料版本與外部系統狀態。
- 確認影響範圍、受影響使用者與是否可回復。
- 撤銷錯誤寫入、恢復版本或啟動補償操作。
- 由業務、技術、資料與資安共同判斷根因。
- 更新權限、流程、測試與通報規則後再重新開放。
若系統無法停用單一Agent、撤銷Token或回到可靠版本，就不適合取得高影響權限。
企業試點與治理如何分工？
治理頁回答「企業應建立哪些長期控制」；試點計畫則回答「四週內怎麼執行」。實際導入可先閱讀AI Agent導入30天計畫：任務盤點、Shadow Mode與上線Gate，再用本文建立正式權限、責任與稽核架構。
單一任務如何寫成可交付規格，可接著閱讀企業AI Agent任務怎麼定義？Task Contract、例外與人工接手範本。
常見問題
小型企業也需要AI治理嗎？
需要，但可以從責任表、資料清單、權限分級、操作紀錄、測試集與停損條件開始。治理的目的不是增加文件，而是讓錯誤能被限制、發現與回復。
Agent可以共用員工帳號嗎？
不建議。共用帳號會失去可追溯性，也難以撤銷單一Agent權限。應使用可識別Workload Identity或受限委派Token。
什麼時候可以降低人工核准？
只有任務低風險、可逆、驗證可自動化，並在足夠真實案例中維持穩定時，才適合降低確認頻率。付款、刪除、權限變更與公開承諾通常仍應保留控制點。
資料來源與延伸閱讀
- NIST：AI Risk Management Framework
- OpenAI：A practical guide to building agents
- Anthropic：Building effective agents
- Coding Agent上線驗收：12項安全測試
- Coding Agent資料流、保留與ZDR
企業AI Agent治理的目的，是讓自主行動保持可識別、可限制、可驗證與可撤銷。當責任與權限清楚，Agent才有條件從試用工具進入日常營運。
治理後的上線與採用
治理規則確認後，企業還要把 PoC 驗收、正式上線、監控、事件回應與員工採用接成同一條生命週期。
分享此文：
KEEP READING
接著讀什麼？
從同一主題繼續閱讀，或回到 YOLO LAB 的完整文章索引，找到下一個值得投入時間的問題。
發表迴響