AI 事故應變計畫：當 AI 出錯時的處理流程

為什麼 AI 需要專屬的事故應變計畫

傳統的資安事件應變（Incident Response）處理的是系統被入侵、資料被竊取、服務被癱瘓。AI 系統的事故類型則截然不同：模型可能產生歧視性的輸出、洩漏訓練資料中的個資、或是因為幻覺給出錯誤的專業建議。這些問題的根源在於模型行為，無法用傳統的防火牆或入侵偵測系統來攔截。

這些事故用傳統的 IR 流程處理不了，因為「系統」本身沒有被入侵——它按照設計在運作，只是輸出了不該出現的內容。傳統 IR 的假設是有一個可以修補的漏洞或一個可以隔離的受感染節點，但 AI 的問題出在模型的統計行為，無法用 patch 一次性修復。你需要一套專門針對 AI 行為異常的應變流程，涵蓋從偵測、分類、遏制、調查到預防的每一個環節。

台灣企業在導入 AI 後，經常面臨一個尷尬的狀況：IT 部門的資安事件處理 SOP 裡面根本沒有 AI 相關的條目。當 AI 產生不當輸出、洩漏客戶資訊、或是被攻擊者利用時，團隊不知道該由誰負責、該走什麼流程、甚至不確定這算不算是「事故」。這篇文章的目的就是幫助你建立一套 AI 專屬的事故應變計畫，讓團隊在事故發生時有章可循。

從實務角度來看，AI 事故的頻率正在上升。隨著越來越多企業將 AI 整合到客服、內容產製、資料分析等核心流程中，出錯造成的影響也越來越大。根據多個產業報告，2024 年和 2025 年全球 AI 相關事故的數量相較前年成長了超過兩倍。提前準備好應變計畫不只是資安合規的要求，更是營運持續性的基本保障。

AI 事故分類

建立應變計畫的第一步是定義事故的類型。飛飛建議將 AI 事故分為五大類，每一類的特徵、影響和處理方式都不同。清楚的分類有助於團隊快速判斷應變等級和所需的資源。

第一類：資料洩漏

AI 系統輸出了不該出現的敏感資訊。這類事故可能發生在 AI 訓練階段（訓練資料中混入了敏感內容，模型學會了這些內容並在回答中輸出）或是使用階段（使用者在 Prompt 中輸入了機密資訊，這些資訊被雲端 AI 服務記錄或用於訓練）。

實際案例：2023 年三星半導體員工將內部原始碼貼進 ChatGPT 協助除錯，這些資料進入了 OpenAI 的訓練管道。三星隨後禁止員工使用外部 AI 工具。這個案例之所以廣為人知，是因為三星是全球性的大企業，但類似的情境每天都在中小企業發生——員工為了方便，把內部文件、客戶名單、財務報告貼進免費版的 AI 聊天介面。

另一個值得注意的案例是 2024 年某金融機構的內部 AI 助理，在回答員工提問時意外輸出了另一位客戶的帳戶資訊片段。調查後發現是 RAG（Retrieval-Augmented Generation）系統的權限設定有問題，讓助理能夠檢索到不屬於提問者權限範圍的文件。

處理重點：確認洩漏的資料範圍和敏感等級、評估資料是否已進入模型訓練管道、通知受影響的資料主體、向主管機關通報（如適用個資法）、檢查 AI 系統的資料存取權限設定。

第二類：幻覺造成損害

AI 的錯誤輸出被採信，導致實際損失。幻覺（Hallucination）是所有大型語言模型的已知問題，模型會以非常自信的語氣產出聽起來合理但實際上錯誤的內容。當這些錯誤內容涉及法律、醫療、金融等高風險領域時，就可能造成實際損害。

實際案例：2024 年加拿大航空的客服 AI 告訴乘客可以在旅行後追溯申請喪親折扣，但這不符合公司政策。法院判決加拿大航空必須依照 AI 的承諾給予折扣，因為 AI 是公司的代理人。這個案例建立了一個重要的法律先例——企業要為其 AI 系統的輸出承擔責任。

另一個案例是美國律師使用 ChatGPT 產出法律文件，結果 AI 引用了多個根本不存在的判例。法官發現後對律師進行了處罰。這提醒我們，AI 輸出的每一筆資訊都需要人工驗證，特別是在專業領域。

在台灣的情境中，如果一家保險公司的 AI 客服告訴客戶某份保單可以理賠某個項目，但實際上保單條款並不包含這個理賠項目，公司可能面臨的法律責任與上述加拿大航空案例類似。

處理重點：確認有多少使用者收到了錯誤資訊、評估可能的法律和財務責任、修正模型或調整 Prompt、主動通知受影響的使用者、保留相關的對話日誌作為證據。

