AI事件響應操作手冊：當模型出錯時該怎麼做

每個在生產中運行AI的組織最終都會遇到模型故障。問題不是是否會發生，而是您是否有辦法快速識別、遏制和從中恢復。

大多數組織沒有。他們有軟件事件響應流程，這些流程對於基礎設施停機和數據洩露是充分的。AI模型故障是不同的：它們通常是無聲的（沒有停機，只是錯誤的輸出）、廣泛的（影響大量請求）、延遲可見的（錯誤輸出可能在被注意到之前造成損害），並且在受監管行業中有不同的監管披露義務。

以下是一個起點，而非完整的模板。根據您的業務環境、監管要求和現有事件管理基礎設施對其進行調整。

嚴重性分類

並非所有AI事件都需要相同級別的響應。定義嚴重性級別使您能夠進行適當的升級，而不會對所有事件反應過度或反應不足。

級別	描述	示例	初始響應時間
P0 - 嚴重	可能的安全事件、數據洩露或受監管決策中可能立即造成傷害的AI故障	醫療AI向患者提供危險建議；信貸AI因受保護特徵系統性拒絕申請人	立即 — 呼叫相關人員
P1 - 嚴重	AI輸出中高容量或高後果的錯誤，影響核心業務流程或外部用戶	欺詐檢測漏掉一類欺詐；合同AI生成錯誤條款	1小時內
P2 - 中等	可測量的性能退化，影響一部分用戶或使用案例	情感分析模型在新輸入格式上性能下降；摘要質量退化	4小時內
P3 - 低	輕微輸出質量問題，僅影響邊緣案例或低容量場景	偶爾的格式不一致；低流量場景中的邊緣案例故障	下一個工作日

第一階段：檢測與分類

目標：確認事件存在，確定初始嚴重性，並呼叫適當的響應資源。

1.1 事件來源

AI事件可以從多個渠道浮現：

自動監控警報：輸出質量指標偏離基線（幻覺率、置信分數、輸出長度分佈）
用戶報告：客戶或內部用戶標記異常輸出
下游系統警報：依賴AI輸出的系統行為異常
定期質量審查：人工或自動化的輸出質量審查發現問題
外部報告：監管機構、合作夥伴或媒體注意到問題

1.2 初始分類清單

當事件被標記時：

事件是否涉及AI/ML系統的輸出，還是底層基礎設施故障？
哪些AI系統、模型版本和使用案例受到影響？
影響的大致容量是多少（請求數量，時間範圍）？
是否有外部用戶或受監管決策受到影響？
是否有立即可能的安全或傷害影響？
根據上述標準的初始嚴重性評估是什麼？

1.3 即時遏制選項

在調查繼續的同時，考慮即時遏制：

流量轉移：將請求從受影響的模型路由到備用系統或後備邏輯
功能降級：暫時退化到規則基線或人工審查
受影響模型停用：如果問題嚴重且安全後備可用

遏制不總是可行的，可能有自己的業務風險——在沒有升級的情況下不要將生產系統下線。

第二階段：調查

目標：確定根因、影響範圍和直接的補救選項。

2.1 影響範圍分析

精確的時間範圍：第一個已知的受影響輸出是什麼時候？
受影響的請求總量
受影響的獨立用戶或客戶
受影響的AI輔助決策（特別是高後果決策）
是否有外部通信、提交或行動依賴了受影響的AI輸出？

2.2 根因假設

常見的AI事件根因：

數據漂移：輸入數據分佈偏離訓練分佈。典型症狀：全面性能退化，通常隨時間逐漸出現。

模型版本更改：供應商的靜默模型更新改變了行為。典型症狀：特定供應商更新後突然的行為變化。

提示配置問題：提示更改、系統提示修改或上下文注入引入了錯誤。典型症狀：提示更改後的突然行為變化。

下游集成失敗：AI輸出解析或後處理中的錯誤以錯誤方式處理有效的AI輸出。典型症狀：AI輸出看起來合理，但下游系統行為錯誤。

對抗性輸入：惡意構建的輸入系統性地誘導有害輸出。典型症狀：集中在特定輸入模式上的故障。

訓練數據問題：僅適用於自有模型——訓練集中的問題浮現在特定輸入類別的推論中。

2.3 調查文件要求

對於P0和P1事件，在調查過程中維護運行日誌：

每次調查行動的時間戳
已測試和排除的假設
支持或反對每個假設的證據
做出的決策和理由

此日誌對事後分析和監管披露具有重要意義。

第三階段：補救

目標：解決根因並恢復正常操作。

3.1 補救選項矩陣

根因	短期補救	長期補救
數據漂移	啟用後備邏輯；增加人工審查	再訓練/微調數據管道；添加漂移監控
供應商模型更新	回滾到先前模型版本（如果合同允許）	談判合同中的版本穩定條款；評估替代供應商
提示配置	回滾提示更改；部署修復的提示版本	添加提示版本控制和暫存測試流程
集成失敗	修補解析邏輯；部署修復	添加集成測試；改進輸出驗證
對抗性輸入	添加輸入驗證/過濾；臨時限速	紅隊測試；對抗性輸入的額外護欄
訓練數據	回滾到先前模型版本	識別和修正訓練數據問題；再訓練

