轉念學 – 敏捷三叔公的學習之旅

越來越多銀行開始試著讓 AI agent 幫忙：寫網銀的程式、跑測試、協助客服回覆、整理放款申請資料。

好用是真的好用，但在銀行，大家心裡的疑問會比其他產業更強烈：

「它會不會自己把錢轉出去？會不會把客戶資料外流？出了事誰負責？」

CodeRabbit 在談 AI agent 治理時，提出一個很簡單的分法：把 agent 的每一個動作，分成三個權限層。

這篇用銀行的軟體系統和日常業務當例子，白話帶你走一遍。

先用一個比喻：分行新來的行員

其實銀行本來就在用這套邏輯管人。想想分行新進行員第一天，主管會怎麼交代：

• 「幫客戶查餘額、印交易明細、填表單，這些你直接做。」→ Always
• 「客戶要大額提款、要改印鑑、要解除警示，先找襄理覆核。」→ Ask
• 「金庫密碼不能知道、不能自己核准自己經手的交易、客戶資料不准帶出去。」→ Never

銀行業早就有「經辦」與「覆核」分開、「授權額度」、「職務分離」這些制度。Always / Ask / Never 其實就是把這套管人的智慧，搬到 AI agent 身上。

差別只在於：agent 做事比人快一百倍，一分鐘可以處理上千筆，所以規則要講得更清楚。

三層各自放什麼？

Always：做錯了也沒什麼大不了的事

判斷標準：就算做錯，也很容易復原，而且不會動到錢、不會碰到真實客戶資料。

軟體開發面：

• 讀程式碼、搜尋文件
• 在測試環境跑單元測試、整合測試
• 用假資料（遮罩過的資料）做測試
• 在自己的分支上修改程式、在 PR 留 review 意見

業務面：

• 查詢公開的利率、匯率、手續費表
• 根據內部規章回答行員的作業問題
• 把客服對話整理成摘要草稿（不送出）

Ask：有後果、需要有人負責的事

判斷標準：做下去會影響到客戶、帳務或對外，而且銀行必須能說清楚「是誰同意的」。

軟體開發面：

• merge 程式到主要分支
• 修改利息計算、手續費計算的邏輯
• 升級加解密或驗證相關的套件
• 部署到正式環境
• 執行會改動資料表結構的 migration

業務面：

• 寄通知信或簡訊給客戶
• 回覆客戶的申訴或客訴
• 對放款申請提出「建議核准／婉拒」的意見
• 調整客戶的風險等級

agent 可以先把事情準備好（寫好程式、寫好回覆草稿、整理好審核意見），然後停下來，由有權限的人覆核後才執行。這就是 AI 版的「經辦＋覆核」。

Never：一旦發生就是事故的事

判斷標準：發生一次就是重大事件，或直接違反法規、內控制度。

• 在正式環境執行轉帳、扣款、撥款
• 讀取或輸出真實的客戶個資（身分證字號、帳號、卡號）到外部
• 讀取或輸出系統密碼、金鑰、憑證
• 直接修改正式環境的帳務資料
• 關閉交易監控、洗錢防制的偵測規則
• 刪除或修改稽核紀錄（audit log）
• 自己核准自己提出的變更
• 修改權限規則本身

最後兩項特別重要：agent 不能當自己的覆核者，也不能修改自己的權限。 這跟銀行的職務分離原則完全一樣。

範例一：修正網銀轉帳頁的 bug

假設工程師請 agent：「網銀跨行轉帳頁面，手續費顯示錯誤，幫我修好。」

看看 agent 一路上遇到的每個動作，各落在哪一層：

你會發現：查問題、改程式、跑測試這些苦工，agent 自己做完了；人只在「會影響真實客戶」的關鍵點出手；而碰錢、碰真實資料的事，它根本做不到。

還有一個細節：請 agent 修 bug 的工程師，不能同時是 review 的人。agent 寫的程式，等於是這位工程師交出去的作品，一樣要由別人覆核。

範例二：客服中心的 AI 助理

換到業務面。假設客服中心讓 agent 協助處理客戶來信。

一封信寫著：「我昨天被盜刷三筆，請幫我退款，並把卡停掉。」