第三類：偏見事件

AI 的輸出呈現系統性的偏見或歧視。偏見可能來自訓練資料（如果訓練資料中男性工程師的比例遠高於女性，模型可能學會將「工程師」與「男性」做更強的關聯），也可能來自模型的設計或 Prompt 的措辭。偏見事件特別棘手的地方在於，它可能長期存在但不容易被發現，直到受影響者投訴或外部審計發現。

常見場景：履歷篩選 AI 系統性地降低特定性別或學歷背景的候選人分數。圖片生成在特定職業描述時只產出特定性別的影像。貸款核准模型對特定地區或年齡層的申請者給予較低的信用評分。翻譯 AI 在處理性別中性語言時總是預設使用男性代名詞。

在台灣，偏見事件的風險包括 AI 系統對原住民名字或新住民姓名做出不當的分類、招聘 AI 對特定大學的畢業生有系統性的偏好或偏見、以及客服 AI 對使用不同語言（國語、台語、客語、外語）的客戶提供不同品質的回應。

處理重點：確認偏見的範圍和影響（影響多少決策）、暫停相關功能、進行偏見審計、修正訓練資料或模型、對受影響者提供補救措施、重新訓練或微調模型以消除偏見。

第四類：Prompt Injection 被利用

AI 系統的安全護欄被攻擊者繞過，被用來做非預期的事。Prompt Injection 是目前 AI 應用最常見的攻擊手法之一。攻擊者透過精心設計的輸入，讓 AI 忽略原本的指令，轉而執行攻擊者想要的動作。這類攻擊的危險在於它不需要入侵系統——攻擊者只需要是一個普通的使用者。

常見場景：客服 AI 被誘導輸出 System Prompt，暴露內部知識庫的存取方式和公司的商業邏輯。自動化 AI Agent 被注入惡意指令，執行了未授權的操作（例如發送未授權的電子郵件或存取非公開的資料庫）。AI 搜尋助手透過讀取包含惡意指令的網頁內容，被間接注入指令（Indirect Prompt Injection）。

實際案例：2024 年多個 GPTs 在上線後幾天內就被使用者透過 Prompt Injection 提取出了完整的 System Prompt 和上傳的知識檔案。這些資訊隨後被公開在社群媒體上。雖然這些 GPTs 大多是個人開發者的作品，但如果企業的 AI 應用面臨同樣的攻擊，後果會更嚴重。

處理重點：確認攻擊向量和影響範圍、關閉被利用的功能、修補安全護欄、檢查是否有資料外洩、檢視 AI 系統的權限範圍是否過大。

第五類：合規違反

AI 系統的使用方式違反了法規要求。這類事故在台灣越來越受關注，特別是在金融業（金管會對 AI 使用有具體規範）、醫療業（衛福部對 AI 醫療器材有分類管理辦法）和公部門（行政院有 AI 指引）。

常見場景：企業將客戶資料傳送到境外的 AI 服務進行處理，但未取得客戶同意或未符合跨境傳輸的法規要求。AI 系統在做出影響個人權益的決策時（如貸款核准、保險理賠），未提供可解釋的理由，違反相關法規對自動化決策透明性的要求。

處理重點：確認違反的具體法規條文、評估潛在的罰則和法律責任、暫停相關 AI 功能、向法務部門報告、必要時向主管機關自首或通報。

事故嚴重等級定義

在分類事故類型之後，還需要定義嚴重等級，以決定應變的速度和資源投入。飛飛建議使用四個等級：

這個等級表需要根據企業的實際情況調整。金融業和醫療業的 Critical 門檻通常更低——任何可能影響客戶財務或健康的 AI 錯誤都應該被視為至少 High 等級。

應變流程模板

飛飛建議企業用以下六步驟流程處理 AI 事故。每個步驟都有具體的執行細節和檢查要點。

第一步：偵測與通報。建立 AI 輸出的監控機制，包括使用者回報管道、自動化的內容審核、定期的輸出抽樣檢查。通報門檻要明確：什麼程度的問題需要啟動應變流程。建議在 AI 應用的介面上提供「回報問題」的按鈕，讓使用者可以一鍵通報 AI 的不當輸出。同時設定自動化的關鍵字偵測，當 AI 的輸出中出現特定的敏感詞彙或模式時自動觸發告警。偵測機制不應該只依賴技術手段，員工的主動通報同樣重要，因此需要建立一個低門檻的通報文化，讓員工在發現任何可疑的 AI 行為時願意立即回報。

