當AI功能發生事件時，不能像一般錯誤一樣除錯。「模型返回錯誤結果」可能是由於：資料品質改變、提示注入、分佈偏移或基礎設施問題。BA需要知道如何分析每種類型。
1. AI特有的風險類別
1.1 AI功能的風險分類
| 類別 | 風險 | 可能性 | 影響 | 緩解措施 |
|---|---|---|---|---|
| 模型 | 精確度下降（漂移） | 中 | 高 | 每月評估、漂移偵測器 |
| 模型 | 高風險情境中的幻覺 | 中 | 非常高 | 人工審查門檻、引用要求 |
| 資料 | 訓練資料中毒 | 低 | 非常高 | 資料來源稽核、異常偵測 |
| 資料 | 透過模型輸出洩漏PII | 低 | 非常高 | 輸出掃描、PII遮罩 |
| 偏差 | 歧視性輸出 | 中 | 高 | 定期偏差稽核、多元測試集 |
| 運營 | 模型不可用（API停機） | 中 | 中 | 備用規則型方案、重試邏輯 |
| 安全性 | 提示注入攻擊 | 中 | 高 | 輸入清理、系統提示鎖定 |
1.2 AI風險評分公式
風險評分 = 機率 × 影響度 × 偵測難度
機率：1（罕見）→ 5（頻繁）
影響度：1（輕微）→ 5（重大/法律影響）
偵測：1（容易）→ 5（非常難以偵測）
評分 ≥ 30：關鍵——需要立即緩解計畫
評分 15-29：高——需要在上線前緩解
評分 < 15：中/低——監控，每季審查
2. AI風險登記冊模板
## AI風險登記冊 — [產品/功能]
**最後更新：** YYYY-MM-DD | **負責人：** [BA姓名]
| ID | 風險 | 類別 | 機率 | 影響度 | 偵測 | 評分 | 狀態 | 緩解措施 | 負責人 |
|----|------|----------|-------------|--------|-----------|-------|--------|------------|-------|
| R001 | 3個月後的模型漂移 | 模型 | 3 | 4 | 3 | **36** | 🔴 關鍵 | 每月評估＋警報 | ML工程師 |
| R002 | 醫療情境中的幻覺 | 模型 | 3 | 5 | 4 | **60** | 🔴 關鍵 | 強制人工審查＋引用 | BA＋QA |
| R003 | AI輸出中的PII | 資料 | 2 | 5 | 3 | **30** | 🔴 關鍵 | 交付前輸出掃描器 | 安全性 |
| R004 | API提供商中斷 | 運營 | 3 | 3 | 1 | **9** | 🟡 中 | 備用流程＋逾時處理 | 開發 |
3. AI的事件分類
並非所有「AI出錯」都是事件。BA需要定義：
嚴重程度等級
| 嚴重程度 | 定義 | 範例 | 應對時間 |
|---|---|---|---|
| P0 — 關鍵 | AI造成直接傷害、資料洩漏或導致錯誤的法律決策 | AI批准錯誤貸款、PII洩漏 | 15分鐘內 |
| P1 — 高 | AI無法運作或精確度下降超過20% | 聊天機器人給出無意義的回答、分類器失敗 | 1小時內 |
| P2 — 中 | 精確度下降10到20%，部分使用者受影響 | 召回率從90%降至75% | 4小時內 |
| P3 — 低 | 輕微不一致、邊緣情境問題 | 某些邊緣情境處理不完美 | 下一個衝刺 |
4. AI的事件應對流程
[偵測到事件]
（透過：監控警報 / 使用者投訴 / 代理人升級）
↓
[BA在15分鐘內確認嚴重程度]
├── P0/P1：啟動事件應對團隊
│ ├── 通知：利害關係人＋法務（如需要）
│ ├── 動作：功能旗標關閉或回滾
│ └── 戰情室：BA＋ML工程師＋PM
└── P2/P3：正常衝刺流程＋追蹤
↓
[根本原因分析——需要檢查的4種類型]
1. 模型問題（漂移，需要重新訓練？）
2. 資料問題（輸入分佈改變了？）
3. 基礎設施問題（API錯誤率增加了？）
4. 對抗性行為（提示注入、濫用？）
↓
[緩解措施＋修復]
↓
[48小時內的事後分析（P0/P1）]
5. AI事件事後分析模板
# AI事件事後分析
**事件ID：** INC-YYYY-XXX
**嚴重程度：** P[0-3]
**日期：** YYYY-MM-DD
**持續時間：** X小時Y分鐘
**受影響的功能：** [AI功能名稱]
## 時間表
| 時間 | 事件 |
|------|-------|
| HH:MM | 事件首次由[誰/系統]偵測到 |
| HH:MM | BA收到通知 |
| HH:MM | 功能停用/套用緩解措施 |
| HH:MM | 根本原因識別 |
| HH:MM | 事件解決 |
## 根本原因
**主要：** [技術描述]
**促成因素：** [清單]
## 影響
- 受影響的使用者：[N]名
- 做出的錯誤決策：[N]個（如有）
- 商業影響：[$X / SLA違反 / 聲譽]
## 哪些方面做得好
- [偵測速度快]
- [回滾順暢]
## 哪些方面需要改進
- [偵測缺口：X發生但警報未觸發]
- [應對：Y花費時間過長]
## 行動項目
| 行動 | 負責人 | 截止日期 | 優先順序 |
|--------|-------|----------|----------|
| 新增[條件]的警報 | ML工程師 | [日期] | P1 |
| 將HITL門檻從X更新為Y | BA | [日期] | P2 |
| 用更正後的標籤重新訓練模型 | ML工程師 | [日期] | P1 |
6. 主動風險審查頻率
| 頻率 | 活動 | 負責人 |
|---|---|---|
| 每週 | 審查P0/P1風險項目 | BA |
| 每月 | 對照基準評估模型效能 | BA＋ML工程師 |
| 每季 | 完整AI風險登記冊審查 | BA＋PM＋安全性 |
| 每個衝刺 | 新AI功能的紅隊演練 | BA＋QA |
結論
AI的風險和事件分析不像標準IT運營。BA需要了解AI特有的故障模式、維護最新的風險登記冊，並了解AI出錯時的升級路徑。不是「如果」AI事件會發生的問題——而是「何時」，以及你是否已經準備好。