快速摘要
AI 出錯不是「會不會」的問題，而是「什麼時候」。這篇提供一份實用的 AI 事故應變計畫，讓你在事故發生時知道該怎麼做。
常見 AI 事故類型
| 類型 | 範例 | 嚴重度 |
|---|---|---|
| 資料洩漏 | AI 在回應中洩漏訓練資料中的個資 | 嚴重 |
| 錯誤輸出 | AI 提供錯誤的醫療或法律建議 | 嚴重 |
| 偏見歧視 | AI 在招聘中歧視特定族群 | 嚴重 |
| 安全漏洞 | Prompt Injection 導致未授權存取 | 嚴重 |
| 成本失控 | API 被盜用或迴圈呼叫導致鉅額帳單 | 中 |
| 服務中斷 | AI 供應商的 API 斷線 | 中 |
| 品質下降 | AI 模型更新後品質變差 | 低-中 |
應變流程
AI 事故應變的五個階段：
- 偵測：發現事故
- 遏制：阻止事故擴大
- 調查：找出根因
- 修復：解決問題
- 預防：防止再發
偵測
AI 事故的偵測管道：
- 監控系統：異常的 API 呼叫量、成本暴增
- 使用者回報：建立簡單的回報機制
- 品質抽查：定期抽查 AI 輸出品質
- 安全掃描：定期的安全測試和 Prompt Injection 測試
遏制
發現事故後的立即行動：
- 判斷事故嚴重度（Critical / High / Medium / Low）
- Critical 和 High：立即停用受影響的 AI 功能
- 通知相關人員（依升級路徑）
- 保留現場：不要急著修改設定，先記錄當前狀態
調查
- 蒐集相關的 log 和記錄
- 還原事故的時間線
- 識別根因（是 Prompt 問題？模型問題？設定問題？）
- 評估影響範圍（多少使用者受影響？資料是否外洩？）
修復與預防
- 修復根因
- 驗證修復效果
- 通知受影響的使用者
- 更新 AI 使用政策和安全設定
- 撰寫事故報告（what happened, why, what we did, what we'll do differently）
- 排定改善項目的時程
常見問題
AI 事故和一般 IT 事故有什麼不同？
AI 事故通常更難偵測（例如模型偏見的累積效應），影響範圍更難界定（AI 輸出可能已經被多人使用），而且根因分析更複雜（模型是黑盒子）。
需要建立專門的 AI 事故團隊嗎？
大型企業建議有。中小企業可以把 AI 事故納入現有的 IT 事故團隊，但要確保成員有 AI 相關知識。
AI 事故需要通報主管機關嗎？
如果涉及個資外洩，台灣個資法和 GDPR 都有通報義務。其他類型的 AI 事故目前沒有強制通報要求，但未來 EU AI Act 可能會有。