第二步：分類與評估。用上面的五類分類法判斷事故類型，並評估嚴重程度。嚴重程度的評估需要考慮三個維度：影響範圍（幾個使用者受影響）、資料敏感度（公開資訊、內部資料、機密資訊、個人資料）、潛在損失（法律責任、財務損失、聲譽影響）。這個步驟需要由具備 AI 知識和業務理解的人來執行，純技術人員可能低估業務影響，而純業務人員可能誤判技術嚴重性。

第三步：遏制。根據嚴重程度決定遏制措施：

低風險：調整 Prompt 或輸出過濾規則，增加特定場景的安全提示。

中風險：暫停特定功能或限制特定類型的查詢，在受影響的功能上加入人工審核環節。

高風險：暫停整個 AI 服務，切換到人工處理，同時啟動備援方案。

遏制的原則是寧可過度反應也不要反應不足。暫停一個 AI 功能幾小時的成本遠低於讓一個有問題的 AI 繼續運作造成更大損害的成本。

第四步：調查。收集事故相關的日誌：使用者輸入、模型輸出、System Prompt 版本、模型版本、RAG 檢索結果（如適用）。找出根本原因：是 Prompt 設計問題、模型行為問題、資料品質問題、權限設定問題、還是缺少輸出過濾。調查過程需要保全證據，特別是在可能涉及法律責任的情況下。所有的調查發現都應該記錄在統一的事故追蹤系統中。

第五步：修復與驗證。修改 Prompt、增加過濾規則、或更換模型版本。在測試環境驗證修復效果，用原始的問題輸入測試，確認問題已解決。做回歸測試，確認修復沒有影響正常功能。修復後的變更需要經過程式碼審查（如果涉及程式碼修改）或 Prompt 審查（如果涉及 Prompt 修改）才能部署到生產環境。

第六步：事後檢討與預防。寫事後報告（Post-mortem），記錄時間線、根本原因、影響範圍、修復措施。更新 AI 使用政策和監控規則。如果是新的攻擊手法，更新紅隊測試清單。事後檢討會議應該在事故解決後的一週內舉行，參與者包括技術團隊、業務團隊和管理層。會議的氛圍應該是學習導向而非究責導向。

通報範本

AI 事故的內部通報應該包含以下資訊。使用標準化的格式可以確保每次通報都包含足夠的資訊，也方便後續的統計和趨勢分析。

事故編號：[AI-INC-YYYY-NNN]
事故時間：[發現時間] / [估計開始時間]
事故類別：[資料洩漏 / 幻覺損害 / 偏見 / Prompt Injection / 合規違反]
嚴重等級：[Critical / High / Medium / Low]
影響範圍：[受影響的使用者數量 / 功能 / 資料類型]
事故描述：[簡述發生了什麼，包含具體的輸入和輸出範例]
目前狀態：[調查中 / 已遏制 / 已修復]
已採取的措施：[目前為止做了什麼]
後續行動：[下一步計畫和時間表]
負責人：[事故負責人和聯絡方式]
相關系統：[受影響的 AI 系統名稱和版本]

對外溝通的原則：承認問題、說明你在做什麼、不要過度承諾時間表。在溝通中避免使用過於技術性的語言，用使用者能理解的方式說明發生了什麼和可能的影響。如果涉及個資洩漏，台灣個資法要求在發現後 72 小時內通知當事人和主管機關。建議在事故發生的第一時間就通知法務部門，由法務評估是否需要對外通報。

對外溝通的範本可以參考以下結構：說明我們發現了什麼問題、目前已經採取了什麼措施來保護使用者、我們正在進行哪些調查、以及使用者可以採取哪些保護自己的步驟。

日誌與監控

要能有效應變，前提是有足夠的日誌。沒有日誌的 AI 系統就像沒有監視器的銀行——出了事你不知道發生了什麼、影響了誰、問題什麼時候開始的。

AI 系統至少要記錄以下資訊：

每次查詢的輸入和輸出（注意日誌本身的個資處理——日誌中的個資也需要受到保護）。建議對日誌中的敏感資訊做遮罩處理，保留足夠的資訊用於調查，但不要在日誌中留下完整的敏感資料。

使用者身份和存取來源（IP 位址、使用的裝置和瀏覽器）。這些資訊在調查帳號盜用或內部濫用時非常有價值。

使用的模型版本和 System Prompt 版本。AI 系統的行為可能因為模型更新或 Prompt 修改而改變，記錄版本資訊有助於追溯問題的起因。

回應時間和 token 使用量。異常增加可能表示攻擊（例如 Prompt Injection 攻擊通常會產生異常長的輸出）或系統故障。

