你在財務部門做了一個 AI agent。它可以讀取 ERP 裡的發票與採購單，找出金額或供應商資料不一致的項目，再把例外送給財務同仁處理。這裡的 agent，可以先理解成「會自己連續執行幾步任務的 AI 助手」。

測試時，團隊為了省事，讓它沿用某位財務人員的帳號。查詢成功、異動也成功，看起來很順。直到有人問：「這筆供應商銀行資料是員工本人改的，還是 AI 代他改的？」日誌只留下同一個人類帳號，已經無法直接回答。

2026 年 7 月，AWS 公開一套 ERP 例外自動化做法，其中包含獨立的 agent 身份、依政策判斷的授權、可稽核動作與人工升級。值得帶回自己系統的重點，不是照抄某個 AWS 或 SAP 元件，而是把 AI 從人類帳號後面拉出來：讓系統能辨認「誰發起、為什麼執行、改了什麼，以及哪位人員核准」。

這堂微課要回答一個實際問題：當 AI agent 開始接觸 ERP 裡的真實財務資料，該怎麼限制它的權限，讓它能處理低風險工作，卻不能自行執行高風險操作？

In this lesson

你會完成五件事：

  1. 找出共用人類帳號造成的追責缺口。
  2. 替 AI agent 建立可停用、可稽核的獨立身份。
  3. 把授權規則改成預設拒絕，再逐項開放必要動作。
  4. 為高風險例外設定人工升級與日誌要求。
  5. 用一小批唯讀案例試跑，不直接碰正式異動。

共用人類帳號，會讓三種紀錄混在一起

ERP 通常已經知道哪位員工登入、查了哪些資料、送出哪些異動。問題出在 AI agent 沿用員工帳號後，日誌裡的「操作者」不再等於真正採取行動的一方。

例如，財務人員登入後啟動 agent。agent 先查採購單，再讀取發票，最後更新例外案件狀態。如果所有請求都使用同一組人類憑證，事後只能看見「王小明做了三個動作」，卻看不出：

  • 王小明親手要求了哪一項工作。
  • agent 自己選擇了哪些後續步驟。
  • 哪個步驟只是讀取，哪個步驟改動了 ERP 資料。
  • 異動前是否真的出現人工確認畫面。
  • agent 是否嘗試過被拒絕的操作。

這不只影響事故追查，也會讓權限收回變得困難。你可能只想停用 agent，卻因為它與員工共用身份，只能連員工的正常工作一起中斷。

如果你還沒盤點 agent 授權時應留下哪些答案，可以接著使用AI agent 授權四問表：身份、權限、理由、後果，把每次操作拆成可查證的四個欄位。

廣告

第一步：建立獨立身份，不只換一個帳號名稱

獨立身份的最低標準，是 ERP、身份系統與稽核日誌都能把 agent 和人類操作者分開。只在顯示名稱後面加上「Bot」還不夠；系統必須能單獨授權、停用與查詢這個身份。

替 agent 建立身份時，至少記下以下內容：

  • 身份名稱：綁定單一用途，例如 ap-invoice-exception-agent，不要使用可被多個流程共用的 finance-ai。
  • 服務範圍：寫明它能連到哪個 ERP 環境、公司代碼或資料區域。
  • 身份負責人：指定一位能核准權限、處理警報並停用身份的人。
  • 認證方式：使用系統可輪替、可撤銷的機器身份憑證，不把員工密碼或瀏覽器工作階段交給 agent。
  • 有效期限：測試身份在試跑結束時失效；正式身份也要有固定複查日期。
  • 日誌識別欄位：每次請求都能同時記錄 agent 身份、觸發它的人或工作流，以及單次執行編號。

這裡的關鍵是把「誰啟動」和「誰執行」分開。使用者可能是觸發者，agent 才是向 ERP 發出查詢或異動請求的執行者。兩者都要留下，不能用其中一個覆蓋另一個。

第二步：從預設拒絕開始，逐條寫出允許條件

預設拒絕的意思是：沒有被明確列入允許規則的動作，一律不執行。agent 不能因為「完成任務可能需要」就自行取得相鄰權限。

別只寫「agent 可以處理應付帳款例外」。這句話涵蓋查詢發票、讀取供應商資料、修改付款狀態、更換銀行帳戶與釋放付款，風險完全不同。授權規則要落到「物件、動作、條件、出口」四個部分。

