在 AMCIS 2026 Proceedings 發表的一篇研究，將企業 Agent 的治理問題由「模型是否透明」推向另一個層次：當 Agent 擁有 delegated authority，可以實際執行工作時，誰控制它的自主行動、錯誤如何傳播、合規責任由誰承擔？作者認為，這些問題不能只靠模型說明文件或最後一次人工檢查解決，還要在 workflow 的架構中設計控制點。
研究的出發點，是企業 Agent 已由 predictive support 走向 execution-capable systems。這個轉變令錯誤、compliance exposure 和 accountability ambiguity 變得更直接，因為 Agent 不只是提出建議，還可能在授權範圍內呼叫工具、更新資料或推動下一步工作。對產品團隊而言，治理因此不再是上線後附加的政策頁，而是應該跟 autonomy、權限、工作分工和風險一起被設計。
作者提出一個以 kernel theory 為基礎的 governance-by-design framework，把 governance configuration 視為一個較高層次的組合，包含 autonomy calibration、human-agent teaming，以及 embedded machine learning guardrails。研究把 autonomy 當作可配置的設計變數，主張監督強度要跟 workflow risk 對齊。低影響、可回復的工作可以有較少介入；涉及外部承諾、敏感資料或不可逆行動的流程，則需要更嚴格的控制。
方法上，作者採用 Design Science Research，設計並比較五種 governance configurations。論文摘要表示，架構上的對齊會影響 workflow performance、compliance adherence、appropriate reliance 和 accountability clarity。這些結果應該理解為該研究框架下的比較發現；要把它推廣到不同行業、模型和組織，仍需要閱讀完整實驗設計和進一步驗證。
對實務落地來說，這項研究提供一個比「所有 Agent 都要人手批准」更精準的方向。團隊可以先按行動風險分級，再決定哪些步驟需要人工確認、哪些工具只能讀取、哪些變更要有雙重授權，以及每次執行要保存甚麼 evidence。這不是把人移出流程，而是讓人的注意力集中在不可逆、難以回復和責任敏感的節點。
同樣重要的是，治理要能夠跟 workflow 一起被測試。除了測模型答案，團隊還應驗證 Agent 在權限不足、工具失敗、上下文不完整和多步驟錯誤時會怎樣停下來、升級或回復。若控制只存在於文件而不在執行架構內，實際行動路徑就可能比規則描述更寬。這一段是基於研究主題作出的工程解讀，不是論文摘要直接宣稱的產品功能。
這篇 AMCIS 研究的核心提醒，是 agent governance 應該被視為 workflow architecture，而不是單一的安全開關。企業在引入可執行 Agent 前，可以先畫出授權邊界、資料流、工具流、人工交接和回復路徑，再選擇合適的 autonomy calibration。當 Agent 的能力愈接近實際營運，治理設計就愈需要成為流程本身的一部分。