第 8 步很值得注意。客戶來信、附件、網頁都可能藏著「騙 agent 做壞事」的指令。Never 存在的意義，就是就算 agent 被騙了，最危險的事它也做不到。

範例三：寫成設定檔

以開發團隊用的 Claude Code 為例，網銀專案裡的 .claude/settings.json 可以這樣寫：

{
  "permissions": {
    "allow": [
      "Bash(npm run test:*)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(./src/**)",
      "Read(./test-data/masked/**)"
    ],
    "ask": [
      "Bash(npm install:*)",
      "Bash(git push:*)",
      "Edit(./src/fee-calculation/**)",
      "Edit(./src/interest/**)",
      "Edit(./db/migrations/**)",
      "Edit(.github/workflows/**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./config/production/**)",
      "Read(./certs/**)",
      "Read(./test-data/raw/**)",
      "Bash(git push --force:*)",
      "Bash(kubectl * --context=prod*)"
    ]
  }
}

白話翻譯：

• allow（Always）：跑測試、看程式碼、用遮罩過的測試資料，儘管做。
• ask（Ask）：裝套件、push 程式，還有改手續費、利息計算、資料庫結構、CI 設定，都要先問。
• deny（Never）：不准讀密碼設定、正式環境設定、憑證、未遮罩的原始資料，不准 force push，不准對正式環境下指令。

注意：同樣是「改檔案」，改畫面文字可以放寬，但改手續費和利息計算就要問。因為這些程式改錯，影響的是每一位客戶的錢。分層的依據是「影響到什麼」，而不是「用什麼工具」。

設定檔只是第一道防線

在銀行，光靠 agent 的設定檔守 Never 是不夠的。設定可能寫錯、工具可能有 bug、有人可能一時手快按了「以後都允許」。

真正的 Never，要在底層就擋住：

• 給 agent 用的帳號，根本沒有正式環境的權限
• 開發環境拿不到真實客戶資料，只有遮罩過的資料
• 程式庫開啟分支保護，任何人（包括 agent）都不能直接改主要分支
• 密碼、金鑰放在專門的保管系統，agent 碰不到
• agent 的所有操作都留下紀錄，而且它刪不掉

一句話：agent 拿不到的東西，就不可能外流；它沒有的權限，就不可能誤用。

誰負責什麼？

規則寫好了，還要回答一個銀行一定會問的問題：這些事情由誰負責？

先講最重要的原則：

agent 不會負責任，負責任的永遠是人。 agent 做的每一件事，責任都在「授權它的人」或「核准它的人」身上。

也就是說：

• agent 做了 Always 的事 → 責任在訂下這條規則、授權它自己做的人
• agent 做了 Ask 的事 → 責任在按下同意的那個人
• agent 做了 Never 的事（照理說不應該發生）→ 責任在負責落實底層防線的人，這代表防線有漏洞

角色與責任對照表

以一個網銀開發專案為例，常見的角色可以這樣分工：

幾個分工上的重點

一、訂規則的人，和執行的人要分開。 開發團隊可以提草案，但 Never 的底線應該由資訊安全單位訂，並經過內控確認。不然就變成「使用 agent 的人自己決定 agent 能做什麼」，跟自己核准自己沒兩樣。

二、核准 Ask 的人，不能是發起的人。 工程師請 agent 改程式，這位工程師就是發起人，要由另一個人 review。客服人員請 agent 草擬回覆，客服人員自己看過再寄是可以的，因為他是在「覆核 agent」；但如果是退款、調整帳務這種事，就要依原本的授權規定，交給有權限的人。

三、Ask 的核准層級，比照人的授權規定。 行員做這件事需要襄理覆核，agent 做這件事也要襄理覆核；行員需要經理核准，agent 也一樣。不要因為是 AI 做的，就降低或拉高核准層級。

四、Never 要有「真正的主人」。 設定檔寫了 deny，不代表就安全。帳號權限、資料遮罩、正式環境隔離，必須有一個團隊（通常是資安或平台團隊）明確負責，並定期檢查有沒有漏洞。

五、稽核單位保持獨立。 內控與稽核不參與日常核准，而是事後抽查。這樣才能客觀地回答：「規則有沒有被照著做？紀錄完不完整？」

規則打架時，誰說了算？