3.2 部署驗證

在部署任何修復之前：

在生產流量的代表性樣本上測試修復
驗證修復解決了觀察到的故障模式
驗證修復沒有在其他使用案例中引入回歸
讓相關利益相關者批准在生產中部署修復
記錄部署時間戳和部署者

第四階段：披露

目標：根據適用要求識別和履行外部披露義務。

披露要求因司法管轄區、行業和事件性質而異。以下是主要框架的摘要——根據您組織的具體情況與法律顧問核實。

4.1 EU AI Act（第 73 條）

對於高風險AI系統，提供商必須向相關市場監督當局通報可能構成嚴重事件的事件。截至 2026 年：

什麼觸發通報：高風險AI系統導致或可能導致死亡、嚴重健康損害、基本權利的嚴重干預，或嚴重的財產或環境損害的嚴重事件
時間表：根據嚴重性，發現後 15 到 72 小時
誰通報：在歐盟市場上市的提供商

4.2 GDPR（第 33 條）

如果AI事件涉及個人數據洩露：

什麼觸發通報：對自然人的權利和自由構成風險的個人數據洩露
時間表：對主管監督機構在知曉後 72 小時內；如果可能對個人產生高風險，也直接通知受影響個人
誰通報：數據控制者

4.3 HIPAA

如果AI事件涉及受保護的健康信息（PHI）洩露：

對 HHS 的通報：對超過 500 人的事件在 60 天內；對較小的事件每年彙總通報
對受影響個人的通知：在 60 天內
媒體通知：對州、地區、郡或其他司法管轄區超過 500 人的事件
誰通報：受保實體和業務夥伴

4.4 SR 11-7（聯邦儲備/OCC 模型風險管理）

對於受 SR 11-7 指導約束的受監管金融機構：

不是法律義務披露，而是監管期望的模型驗證和監控文件
重大模型故障應記錄並提交監管人員審查
在銀行的模型風險管理框架內通報您的首席風險官和模型風險管理功能

4.5 內部披露

在考慮任何外部披露義務之外：

已通知法律顧問並參與披露決策
已聯繫 CEO/C 層（P0 和 P1 事件）
如果適用，已聯繫董事會審計委員會（監管披露可能觸發的事件）
已評估客戶合同通知義務
已評估媒體聲明（如果事件可能公開或已公開）

第五階段：事後分析

目標：從事件中學習並防止復發。

5.1 事後分析要素

事後分析（也稱為事後回顧或根因分析文件）應在事件關閉後 [5-10 個工作日] 內完成。

最低要素：

事件摘要：1-2 段，包括什麼出了問題，影響，以及如何解決
時間線：帶有時間戳的詳細事件和響應行動列表
根因分析：根本根因是什麼？是否有促成因素？是否有沒有起作用的安全網？
影響評估：受影響的用戶/請求數量，業務影響，監管影響（如果適用）
我們做得好的事情：哪些響應有效？什麼需要保留？
可以改進的事情：哪些響應有缺陷或缺失？
行動項目：具體的改進，負責人和截止日期

5.2 常見事後行動項目

根據事件類型，常見的後續行動包括：

添加或改進 AI 系統的監控指標
在受影響區域的提示或模型配置中添加護欄
使高後果使用案例的人工審查觸發器對較低置信度閾值更敏感
在 AI 供應商合同中添加版本穩定性條款
建立或改進受影響模型的測試集
更新 AI 治理文件以反映新識別的風險

常見陷阱

將 AI 事件作為基礎設施事件響應：軟件停機響應程序不適合無聲的 AI 輸出質量問題。AI 事件通常需要不同的檢測機制、不同的調查方法和不同的修復選項。

等待確定性再採取行動：AI 事件調查很少立即產生確定性的根因。定義觸發遏制行動的初始嚴重性評估標準，而不等待完整的根因分析。

未記錄調查過程：調查日誌對事後分析和監管披露至關重要。建立從事件開始的運行文件的習慣，而非在解決後重建時間線。

忽略上游數據問題：許多 AI 事件的根因在輸入或訓練數據中，而非模型本身。調查不應在模型配置或提示處停止——它應該延伸到數據管道。

沒有測試修復：在生產中部署 AI 修復而不先在代表性測試集上驗證它，有引入新問題的風險，同時試圖解決原始問題。

操作手冊基礎設施需求

有效的 AI 事件響應需要預先存在的基礎設施——您無法在事件期間建立它：

不可變審計日誌：帶有模型版本、時間戳和輸入/輸出哈希的每個 AI 請求的日誌，可以隔離受影響的請求並支持調查
模型版本追蹤：知道哪個確切的模型版本對哪個時間段的輸出負責
監控和警報：自動检测輸出質量退化的系統，理想情況下在用戶報告之前
事件管理系統：追蹤事件時間線、行動項目和溝通的工具
文件的地方：調查日誌和事後分析的記錄存儲庫

預約與 Ertas 的發現電話 →

對於在高後果環境中部署 AI 的受監管行業，Ertas Data Suite 提供您的 AI 事件響應操作手冊需要的基礎設施：不可變的、帶時間戳的審計日誌、模型版本追蹤和數據血緣——作為您數據準備工作流程的副產品生成的，而非事後組裝的。