ERP 動作自動允許條件拒絕或升級條件必留紀錄
讀取發票與採購單僅限被指派的公司代碼；單次最多 50 筆；欄位不含完整銀行帳號跨公司代碼、超過 50 筆或要求未列入白名單的欄位時拒絕查詢條件、筆數、回傳欄位、執行編號
標記「等待人工檢查」發票已存在，且 agent 只新增狀態與原因碼原狀態已是「核准付款」或案件已關閉時拒絕修改前後值、原因碼、來源文件編號
草擬例外說明只產生草稿，不寫回正式備註欄草稿含銀行帳號、稅務識別碼或未授權個資時遮蔽並升級輸入文件、遮蔽結果、草稿版本
修改供應商主檔不自動允許任何地址、稅務資料、收款人或銀行資料異動都送人工核准申請人、差異內容、核准人、核准時間
釋放或執行付款不自動允許無論金額多少都要求 ERP 內的指定核准角色確認核准鏈、付款批次、agent 建議與最終決定

表中的數字是試跑用的示範門檻，不應直接當成所有公司的正式政策。真正部署時，要根據工作量、資料敏感度與現有核准制度調整；但每條規則仍必須有可由系統判斷的數字、欄位或狀態，不能只寫「高風險時交給人工」。

權限也要按動作拆分。讀取、草擬、標記與正式異動不該綁成同一包。如果團隊正在設計這條界線，可參考常駐 AI 助理要先學會停手，才適合接進主要帳號，進一步區分「可讀」、「可準備」與「必須等人確認」。

第三步：讓每次授權都帶著當下情境

即使 agent 擁有讀取發票的權限，也不代表它在任何時間、任何來源或任何數量下都能讀。授權檢查應該在每次操作發生時重新判斷，而非登入成功一次就一路通行。

一項操作送進 ERP 前，可以依序問：

  1. 這是哪個身份？ 必須是指定的 agent 身份，不能退回共用帳號。
  2. 它要操作什麼？ 明確到 ERP 物件、動作與欄位，例如「讀取發票金額與採購單編號」。
  3. 這次為何需要？ 請求必須帶有案件編號或工作流執行編號，無法對應任務就拒絕。
  4. 是否落在允許範圍？ 檢查公司代碼、資料欄位、筆數、案件狀態與執行環境。
  5. 是否碰到人工邊界？ 供應商主檔、銀行資料、付款釋放與核准狀態等動作，直接轉人工。

這樣做會讓規則比單純角色權限更具體。同一個 agent 可以在「讀取 20 筆指定發票」時獲准，卻在「匯出整個供應商清單」時被拒絕。身份沒有變，當下情境不同，結果也應不同。

第四步：把人工升級做成流程，不要只發通知

很多團隊把「人工介入」做成一封 email 或聊天訊息，但 agent 仍繼續執行後面的步驟。真正的人工升級必須讓工作流停在一個可辨認的狀態，直到指定人員在 ERP 或核准系統內作出決定。

你可以用以下文字決策樹檢查每個例外：

agent 提出下一個 ERP 動作
├─ 規則沒有明確允許
│  └─ 拒絕，記錄嘗試，不自動改用其他身份重試
├─ 規則允許，但觸及人工邊界
│  └─ 暫停案件，產生差異摘要，送指定角色核准
│     ├─ 核准：使用原執行編號完成指定動作
│     └─ 拒絕或逾時：結束執行，不做後續異動
└─ 規則允許，且未觸及人工邊界
   └─ 執行，記錄輸入、規則結果與修改前後值

人工核准畫面至少要顯示：agent 想做的動作、資料修改前後差異、觸發原因、套用的規則，以及核准後還會發生哪些後續動作。只顯示「是否允許 AI 繼續？」會迫使核准人盲目同意。

另外要禁止一個常見的失敗出口：agent 被拒絕後，改用觸發者的人類身份重試。如果這條備援存在，獨立身份與預設拒絕都會失去作用。

第五步：日誌要能還原一次完整決定

「有記錄」不代表「能追責」。如果日誌只留下成功或失敗，事後仍無法知道是哪條規則放行、誰核准，以及 agent 實際改了哪些值。

