AI Agent 入企業流程前，先補上權限、成本與稽核三道閘

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-11

iThome 報道指出，隨着公部門開始把 AI Agent 放入日常工作，部署焦點正由「選哪一個模型」轉為「如何讓 Agent 在既有流程內受控工作」。這個轉變同樣影響企業、機構及公共服務單位：一個可讀取文件、調用 API、比較多個系統資料，甚至主動寄信的 Agent，其風險已遠高於單純聊天工具。若仍只以模型準確度衡量成效，很容易在真正接入資料與業務系統時才發現權限、成本和責任歸屬未有安排。

最重要的限制是，來源內容主要來自 Headquarter.aii 共同創辦人暨行政總裁黃建璋的觀點及個案分享，並非一套已獲普遍驗證的公部門標準。因此，機構不宜把文中的自動化模式直接套用到所有高風險工作。不過，iThome 所整理的權限、用量及稽核三個治理面向，正好可化為部署 AI Agent 前的最小檢查清單；尤其當 Agent 開始跨越部門、模型供應商和內部系統時，這些基礎控制不能留待事後補救。

先決定 Agent 是助手還是可放行的數碼員工

iThome 報道把 Agent 的部署模式分成兩類：其一是 human-in-the-loop 的人機協作，由 AI 處理大部分工序，待人員覆核才進入下一步；其二是可自行完成流程的自主 Agent，只在異常情況或事後稽核時由人員介入。兩者分別並不在於模型有多聰明，而在於工作是否容許錯誤自行流轉，以及人類覆核能否真的帶來額外價值。

公文、審查及行政決策等涉及專業判斷或後果較重的工作，來源建議保留人工覆核。相反，郵件分類、文件整理、跨系統資料比對等高頻而規則清楚的工序，若每次都要人員逐件確認，覆核所花的時間，可能抵銷 AI 節省的人手，未必合乎成本效益。這是一項很實際的取捨：人機協作有助壓低誤判影響，卻會減少自動化收益；自主 Agent 可以提升吞吐量，前提是輸入、判斷準則、例外處理及回復安排已經足夠成熟。

從部署角度看，機構可先以三個問題篩選流程：工作是否持續而大量出現、判斷標準是否能清楚說明、以及 Agent 是否只需在明確授權下連接內部系統。iThome 報道列舉的公文分流、資格審查和資料比對，都符合這些特徵。若一項工作高度依賴個案脈絡、價值取捨或不可逆決定，較穩妥的做法是讓 Agent 準備資料、標示風險與草擬內容，把最後決定留給負責人員。

權限不能沿用「代替員工登入」的模糊做法

iThome 指出，第一項治理重點是身分與權限：組織必須先釐清 Agent 是以哪一種身分讀取系統，包括代表某名使用者、作為受委派的代理身分，還是擁有獨立身分，並與既有身分管理機制整合。這看似是技術細節，實際上決定事故發生後能否辨識誰授權、哪個 Agent 執行，以及它為何擁有相應資料存取權。

可操作的原則是把每個 Agent 視為獨立的數碼角色，而非共用帳戶下的一段自動化程式。它應只取得完成指定任務所需的最低權限；可查閱哪些資料庫、可調用哪些 API、可否寫入或寄出內容，都要分開設定。對外連線亦應以明確的工具或 API 邊界處理，避免外部 Agent 直接接觸內部核心系統。iThome 提及以 Agent-to-Agent 的安全存取架構建立邊界，所反映的正是這個需求：系統之間需要可控的授權通道，而不是把內部資料一次過交給模型。

這也會改變採購及系統整合的提問方式。與其只問供應商「支援哪些模型」，機構更應確認 Agent 能否在不同模型與工具之間維持一致的身分規則、權限撤銷和紀錄格式。iThome 引述黃建璋的看法，模型排行榜變動很快，若系統綁死單一模型，日後升級和轉換會變得困難。採取模型中立架構不保證風險會消失，但能避免每次更換模型時都重建一套權限與稽核控制。

Token 成本要能追到人、Agent 與一次工作

第二道閘是用量管理。傳統軟件授權或雲端帳單，未必足以說明 AI Agent 的真正成本，因為一次工作往往同時包含多輪模型調用、檢索資料、工具執行及 API 呼叫。iThome 報道建議把 Token 用量細分至使用者、Agent 和 Agent 工作階段，並可按使用者或群組、按 Agent 或工作流程拆帳。這讓管理者不只看到總額，也能知道哪一類任務正在推高資源消耗。

對營運團隊而言，這種拆帳資料有兩層用途。第一是成本控制：當某個流程的用量突然上升，可以追查是輸入文件變大、Agent Loop 重試過多、工具失敗後反覆調用，還是有人把不適合的複雜工作交給 Agent。第二是效益評估：若一個 Agent 用量高昂，卻只縮短少量人手時間，便應調整流程或改回人工覆核。這是分析上的合理延伸，而非來源已證實的因果；重點是預算不能只按模型供應商總帳單管理。

來源亦提到完整 AI Agent 除了大型語言模型，還包括工具、prompt、上下文和可規劃、反覆執行任務的 Agent Loop。正因為工作結果由多個部分共同造成，成本紀錄也應包含調用了甚麼模型與工具、工作在哪一步停止或重試。否則，團隊即使知道 Token 上升，也難以判斷應限制使用者、收窄工具權限，還是修正流程設計。

稽核紀錄要回答「它做過甚麼」

第三道閘是可追溯稽核。iThome 報道指，紀錄應覆蓋 Agent 使用了哪些模型、調用了哪些工具，以及存取了哪些資料。對涉及客戶、個案或內部文件的流程，單靠保存最終輸出並不足夠：一份錯誤報告可能源於不適當的資料來源、過期上下文、越權工具調用，或模型在中途改變了工作路徑。沒有完整操作軌跡，事後很難修正控制，也難以向內部審查人員交代。

稽核亦與人員能力傳承有關。iThome 報道以社工個案說明，若 AI 直接完成整份報告，使用者或會逐漸失去思考及學習機會；來源建議把協助撰寫與督導檢閱拆分為不同角色，讓 AI 指出知識缺口並推薦相關資料。這個例子不應被直接推論至所有部門，但它提醒管理者，Agent 的成功指標不應只看省時，也要看專業判斷是否仍由合適的人員掌握，以及覆核者能否理解並質疑 AI 的依據。

隨着試用由零散聊天工具延伸至 Agent，組織或需面對跨模型、跨部門管理的平台需要。當 Agent 數目增加，最先受影響的未必是模型選型，而是身分管理、財務拆帳、資訊保安和業務覆核團隊。對準備擴大部署的機構來說，先把每個 Agent 的身分、可用工具、成本歸屬、紀錄範圍及人工介入門檻寫清楚，較有機會把自動化放在可承受的風險範圍內。