【演繹觀點】AI 代理人少問一點，關鍵決定仍要人來審
從 Amazon Quick 的 Smart Approvals 看 AI 代理人審核設計：哪些動作可以交給模型放行、哪些必須由人核准，以及企業在試行前就該完成的權限與紀錄設定。
AWS 最近在官方部落格介紹 Amazon Quick 的 Smart Approvals 功能。它會檢查 AI 代理人準備執行的動作，符合使用者原本要求的就自動放行，否則退回給本人確認。正在讓 AI 代理人寄信、改資料的企業，都該關心這件事。
很多主管直覺認為，每一步都讓人按同意最安全。原文卻提醒，資安警示的研究顯示，提示重複出現，注意力和遵守程度都會下降。按到後來，同意鍵就變成反射動作。
審核的價值不在次數，而在問對時機。
先搞清楚變了什麼
根據 AWS 原文，這項功能有五個重點：
- 預設開啟： 功能預設就是開的，管理者透過自訂權限決定哪些人能用。若設定為預設拒絕，則要明確開放。
- 只審有資格的動作： 被政策拒絕的動作照樣擋下，規定必須由人核准的也照樣要人核准。
- 另一個模型把關： 獨立的分類模型會比對動作和使用者的要求，看動作做什麼、資料流向哪裡、影響到誰。
- 核准只用一次： 每次自動核准只適用於那一個動作和參數，不會變成長期權限。
- 使用者可以關掉： 關掉後，原本能自動審核的動作，都要本人點頭才會執行。
換句話說，這項功能不是放寬權限。它是在既有規則之內，幫人過濾掉不需要看的確認。
原文舉了一個例子。一位客戶經理請 Quick 整理季度業務簡報，再寄給自己指定的兩位同事。這種寄送和要求一致，可以交給系統審核。
但如果客戶筆記裡寫著，簡報也要寄給約 2,000 人的全業務群組，收件範圍就超出了原本的要求。系統會把這次寄送退回給本人，原本的核准也不能拿來用在更大的名單上。
換成台灣情境，一家製造業者用代理人整理供應商報價，文件裡夾了一行字，要求把資料轉寄到外部信箱。原文稱這類手法為間接提示注入，也就是讀進來的內容試圖改變代理人的方向。
機器先過濾例行事，人只看會出事的。
審核太多反而失守
很多公司都經歷過警示疲勞。郵件或防毒系統天天跳警告，員工很快學會不看內容就關掉。真正的釣魚信，往往就混在那堆被關掉的視窗裡。
AI 代理人也一樣。一個任務可能拆成很多步，每步都要人按同意，主管很快就會一路點下去。結果最危險的那次對外寄送，跟例行動作一起被放行了。
反過來說，把審核交給模型，不代表規則也能交給模型。原文坦白承認，模型審核仍可能出錯。必須由人核准的動作，特別是會搬動敏感資料的，應該直接用連接器的動作權限規定下來。
原文列出幾類即使符合要求，也值得人看一眼的動作：
- 對外寄送： 內容送出組織外，或寄給使用者匯報線上的高階主管。
- 改動存取： 調整誰能看、誰能改的設定。
- 刪除與付款： 刪除紀錄或發起付款，做了就很難收回。
還有一個常被忽略的教訓：核准紀錄不等於動作真的發生。原文提醒，紀錄上的標記不能證明動作已經執行。要確認信有沒有寄出，得對照目的地系統的紀錄。
所以要做兩件事：規則寫死在權限裡，事後能從紀錄追到結果。少了任何一件，自動核准就只是把風險藏起來。
原文的結論很直接：有效的監督，不看代理人問了幾次，而看人是否仍掌握重要決定。我們同意這個判斷。
接下來就能做的事
內部討論常卡在這裡：資安希望關卡多一點，業務希望打擾少一點，兩邊都有道理。與其爭論，不如先動手做幾件小事。
- 先列必須人審的清單： 把對外寄信、改權限、刪資料、付款寫下來，設定成一律要人核准，不要只靠模型判斷。
- 先把紀錄開好： 設定 CloudTrail 追蹤，並把聊天紀錄送進 CloudWatch Logs。事件歷史只保留 90 天，聊天紀錄也只記錄設定之後的活動。
- 挑一個小團隊試行： 用自訂權限只開放給一個處理固定流程的團隊，其他人先不開。
- 事先講好成功標準： 例行提示變少，但重要動作仍回到人手上，兩個條件都要達到。
- 故意測高風險情境： 抽查自動核准的紀錄，並在文件裡塞進陌生收件人，確認系統會退回給人。
試行結果達標再擴大到其他團隊。之後動作或政策改變時，也要重新檢查一次。
就算公司沒有用這套工具，這幾步一樣適用。換任何代理人平台，都可以先問供應商：哪些動作一定會回到人手上？
總結而言，好的審核設計是讓人少按幾次，卻一次都不漏掉重要決定。
每家公司的流程和風險不同，哪些動作該自動、哪些該人審，很難一次想清楚。如果你正在規劃 AI 代理人的導入，可以找熟悉流程與資安的顧問一起盤點，從一個試行流程開始。