摘要： AI 與低程式碼工具讓更多員工能自行打造應用與工作流程，企業內部卻累積出一層難以追蹤的技術。針對這道缺口，Forbes 在 2026 年 10 月邀集 CIO、CTO 等高階主管提出治理建議，OneReach.ai 也發表了對應分析。對 builder 來說，重點很具體：工具上線前先回答「誰掛名負責」，並讓治理跟著執行階段走，而不是停在登記表上。
為什麼 RPA 時代的教訓，這次更難處理
把建置權交給最懂流程的業務人員，並不是新鮮事。開發代理人協作與治理平台的 OneReach.ai 在分析中指出，十年前的 RPA 就讓這件事發生過一次。差別在於：RPA 機器人很脆弱，介面一改就停擺，錯誤反而自己會浮出來；AI 代理人則能繞過障礙、找替代路徑繼續行動，超出範圍時產生的不是錯誤訊息，而是沒有人核准過的結果。
這正是治理人員最頭痛的地方。你在監控儀表板上看到的不再是「有東西壞了」，而是「有東西在正常運作，但你不知道它為什麼會這樣做、誰核准的」。
先指定具名負責人，答不出名字就不上線
幾位專家把問題收斂到同一點：具名負責人。NEWWORK Software 的 Michael Jaszczyk 主張，沒有具名負責人的 AI 代理人一律不得上線，權限只限於角色實際需要，任何動作觸及核心紀錄系統前都要通過政策檢查，並能追溯到負責人。
Hawksroost 的 Chris Jay Hawkinson 建議每個員工自建的工具（公民開發）上線前都先回答一個問題：「這個工具做出的決策，由誰負責？」他認為審核關卡與登記庫會失效，正是因為沒有人對登錄項目負責；決策歸屬不會失效，因為問責本身就會留下紀錄。
OneReach.ai 把要求再推細一層：負責人必須是個人而非團隊，且要負責在代理人不再需要時將它下架。權限方面，代理人應使用專用的服務帳號登入，不要沿用建置者的個人帳密，並依最小權限原則開放存取。這一點和 API 金鑰管理的基本功是同一件事——我們之前談過的推理容量與存取設計該照實際使用形狀來算，背後思路一致：資源的歸屬要先講清楚，後面的治理才有抓手。
登記庫告訴你昨天，可視性告訴你現在
有了負責人，還得隨時看得到工具在做什麼。Appian 的 Gregg Aldana 主張所有 AI 代理人、低程式碼應用與自動化都要透過受治理的協作層運行，具備具名負責人、權限邊界、稽核軌跡與緊急停止開關。他的說法很直接：登記庫只能告訴企業昨天有什麼，執行階段的治理才告訴你現在有什麼正在運作。
Innovaccer 的 Abhinav Shashank 補充了要記錄的內容：工具讀取哪些資料、做出哪些決策、能自行執行哪些動作。讀取與執行是不同層級的權限，要分開記錄，而且要在工具建立時就完成——否則系統出問題時，你才知道原來有它在跑。
三個機制，對應三種風險
- 代理監控代理：Sainapse 的 Abhirup Ghosh 建議把高風險工作交給前沿模型處理，並讓這些前沿代理人負責監控其他代理人。
- 強制登記：Nasuni 的 Nick Burling 主張建立強制性 AI 資產登記庫，凡是用 ChatGPT、Claude、Copilot 或自動化工具產出的成果，都要記錄擁有者、用途、版本與審查日期，部署前經過核准。
- 憑證管理：SpyCloud 的 Damon Fleury 指出，AI 與 low-code 工具大量使用 API 金鑰、權杖與服務帳號，形成沒有人刻意開通、也沒有人監控的「影子存取」，攻擊者已在利用。他建議開通時就指定具名負責人並持續監控。
治理往前移，不要做成事後檢查點
最值得 builder 細看的是治理位置前移的兩個主張。OneReach.ai 提出「治理即設計」：傳統做法把治理當成建置完成後的檢查點，等到審查時代理人早已上線、連線與預設值都設定完成；應該在建置當下，就由架構強制套用存取控管、紀錄與資料處理規則。Droma 的 Casey Kindiger 更進一步，認為登記庫、負責人與停止開關本質上是控制機制，控制無法隨自建 AI 的規模擴大；他主張用 MCP 等標準統一工具層，把信任設計成可衡量、依情境調整的原則，讓 AI 的自主權依證據與風險被授予、擴大或撤回。
對正在規劃內部 AI 工具的團隊，一個務實的起點：把你手上每個上線中的自動化列一遍，確認每個都有具名負責人、專用服務帳號與執行階段的紀錄。答不出名字的那幾個，就是該先停下來處理的。