分級依據是影響，不是錯誤訊息
事故分級不應只看 API 是否回傳錯誤。企業 AI 助理即使仍能回答，也可能引用錯誤版本的文件、跨越使用者權限、產生不應執行的 ERP 操作，或因模型重試造成成本快速累積。工程團隊應同時評估服務可用性、資料機密性、回答可信度、交易完整性、受影響範圍，以及是否存在持續擴大的風險。
建議採用四級制度，並為每一級預先定義通知對象、回應責任與允許採取的緊急措施。級別應可隨新證據升降，而不是在事故開始時一次決定。若無法確認是否涉及敏感資料或不可逆操作，先按較高等級處理通常更安全。
- SEV-1：涉及資料外洩、越權操作、核心流程全面不可用，或 AI 正持續執行高風險動作。立即停用相關能力，啟動事故指揮與管理層通報。
- SEV-2：主要功能明顯受阻、回答品質大範圍失真，或關鍵整合持續失敗，但仍有替代流程。優先降級服務並集中處理。
- SEV-3：影響局部使用者、特定文件集合或非核心功能，且有穩定繞行方式。排入當日或近期修復並持續監控。
- SEV-4：輕微顯示問題、偶發低風險錯誤或尚未影響使用者的告警。納入一般維護，但保留升級條件。
先控制傷害，再尋找根因
事故發生後，第一個目標是建立單一指揮窗口與可靠時間線。指定事故指揮者負責決策、技術負責人執行調查、紀錄者保存證據，並由溝通負責人同步內外部狀態。此時應暫停非必要部署，記錄模型版本、提示詞、知識庫索引、權限設定與第三方服務狀態，避免環境在調查期間繼續變動。
- 隔離：撤銷可疑憑證、封鎖受影響租戶、停止工具呼叫，或將 AI 助理切換為唯讀模式。
- 降級：停用生成式回答，改為文件搜尋、固定回覆、人工轉接或既有表單流程。
- 回滾：只有在前一版本及其資料相容性已知時才回滾；模型、提示詞與索引應視為同一發布單元。
- 切換：模型供應商異常時可使用備援，但必須重新確認資料落地、內容政策、工具呼叫與輸出格式。
選擇措施時，要比較持續傷害與降級成本。客服助理暫停回答可能造成等待，但通常比持續提供錯誤退款指引安全；內部知識搜尋可以保留低風險查詢，卻應先關閉會寫入 CRM 或 ERP 的動作。不要為了維持表面可用性而保留不可控能力。
用 AI 專屬檢查路徑縮小問題範圍
傳統監控通常只能看到延遲、錯誤率與資源使用量，無法直接判斷答案是否可靠。調查時應把請求拆成身分與權限、資料擷取、提示詞組裝、模型推論、工具執行及回傳處理等階段，使用同一筆追蹤識別碼串起紀錄。同時保存必要的輸入輸出摘要，但敏感內容應遮罩並遵守保存期限。
重現問題時，不要只測事故中的單一句問法。應建立一組經過去識別化的重播案例，涵蓋正常問題、權限邊界、找不到資料、提示注入、第三方逾時與工具部分成功等情境。若更換模型後問題消失，仍不能直接判定模型是根因；提示詞長度、檢索排序、結構化輸出解析與供應商限制也可能同時改變。
- 回答錯誤：檢查來源文件版本、切塊方式、檢索結果、引用對應與無答案策略。
- 權限異常：確認授權過濾是否在檢索前執行，快取與向量索引是否保留租戶邊界。
- 動作錯誤：核對工具參數、冪等鍵、人工核准點與部分成功後的補償流程。
- 延遲或成本異常：查看重試迴圈、上下文膨脹、備援鏈、批次工作與外部 API 限流。
復原不等於重新開機成功
修正完成後，先在隔離環境重播事故案例與核心回歸案例，再以受控範圍恢復流量。驗證項目不只包括成功回應，也要確認引用正確、權限隔離、工具副作用、逾時行為、成本上限與稽核紀錄。若無法證明高風險功能安全，可以先恢復查詢能力，讓寫入或自動執行功能維持關閉。
正式結案前應確認監控指標回到可接受範圍、待處理工作已清理、錯誤交易已補償、受影響資料已盤點，且使用者得到一致說明。事故報告應記錄時間線、影響、觸發條件、促成因素、有效與無效的處置，以及每項改善工作的負責人和驗證方式；重點是改善系統，不是尋找個人責任。
- 短期：補上告警、停用危險預設值、限制重試，並建立可操作的降級開關。
- 中期：增加權限邊界測試、提示詞與索引版本管理、重播測試及備援演練。
- 長期：調整架構以縮小故障範圍，將高風險動作納入人工核准、冪等與完整稽核。