Dataiku Agent Management 上線前，企業怎麼盤點 AI Agent？2026 清單

優先做跨平台 Agent 盤點，不必等 Dataiku Agent Management 正式開放；只要 Agent 分散在不同平台或自建環境，就先整理清冊、責任人與風險，再核對監控、認證及執行環境控制。Dataiku 在 2026 年 9 月 24 日宣布產品計畫於 2026 年 10 月正式開放；確切日期與屆時支援範圍仍待官方更新，產品可見性也不等於執行控制。官方公告

這篇適合你，如果：
你負責盤點多平台或自建環境中的 Agent，並要確保清冊能持續更新。
你要優先識別敏感資料、客戶服務或交易流程中的高風險 Agent。
你需要為每個 Agent 找到業務責任人，並訂出繼續運行、限制或暫停的依據。

最後更新於 2026 年 9 月 26 日；開放時間、產品定位及支援範圍核對自 Dataiku 官方公告與產品部落格。

Dataiku Agent Management 上線準備：先分清楚可見與可控

Dataiku 表示，Agent Management 的定位包括跨平台發現 Agent、監測運行情況及管理風險；官方也披露了平台接入範圍，以及透過 OpenTelemetry 支援自訂環境的方式。產品說明不代表所有平台和自建環境都已接通，更不構成對監控效果的獨立驗證。

你要先分清楚四件事：資產發現回答有哪些 Agent；運行監控回答觀測到什麼；風險評估與認證紀錄回答誰根據什麼證據作出判斷；權限控制與執行環境才限制 Agent 實際能做什麼。不能拿其中一項代替另一項。

盤點面向	你要確認的內容	不足時的處置
資產與依賴	Agent 識別資料、平台、部署環境、資料連線、模型與工具依賴	標記來源與核驗狀態；未知項目列待查
業務責任	用途、使用對象、建立團隊、日常營運團隊及業務責任人	找不到責任人或用途不明，先列待確認
風險與權限	資料敏感度、外部工具、副作用、人工審批及可執行操作	高影響動作暫停、限縮或增加人工核准
監控與驗收	健康狀態、使用情況、成本、品質和行為變化各自的證據	設定人工處置路徑，補上交付測試證據
認證與複核	風險紀錄、測試結果、認證狀態與更新責任	證據不足時補測，不以狀態標籤放行

平台工程：建立可持續更新的 Agent 清冊

你的清冊要能回答「這筆資料從哪裡來」以及「最近一次何時核實」，而不是只列出產品儀表板能顯示的 Agent。對每個項目記錄穩定識別方式、執行平台、部署環境、資料連線、工具與模型依賴，再標明資訊來源及最後核驗狀態。

Dataiku 公布的接入範圍應視為產品披露的支援資訊；對未列明的自建環境或內部工具，先由平台團隊人工登記，再確認能否取得所需遙測資料。OpenTelemetry 文件說明，插樁是讓軟體產生遙測資料的方式；有插樁不代表事件內容必然完整，也不代表所有環境已自動接入。OpenTelemetry 插樁說明

業務與研發：把用途和責任人分開核實

每個 Agent 都要有可識別的業務目的、預期使用對象、負責團隊，以及能決定繼續運行或暫停的責任人。建立 Agent 的團隊可能不等於日常營運團隊；平台帳號或專案擁有人也不必然承擔業務責任。請把這些角色分欄記錄，並在組織調整或用途變更時重新核對。

用途描述要能對照實際工作，例如它會讀取什麼資料、呼叫哪些工具、輸出交給誰，以及輸出後是否會觸發外部動作。若用途已偏離原設計，或沒有人願意承擔後續責任，就先放入待確認清單，不要因為 Agent 還在運行便預設核准。

安全與治理：依實際影響安排風險複核

先審查面向客戶、接觸敏感資料、能執行交易或會改動外部系統的 Agent。每筆風險紀錄至少要交代資料存取範圍、外部工具、副作用、人工審批邊界，以及失敗時誰能停止操作。高風險項目要有相應測試與複核責任；沒有足夠證據時，應限制範圍、暫停高影響動作或補測。

NIST 的生成式 AI 風險管理框架及 AI RMF Playbook 可用來組織風險識別與管理工作，但企業仍須用自己的政策、情境和證據決定風險等級。NIST 生成式 AI 風險框架與AI RMF Playbook不是廠商功能的安全認證。OWASP 的 Agent 安全清單則可輔助檢視權限、工具使用等安全面向。OWASP Agent 安全清單

監控能指出資料中出現的狀態或行為變化，不能單獨證明業務結果正確、程式碼已通過測試，或任務已安全交付。請把「觀測紀錄」與「驗收證據」分開保存。

運維、審計與財務：把觀測、證據和成本放回同一條鏈

運維團隊要逐項標示健康狀態、使用情況、成本、品質和行為變化由什麼資料支撐，以及資料缺失時由誰人工處置。OpenTelemetry 將追蹤、指標和日誌等列為不同訊號；實際能觀測到什麼，取決於環境是否產生並收集相應資料。OpenTelemetry 訊號說明