每次執行至少要串起這些資料：

  • 單次執行編號。
  • agent 身份與版本。
  • 觸發者身份或排程名稱。
  • ERP 物件、動作與目標欄位。
  • 請求發生前的資料狀態。
  • 命中的允許、拒絕或升級規則。
  • 人工核准人的身份、時間與決定。
  • 修改前後值，或明確的「未修改」。
  • 被拒絕的嘗試與拒絕原因。

日誌本身也要限制存取，尤其當其中包含發票、供應商或付款資料。若 agent 使用的憑證、工作流或連接器出現暴露風險，可以用AI workflow builder 憑證暴露檢查清單確認止血、保全日誌與輪替順序，避免新憑證再次被同一入口讀到。

最小試跑：只選一種例外、兩個動作

第一輪不要讓 agent 處理整條應付帳款流程。選一種發生頻率足夠、但不需要直接付款的例外，例如「發票金額與採購單不一致」。

把試跑限制成兩個動作：

  1. 讀取被指派案件的發票金額與採購單金額。
  2. 產生差異摘要，並把案件送入人工檢查清單。

試跑期間採用 dry-run，也就是先試跑但不真的修改正式資料。準備至少 20 個已知結果的歷史案例，其中包含：正常匹配、金額不符、缺少採購單、跨公司代碼，以及要求讀取未授權欄位的案例。

只有在以下結果都能從日誌直接驗證時，才考慮開放第一個低風險寫入動作：

  • 20 個案例都能辨認 agent 身份與觸發者。
  • 跨公司代碼與未授權欄位的請求全部被拒絕。
  • 每個人工升級案件都停在核准點，沒有自行執行後續步驟。
  • 每次拒絕都留下規則編號與原因。
  • 停用 agent 身份後，它無法改用人類帳號繼續。

第一個寫入動作可以只是新增「等待人工檢查」狀態，不要從唯讀直接跳到修改供應商主檔或釋放付款。這會讓團隊先驗證身份、規則與日誌是否真的連在一起，再增加影響範圍。

AI 整理卡

如果你要把現有 ERP 例外流程整理成可實作規則，可以把下面這段交給 AI。請先移除真實供應商名稱、帳號、發票內容與憑證，只提供欄位名稱、角色與匿名案例。

你是 ERP 工作流安全分析助手。請根據我提供的例外流程，協助我設計 AI agent 的獨立身份與預設拒絕規則。

流程背景：
- ERP 系統與環境：
- 例外類型：
- agent 需要讀取的物件與欄位：
- agent 可能提出的寫入動作：
- 現有人工核准角色：
- 必須保留的稽核資料：

請輸出：
1. agent 身份的單一用途定義與負責人。
2. 逐項列出允許的物件、動作、欄位、筆數或狀態條件。
3. 列出一律拒絕的動作，以及必須人工升級的動作。
4. 為每條規則指定可由系統判斷的 if–then 條件；不要使用「高風險時」或「視情況而定」。
5. 設計人工核准畫面應顯示的修改前後差異與後續影響。
6. 列出每次執行必留的日誌欄位。
7. 提出一個只含唯讀與草稿輸出的 dry-run 測試，包含至少 5 種拒絕案例。
8. 標出目前資訊不足、不能安全授權的項目，不要自行假設。

用 AI 整理規則草案後，仍要由 ERP 管理員、財務流程負責人與身份權限負責人共同確認。最小可行的起步動作很簡單：今天先找出一個正在沿用人類帳號的 agent，替它建立可單獨停用的測試身份，並只開放一項唯讀查詢。

用日常來理解

財務人員把單一文件交給 AI 助手；助手想碰其他上鎖資料時被人員設下界線，最後只把指定文件送回人工檢查。

  1. 財務人員先交給 AI 助手一份被指派的發票文件。
  2. 助手拿著文件，開始把手伸向其他仍上鎖的資料櫃。
  3. 財務人員立即放下界線，要求助手回到原本的一份文件。
  4. 助手只把該文件送入人工檢查盤，其餘資料仍保持上鎖、等待另行授權。
廣告

Share

分享這篇微課

如果這篇剛好解開一個工作卡點，可以分享給也在判斷 AI 怎麼用的人。

參考來源