如何判斷 AI 是否準備好行動
一份 AI readiness checklist，用來判斷 agent 或自動化何時可以行動：背景、來源覆蓋、權限、信心、可回復性和審閱。
重點摘要
- AI 只有在工作背景清楚、來源足夠、權限明確，而且錯誤可以被發現或補救時，才算準備好行動。
- 模型能力只是其中一個因素；readiness 亦取決於治理、來源覆蓋、信心檢查、可回復性和升級路徑。
- 最穩陣的路徑是分階段委派：協助、草擬、建議、經批准後行動，最後只在狹窄並受監察的條件下自動行動。
判斷 AI 是否準備好行動，不應只看模型能力，而要看背景、來源覆蓋、權限、信心檢查、可回復性和審閱路徑。
在本文，「準備好行動」指 AI 系統準備做一些會改變工作狀態的事：發送訊息、更新紀錄、批准一步、拒絕要求、觸發工作流程、改變優先次序、建立義務，或呼叫會影響其他系統的工具。
這和準備好回答問題不同。模型可以在草擬和分析上有用，但未必安全到可以行動。因此 readiness test 應集中在行動周邊的營運條件。
Readiness inputs
Context
State
Sources
Evidence
Authority
Permission
Checks
Validation
Undo path
Containment
Review
Escalation
Ready?
Is it safe to act?
Action level
What the system may do
- Draft only
- Recommend
- Ask approval
- Act automatically
這個測試反覆出現兩個條件：在可問責決策中使用 human-in-the-loop 審閱。
Readiness 是一個委派決定
AI readiness 是一個委派決定。你是在決定軟件是否可以代表一個人或機構採取某一步。
NIST 的 AI Risk Management Framework 很有幫助，因為它不把 AI 風險只視為模型本身的屬性。它要求機構在 AI 生命週期中治理、映射、量度和管理風險，並指出部署應基於對可信度、風險、影響、成本和利益的情境化評估（NIST AI RMF1）。
也就是說，問題不是「模型夠不夠好？」問題是「這個系統，在這個 workflow、這些資料、這種權限、監察和補救路徑下，是否準備好採取這個行動？」
為甚麼會有這個問題
能力不等於權限
AI 系統可能有能力草擬回覆、識別可能分類，或建議下一步。這不代表它有權發送回覆、指定分類或執行那一步。
權限必須被明確授予。機構要定義系統可以讀取、寫入、發送、批准、拒絕、花費、排程、披露或刪除甚麼。沒有這條邊界，「AI readiness」就會變得含糊而高風險。
信心不是自明的
生成式 AI 可以產生語氣很肯定但其實錯誤或無根據的輸出。NIST 的 Generative AI Profile 把 confabulation 描述為以自信方式呈現的錯誤或虛假內容，並指出錯誤邏輯或引用可能誤導用戶信任輸出（NIST AI 600-12）。
因此 readiness 需要模型語氣以外的信心檢查。系統需要來源檢查、政策檢查、限制檢查、測試個案、監察和人手審閱路徑。
Readiness Checklist
1. 背景
系統是否看得見相關的工作狀態？
有用的行動取決於背景：用戶、客戶、案件、個案、截止日期、政策、歷史、義務、權限和目前狀態。如果背景缺失或分散，系統可能採取一個局部看似合理、整體卻錯誤的行動。
在香港專業團隊裏，這個問題通常不是「有沒有資料」，而是資料分散在電郵、SharePoint、CRM、會議紀錄、合約 PDF、財務系統和人的記憶裏。AI 如果只看見其中一角，就可能錯把過時承諾當最新狀態，或者忽略某位合夥人、客戶負責人、項目經理早已改變方向。準備行動前，系統要知道自己看見的是整體工作狀態，還是只是方便取得的一部分。
2. 來源覆蓋
系統是否擁有正確證據，而且能否展示出來？
來源覆蓋不只是 retrieval。它包括新鮮度、權威性、完整性和衝突處理。不能分辨現行政策和過時筆記的系統，不應按政策行動。不能展示來源的系統，不應作出可問責主張。
來源覆蓋亦要處理衝突。兩份文件都被找回，不代表系統知道哪一份應優先：正式簽署版本通常比草稿重要；最新政策通常比舊 wiki 重要；客戶確認電郵可能比內部假設重要。準備行動的系統要能標示「來源互相矛盾」或「來源不足以支持行動」，而不是把衝突平均成一個流暢答案。
3. 權限
行動是否在明確許可之內？
Anthropic 對 building effective agents 的建議區分了 workflows 和 agents：workflows 的路徑由程式碼定義；agents 則會動態指揮自己的流程和工具使用。它建議由受限制模式開始，只在需要時增加自主性（Anthropic3）。這是一條有用的 readiness 原則：先授予狹窄工具權限，再談廣泛自主。
4. 信心檢查
系統能否在採取行動前測試擬議行動？
檢查可以包括 schema validation、來源匹配、政策比較、重複偵測、矛盾偵測、門檻檢查、模擬或 evaluator review。重點是在壞行動離開系統之前，加入獨立阻力。
信心檢查最好盡量外置於模型語氣。系統可以要求每個主張連回來源段落、每次更新符合 schema、每個付款建議通過金額和權限門檻、每封對外訊息先通過敏感詞和關係風險檢查。這些檢查不會令 AI 完美，但會把「看起來合理」改成「有證據、有規則、有例外路徑」。
5. 可回復性
行動能否撤回或控制影響？
更新內部草稿和發送客戶電郵不同。建立任務和批准付款不同。可回復行動可以較早被委派。不可回復、對外、受規管或高後果的行動，需要更強批准。
6. 審閱路徑
當系統不確定、受阻或超出權限時，會發生甚麼？
Readiness 包括停下來的能力。EU AI Act 對高風險 AI 系統的人手監督要求，強調有效監督和對 automation bias 的認知（EUR-Lex4）。在實務上，這代表審閱不能是事後補丁。workflow 必須定義誰審閱、他們看到甚麼，以及如何推翻系統輸出。
審閱路徑要在設計時存在，而不是在出事後才加上去。審閱者需要看到建議行動、使用來源、缺失資料、系統信心、權限邊界和可選擇的下一步。他們亦需要有真正權力去改、拒絕、延後或升級。否則，人手審閱只會變成把責任放在最後按鈕上的形式。
分階段委派模型
大部分團隊不應由 chatbot 直接跳到自主行動。分階段模型更安全，也更容易評估。
| 階段 | AI 角色 | Readiness 標準 |
|---|---|---|
| 協助 | 總結、搜尋、解釋 | 有幫助，並有來源意識 |
| 草擬 | 準備文字或結構化欄位 | 使用前由人審閱 |
| 建議 | 提出下一步行動 | 證據和理由可見 |
| 經批准後行動 | 準備行動，等待確認 | 權限清楚，有審閱者路徑 |
| 自動行動 | 執行狹窄行動 | 低風險、可回復、受監察、可審計 |
這個模型也令進度更可量度。一個 workflow 可能已準備好草擬，但未準備好發送。可能準備好更新內部狀態，但未準備好通知客戶。也可能在一個部門可用，在另一個部門不可用，因為來源覆蓋或政策背景不同。
這不是甚麼
AI readiness 不是單一 benchmark 分數。Benchmark 可以幫助比較模型，但不能證明某個特定 workflow 已有足夠背景、權限、來源覆蓋和補救設計。
它也不是一年一次的批准。ISO/IEC 42001 把 AI 治理描述為一套用於建立、實施、維持和持續改善負責任 AI 使用的管理系統（ISO5）。當政策、資料、模型、工具和營運條件改變，readiness 也會改變。
例子
準備好草擬，未準備好發送
客戶更新助手可以擷取近期活動、草擬摘要和列出證據。如果關係語氣、法律風險或未解事實很重要，它不應自動發送更新。
在這種情況下，系統的 readiness 停在 preparation。它可以把最近會議、未完成承諾、相關文件和缺失問題放到同一個 packet；也可以建議幾種語氣或下一步。但發送本身會代表機構立場，亦可能創造客戶期望，所以仍然需要 account owner 或專業負責人批准。這不是浪費 AI，而是把 AI 放在它已經可靠的位置。
準備好更新狀態
當必填欄位完整而下一位負責人已知，內部 workflow agent 可能準備好把任務標記為「等待審閱」。這個行動可見、可回復，而且風險低。
這類行動適合較早委派，因為錯誤容易發現和修正。狀態更新通常留在內部系統，有 audit trail，也不直接對外承諾。即使標記錯了，人可以改回、重新指派或把任務拉回隊列。這種可見、可回復、低後果的行動，是團隊建立自動化信任的好起點。
未準備好拒絕要求
如果決定取決於不完整證據、含糊政策、受保護特徵或上訴權，系統不應自動拒絕客戶、申請人或員工的要求。
拒絕通常比準備更高風險，因為它會影響人的權益或關係，也可能需要解釋和申訴路徑。AI 可以整理證據、標示政策條款、指出缺失資料，甚至建議需要哪位審閱者。但只要決定牽涉權利、合約、僱傭、信貸、服務資格或專業判斷，系統就不應把「可能不符合」直接變成最終拒絕。
結論
當周邊營運設計準備好委派，AI 才準備好行動。這代表系統有背景、來源、權限、檢查、可回復性、審閱和監察。
實用標準是：如果系統錯了，機構能否發現、解釋、控制影響並分配問責？如果不能，AI 仍然可能有用，但尚未準備好行動。
這代表 readiness 不是一次性 yes/no，而是按行動類型、風險和補救能力調整的控制模型。團隊可以先批准建立任務或更新內部狀態，但暫不批准對外發送或更改金額；等低風險步驟穩定後，再逐步擴大權限。
這樣做的好處，是讓 AI 仍然可以有用，但不必太早承擔它未準備好的責任。系統可以先協助、草擬和建議；只有當背景、來源、權限、檢查和補救路徑都成熟，才把某些狹窄行動交給它執行。
換言之，readiness 是營運設計的問題，不只是模型表現的問題。
這個標準越早說清楚，之後擴大委派時就越少靠感覺，也越容易向審閱者和管理層解釋為甚麼某些行動可以交給系統，某些仍然要留給人。
資料來源
/ 開始
先由一個營運範圍開始，再逐步擴展。
由一個清晰的審閱節奏、工作流程或團隊開始，找出更好的營運背景能即時改善準備和判斷質素的地方。