AI 代理的內控框架:當「不是人」的東西開始做交易,內控該怎麼寫(2026)

by Abby Huang
AI 代理的內控框架:當「不是人」的東西開始做交易,內控該怎麼寫(2026)
AI 代理的內控框架:當「不是人」的東西開始做交易,內控該怎麼寫(2026)

這不是未來式。Oracle Fusion 的 AI 正在自動比對銀行入帳建議沖帳,SAP 的代理已經能在條件滿足時自動放行生產工單——AI 代理(AI Agent)已經在企業的帳上做事了。而全世界的內部控制制度,從九大循環到 COSO 框架,都建立在同一個沒被說出口的假設上:執行交易的是「人」——有帳號、有職掌、會被考核、出錯要負責的人。

這個假設正在失效,而準則與查核實務都還沒跟上。這篇提出一套可以今天就開始用的框架——我們稱之為 AI 代理內控五支柱:身分與授權、風險分級、代理的職能分離、軌跡與版本、監控與回測。它不是憑空發明,是把九大循環用了幾十年的方法論(授權、執行、記錄、覆核),翻譯到一個新物種身上。

先立一個貫穿全文的原則,這是我們在檢驗 ERP 的 AI 功能時就講過的那句話:代理做的每個動作,在稽核眼中都是一筆需要授權依據和紀錄的交易。 AI 不豁免內控——它只是內控的新對象。


支柱一:身分與授權——AI 也要有「職務說明書」

第一條鐵律:代理必須有自己的身分。實務上最危險的做法是讓 AI 掛在某個人類使用者的帳號下跑——那意味著代理的每筆動作在軌跡上都顯示成那個人做的,權限繼承那個人的全部權限,出事時分不清人與機。代理要有獨立的系統身分(服務帳號),權限按最小授權原則單獨配置。

第二條:代理要進核決權限表。人類員工的採購核決有金額分層,代理也要——這個沖帳代理能處理的單筆金額上限、能碰的交易類型白名單、能觸及的資料範圍,白紙黑字寫進核決權限表的一個新章節。開通一個代理的程序,比照一個新進人員的到職權限申請:誰提出、業務主管與資訊主管會簽、留下開通紀錄。

第三條:每個代理要有一個人類 owner。像 key user 制度一樣,每個代理指定一名負責人——它的規則設定、行為監控、錯誤處理都掛在這個人身上。「AI 出錯誰負責」這題的答案不該是哲學辯論,該是組織圖上的一個名字:owner 負的不是代理的錯,是監督的責

支柱二:風險分級——不是「用不用 AI」,是「放手到什麼程度」

把代理的自動化程度分三級,按風險配置:

L1 建議級:AI 產出建議,人逐筆確認才執行(沖帳建議、費用單自動帶入待確認)。風險最低,因為控制點還是人——這是所有代理的合理起點。L2 條件自動級:閾值內自動執行、超出升級人工(五萬以下的完全匹配沖帳自動過、以上送人工)。L3 全自動級:無人介入的閉環執行——只留給同時滿足三個條件的場景:金額小、動作可回復、不直接影響財報數字。

分級的判斷軸就是這三個變數的乘積:金額重大性 × 可回復性 × 財報影響。自動放行生產工單為什麼要格外謹慎?因為它啟動的是實體資源的投入——料下去了、機台跑了,回復成本是真金白銀。分級不是一次定終身:代理在 L1 跑出足夠的準確率紀錄後,可以按程序升級到 L2——升級本身要有核准,如同調高一個員工的核決權限

支柱三:代理的職能分離——SoD 要看「鏈」,不是「點」

人類的 SoD 邏輯直接平移過來:一個代理不能同時掌握不相容職務——維護供應商主檔的代理和執行付款的代理必須是兩個身分、兩套權限(原因和人類版一模一樣:合在一起就是假供應商舞弊的無人化完整路徑)。

再加兩條 AI 特有的分離。設定者與覆核者分離:配置代理規則、調整它閾值的人,不能同時是覆核其輸出的人——否則「調鬆一點讓數字好看」無人攔截;這條在減碳數據、獎酬掛鉤指標的場景特別要命(我們在 ESG 第十循環講過同構的風險)。代理鏈的複合檢視:這是全新的課題——單看每個代理權限都合規,但代理 A 的輸出觸發代理 B、B 再觸發 C,串起來就是一條從訂單到付款的無人路徑。SoD 矩陣(方法見我們的權限設計專文)要新增一個維度:不只掃「單一身分的權限組合」,還要掃「代理之間的觸發鏈」——鏈上是否至少有一個人類控制點,是 L3 場景的硬要求。

支柱四:軌跡與版本——AI 最大的不同:它會「漂移」

傳統自動化(RPA、批次程式)的行為是固定的——同樣輸入永遠同樣輸出,測過一次就定了。AI 代理不是:模型更新、規則調整、甚至資料分布的變化,都會讓它對同一種情境做出不同的決定。這個特性推翻了「上線前測一次就好」的傳統邏輯,帶出兩條新規矩:

紀錄要能「事後說明」而非「事後重演」。 每筆代理動作記錄五件事:哪個代理、依據什麼輸入、當時的規則與模型版本、決策內容(含信心度,若有)、人是否介入。因為 AI 的決策不保證可完全重演,查核的答題方式從「重跑給你看」變成「當時的完整紀錄給你看」——記錄的完整度就是你的可查核性。

模型與規則的變更,比照客製程式的變更管理。 誰改的、為什麼改、改前改後的行為差異測試、核准簽章——AI 供應商推送的模型更新也算變更:更新後的首個期間,該代理的抽樣覆核密度要拉高。這條寫進去,你的變更管理制度就正式承認了一個新的變更來源:不是你改了系統,是系統自己變了

支柱五:監控與回測——覆核從「逐筆」變「例外+抽樣」

人工逐筆覆核會吃掉自動化的全部效益,所以覆核設計要換型態:例外管理(代理標記的低信心案件、超閾值案件進人工佇列——佇列有沒有人及時清,本身就是監控指標)+定期抽樣回測(每月從代理已執行的決策裡隨機抽樣,人工重驗——它沖的帳真的對嗎、它放行的工單條件真的滿足嗎,準確率進儀表板,連續下滑就觸發降級檢討)。

最後一道保險:kill switch。誰有權緊急停用代理、什麼條件自動觸發(錯誤率突破門檻、單日執行量異常暴增)、停用後的人工接手程序——寫進制度,並且演練過。這跟上線切換的回退計畫是同一個哲學:希望永遠用不到,但沒有它的自動化是在裸奔。

查核的視角:會計師遲早會問的四題

準則還沒跟上,但查核邏輯可以推演。四個遲早會被問的問題,現在就用來自我檢驗:這個代理的授權依據在哪(核決權限表的章節、開通簽核紀錄)?它的行為紀錄完整嗎(五要素軌跡調得出來嗎)?它的變更有管理嗎(模型版本史、變更簽核)?它的準確性有人監控嗎(回測紀錄、例外處理紀錄)?——四題答得出來,不管未來準則怎麼寫,你都站在對的那一邊。有 IPO 時程的公司多想一步:專審時內控的「有效運作」要看證據,代理相關的這些紀錄,從啟用第一天就要留(老規矩:紙上的制度誰都會寫,軌跡才是真話)。


常見問題(FAQ)

現在有法規要求 AI 代理的內控嗎?
針對 AI 代理的專門規範尚未成形,但責任體系已經存在:代理產出的交易進了帳、帳進了財報,財報的內控要求就涵蓋它。等專門規範出來才動手的公司,補的不是文件,是好幾年的軌跡。

這跟 RPA 的內控差在哪?
RPA 行為固定、可完全重演,測試一次可信賴一段期間;AI 代理會隨模型與資料漂移,需要持續監控、抽樣回測與變更管理。把 AI 代理當 RPA 管,是這個題目最常見的類別錯誤。

中小企業也需要這套嗎?
用了代理就需要,規模只影響繁簡。最小可行版本:代理獨立帳號、進核決權限表、從 L1 建議級起步、留五要素軌跡——四件事,一週內做得完。

該從哪個代理開始?
從 L1 且高頻的場景:沖帳建議、費用單辨識。跑出準確率紀錄、建立監控習慣,再談升級與擴張。順序永遠是:先有內控框架,再放代理進來——反過來的公司,是在用真實交易幫 AI 做沒有安全網的測試。


本框架為本站提出之原創方法論,將隨各系統代理功能與查核實務的演進持續迭代(建議每半年回訪本文)。若需要協助評估貴公司代理場景的風險分級或建立五支柱的落地設計,歡迎與我們聯繫。

延伸閱讀

You may also like

3 comments

《資通安全管控指引》落地三段譯:把指引從年度問卷變成內控制度的資安章(2026) – ERP Master 2026-07-06 - 02:28

[…] AI 代理的內控框架:當「不是人」的東西開始做交易,內控該怎麼寫(2026) […]

Reply
ITGC 四塊縱深:存取、變更、備份、監控——九大循環自動控制的信任地基(2026) – ERP Master 2026-07-06 - 02:29

[…] 現在,你的 ERP 正在沒有任何人按核准鍵的情況下做決定——收料自動過帳、超過核決金額的採購單自動擋下、信用額度不足的訂單自動凍結。這些「自動控制」是九大循環運作的日常,而多數公司對 ITGC(Information Technology General Controls,資訊科技一般控制)的理解,還停留在「查核前要生出來的那疊文件」。這個理解建立在一個已經失效的假設上:以為控制是人做的、系統只是工具。事實剛好相反——九大循環裡越來越多控制是系統做的,而 ITGC 是唯一讓「系統做的控制」值得被信任的東西。 […]

Reply

Leave a Comment