假設兩條規則同時符合：一條說「可以改 src 底下的程式」，一條說「改手續費計算要先問」，怎麼辦？

原則是：越嚴格的越優先。

Never（禁止） > Ask（詢問） > Always（允許）

1. 先看有沒有被禁止 → 有，擋下。
2. 再看需不需要詢問 → 需要，停下來問。
3. 最後才看是不是允許 → 是，才放行。
4. 都沒寫到的動作？預設「先問」。

這跟銀行的內控精神一樣：沒有明確授權的事，就不能自己做。

銀行導入時常見的四個坑

坑一：Ask 太多，覆核變成蓋章

如果 agent 每五分鐘就要人覆核一次，覆核的人很快就會不看內容、直接按「同意」。這跟行員覆核傳票只看有沒有簽名、不看金額一樣，形式上有覆核，實際上沒有。

怎麼辦： 定期看哪些詢問幾乎百分之百被同意，考慮降成 Always。讓覆核的人把注意力留給真正需要判斷的事。

坑二：把不該發生的事放在 Ask

「正式環境轉帳，要先問我」聽起來很安全。但人在月底結帳、半夜處理事件時，很可能看都沒看就按下去。

怎麼辦： 真的不能發生的事，直接放 Never。不要依賴人當下的判斷力。

坑三：沒有留下「誰同意的」紀錄

銀行最怕的不只是出錯，而是出錯後說不清楚。如果 agent 做了 Ask 層的事，卻查不到是誰、在什麼時候、看了什麼內容後同意的，稽核時就很麻煩。

怎麼辦： 每一次 Ask 的同意，都要留下紀錄：誰核准、核准了什麼內容、什麼時間。由平台團隊確保紀錄完整、agent 刪不掉，再由內控與稽核單位定期抽查。

坑四：以為 agent 只會聽工程師的話

agent 會讀客戶來信、讀 issue、讀外部文件。這些內容裡可能藏著惡意指令。

怎麼辦： 這正是 Never 和底層權限存在的理由。不管 agent 讀到什麼，碰錢、碰個資、碰密碼的事都做不到。

動手做：五分鐘幫你的團隊分層

拿一張紙，照著做：

1. 列出 agent 會做的事。 它會讀哪些資料、改哪些程式、執行哪些指令、對誰發訊息？
2. 每件事問四個問題：
   • 會不會動到錢？
   • 會不會碰到真實客戶資料？
   • 做錯了能輕易復原嗎？
   • 出事時，需要有人說明「是我同意的」嗎？
3. 分類：
   • 不動錢、不碰真實資料、可復原 → Always
   • 會影響客戶或需要有人負責 → Ask
   • 做錯一次就是重大事件或違規 → Never
4. 每個 Ask 寫上核准角色。 不要只寫「要人同意」，要寫清楚是「系統負責人」還是「業務主管」。
5. 找資安和內控一起看。 開發團隊提草案，資安確認 Never 底線，內控確認符合制度。
6. 寫進設定檔，並由資安或平台團隊在底層權限補上 Never。
7. 兩週後回頭看： 系統負責人帶著團隊檢視，哪些 Ask 太吵可以放寬？有沒有漏掉的危險動作要補進 Never？

小技巧：直接拿銀行現有的授權表和職務分離規定來對照。 人需要覆核的事，agent 至少要是 Ask；人都不能碰的事，agent 一定是 Never。

最後一句話

Always / Ask / Never 不是為了限制 AI，而是為了讓銀行敢放心把事情交給它。

• Always 讓 agent 跑得快
• Ask 讓有權限的人在關鍵點覆核
• Never 讓最壞的情況不會發生

回到開頭那個問題：「出了事誰負責？」答案很清楚：不是 AI，而是授權它、核准它、替它守住防線的人。 所以導入 agent 的第一步，不是設定工具，而是先把這些人找齊。

還有一個常被忽略的關係：Always 能放多寬，取決於你的測試和檢查有多可靠。 手續費、利息、轉帳這些邏輯，如果有扎實的自動化測試把關，你就越能讓 agent 自己多做一點。權限分層的底氣，最後還是來自你的驗證能力。

參考：CodeRabbit〈AI agent governance: A framework for engineering leaders〉