審計負責人則要讓風險紀錄、測試證據、認證狀態和複核責任可以追溯至 Agent 的版本或設定變更。只保存一個「已核准」狀態，不足以回答核准依據是否仍適用。財務與技術管理者可把用量、成本、業務價值和風險放在同一份審查資料中；Dataiku 公告提及計價方式，但企業實際支出與所需執行環境容量，仍須依自身任務與帳務資料評估，不應從功能描述推算。官方公告

FAQ：正式開放前的盤點與控制邊界

Agent 清冊應記錄哪些資訊？
記錄識別方式、運行平台、部署環境、資料連線、工具和模型依賴，以及用途、責任人、風險、資訊來源與最後核驗狀態。未確認的欄位要明確標為待查，不能把產品已接入的範圍視為企業全體 Agent 的完整清冊。

多平台 Agent 的負責人和用途怎樣登記？
分開登記建立者、日常營運團隊和業務責任人，並以可核對的任務、資料和使用對象描述用途。若找不到責任人，或實際用途偏離原設計，先列待確認；不要以平台帳號歸屬代替業務責任，也不要預設該 Agent 可繼續執行高影響操作。

哪些 Agent 應先做風險分級和認證複核？
優先處理面向客戶、接觸敏感資料、執行交易或會改動外部系統的 Agent。企業要依自身資料分類、權限政策、測試結果和人工審批邊界定級。缺少責任人或複核證據時，先限制操作或補測，不要把廠商風險標籤當成安全認證。

監控紀錄能取代權限或隔離環境嗎？
不能。監控紀錄呈現的是已收集到的運行資訊，並不會自動限制工具、憑證或資料存取，也不能證明交付安全。你仍須在 Agent 執行環境中設好權限與隔離，安排人工核准、停止方式及獨立的測試驗收證據。

可勾選的落地檢查清單

• [ ] 建立跨平台清冊，為每筆 Agent 記錄識別資料、運行平台和部署環境。
• [ ] 補齊資料連線、模型、工具、權限及資訊來源，並標示最後核驗狀態。
• [ ] 分開確認建立團隊、日常營運團隊與業務責任人。
• [ ] 寫明用途、預期使用對象和繼續運行的條件；無法確認的項目列為待查。
• [ ] 先複核面向客戶、處理敏感資料、執行交易或造成外部副作用的 Agent。
• [ ] 將監控訊號、品質驗收、程式測試和安全交付證據分開記錄。
• [ ] 確認風險與測試紀錄能對應版本或設定變更，並指定後續複核責任人。
• [ ] 對缺少證據的項目設定處置：補測、縮小範圍、限制高影響操作或暫停。
• [ ] 同時檢視用量、成本、業務價值與風險；成本無法說明的項目先查明來源。

用清單決定環境，不以可見性代替控制

當清冊能說明 Agent 做什麼、由誰負責，以及有哪些監控訊號，下一步是檢查 Agent 實際在哪裡執行、憑證如何限制、資料和網路邊界如何設定。監控能提高運行可見性，卻不能代替執行權限、隔離環境或交付驗收；對證據不足的高風險項目，先限縮操作，再補足控制與測試。

如果你目前依賴多平台儀表板、人工對表或共用執行環境，常見缺口是清冊更新容易中斷、責任人與帳號歸屬混淆，以及監控資料和權限控制各自分散。先為需要隔離或可重現交付的 Agent 補上環境驗收證據；若任務涉及真實 macOS 工具鏈，再把 vmzig 的 Mac 環境納入選型比較。若不需要 macOS 專屬工具鏈，自建環境或其他合適的執行方式可能更直接，不必為了盤點而更換平台。

常見問題

正式開放前，Agent 清冊至少要記下哪些資料？

每筆至少要能辨識 Agent、用途、負責團隊、運行平台與部署環境，並記錄資料連線、模型及工具依賴、權限、副作用和資訊來源。也要標示最後核驗狀態；尚未確認的平台或欄位應明確列為待查，不能因為產品能顯示部分資產就當成全公司清冊完整。

不同平台上的 Agent，怎樣登記負責人和業務用途？

分開記錄建立者、日常營運負責團隊，以及能決定繼續運行或暫停的業務責任人。用途要寫成可核對的任務與使用對象，而非只填部門名稱。若找不到負責人、用途已偏離原設計，先標記待確認並限制高影響操作，不要把平台帳號持有人直接視為業務所有者。

哪些 Agent 應先做風險分級和認證複核？

先查面向客戶、處理敏感資料、可執行交易或會對外部系統造成副作用的 Agent。分級依企業自己的資料分類、權限規則、測試結果與人工審批邊界決定。高風險項目若缺少可追溯測試或複核證據，應暫停高影響操作、縮小可用範圍或補測，而不是把廠商標籤當成安全認證。

Agent 監控資料足以取代權限控管或隔離環境嗎？

不足。監控能呈現所收集到的運行訊號和變化，不能自行限制 Agent 可呼叫的工具、憑證或資料，也不能證明任務結果正確、程式已通過測試或交付安全。你仍須在執行端設定最小權限、網路與資料邊界、人工核准及可停止機制，並分開留存驗收證據。