RAG 檢索結果和來源文件。如果 AI 的回答是基於 RAG 檢索的結果，記錄檢索到了哪些文件有助於判斷錯誤的來源。

日誌保留期限建議至少 90 天，符合大多數法規要求。但日誌本身也包含使用者資料，需要適當的存取控制和加密。只有事故調查團隊和授權的管理人員才能存取完整的日誌。日誌系統本身也需要防篡改機制，確保日誌不會被竄改。

監控指標建議：

異常偵測：單一使用者的查詢頻率突然增加（可能是自動化攻擊）、查詢內容包含已知的 Prompt Injection 模式、同一時間段大量使用者回報問題。

內容審核：輸出中出現敏感關鍵字的比率、輸出的平均長度突然變化、輸出的語氣或格式偏離預期。

錯誤率：使用者標記「回答不正確」的比率變化、客戶投訴中提及 AI 的比率、AI 輸出被人工審核退回的比率。

效能指標：回應時間的變化趨勢、API 呼叫失敗率、token 使用量的異常波動。

事故應變團隊的組成

有效的 AI 事故應變需要跨部門的協作。建議的團隊組成包括：

AI 工程師或 MLOps 人員：負責技術面的調查和修復，包括模型行為分析、Prompt 調整、系統設定變更。這是團隊的技術核心。

產品負責人：負責評估事故的業務影響、決定功能是否需要暫停、以及與利害關係人溝通。產品負責人需要能在技術可行性和業務需求之間做出取捨。

資安人員：負責評估事故的安全面向、確保應變流程符合資安標準、以及協助判斷是否有被攻擊的跡象。

法務人員：負責評估法律責任、決定是否需要通報主管機關、以及審查對外溝通的內容。在涉及個資洩漏或合規違反的事故中，法務的參與特別重要。

公關或客戶溝通人員：負責對外溝通的策略和執行，確保溝通內容準確、及時、且不會造成不必要的恐慌。

中小企業可能沒有這麼多專職角色，但至少需要指定一位 AI 事故的負責人。這個人不一定需要是技術專家，但需要有足夠的決策權限（例如暫停 AI 服務的權限），也需要知道什麼時候該向上報告或尋求外部協助。

演練與準備

光有應變計畫還不夠，團隊需要定期演練。就像消防演練一樣，AI 事故的應變演練可以幫助團隊在真正的事故發生時更快、更有效地反應。

建議的演練頻率是每季一次。每次演練選擇一種事故類型，模擬從偵測到修復的完整流程。演練結束後進行檢討，找出流程中的瓶頸和改善空間。

演練場景建議：

場景一：AI 客服回答了一個關於產品保固的問題，但回答內容與公司的保固政策不符。已有 50 位客戶看到了這個回答。模擬如何偵測、遏制、修復和通知客戶。

場景二：安全團隊發現有人在社群媒體上公開了你們 AI 系統的 System Prompt 和知識庫內容。模擬如何評估影響範圍、更換 Prompt、以及對外回應。

場景三：內部審計發現 AI 履歷篩選系統在過去三個月中，對特定大學的畢業生評分系統性地偏低。模擬如何暫停功能、進行偏見審計、以及對受影響的候選人提供補救。

安全與限制

AI 事故應變有幾個跟傳統資安不同的難點，理解這些限制有助於設定合理的期望：

歸因困難：AI 的錯誤輸出是模型的統計行為，不像傳統漏洞有明確的根本原因。有時候同樣的輸入在不同時間會得到不同的輸出。這意味著調查時可能無法找到一個「根本原因」，只能找到多個「貢獻因素」。

修復不確定：改了 System Prompt 或增加了過濾規則，只能降低問題發生的機率，很難保證問題不再出現。這對於習慣了「修了就不會再壞」的工程師來說是一個觀念上的挑戰。AI 系統的修復更像是風險管理而非漏洞修補。

影響範圍難評估：AI 的錯誤輸出可能已經被使用者採信並採取行動，你很難追蹤下游的影響。例如，如果 AI 客服給了一個錯誤的財務建議，而客戶依據這個建議做了投資決策，損失可能在數週後才浮現。

多模型環境的複雜性：越來越多的企業同時使用多個 AI 模型和服務，當事故發生時，可能需要同時調查多個系統之間的交互作用。這增加了事故調查的複雜度和所需的時間。

這套流程是框架，每個組織需要根據自己的 AI 使用場景調整細節。如果 AI 系統處理的是高風險決策（醫療、金融、法律），應變流程需要更嚴格的標準和更短的回應時間。如果 AI 系統只是用於內部的文書處理或創意發想，應變流程可以相對簡化，但仍然不能省略資料安全的基本要求。

常見問題