90 分鐘下線把 AI 變成事故演練

這篇把 90 分鐘下線事件拆成一份 AI 事故應對 playbook，重點是 rollback、溝通和權責分工。

我做 AI 系統一陣子後，最煩的不是模型答錯，而是它一旦出事，整個團隊才發現自己根本不會「關掉它」。平常大家都在談 eval、prompt、context window，講得像把分數拉高就萬事大吉。結果真碰到外部要求你立刻停機，才知道你沒有 runbook、沒有 kill switch、沒有對外說法，連誰能拍板都說不清楚。那種慌，不是技術慌，是組織慌。

更尷尬的是，很多 AI 團隊把「上線」當成終點，卻沒把「下線」當成同樣重要的流程。我看過太多漂亮 dashboard，卻沒有一條真的能把流量切乾淨的路。看起來像有治理，實際上只是把風險藏得比較好而已。

所以我不是把這件事當八卦看。我是把它當一個系統事故案例看：如果一個 AI 產品可能被要求在很短時間內撤下，那每個團隊都該先想好，怎麼停、誰停、停了怎麼講。

這份洞察的觸發點來自 The New York Times 對 Anthropic 事件的報導。文中提到的硬資訊很直接：他們被告知只剩不到 90 分鐘要把最新 AI 下線。這個數字本身就夠刺眼，因為它代表的不是產品節奏，而是事故節奏。

上線和下線，其實是同一個流程

Executives at the artificial intelligence start-up Anthropic received alarming news from the White House on Friday. They had less than 90 minutes, they were told, to take down their newest A.I.

翻譯一下就是：你不能只會 deploy，還要會 un-deploy，而且這兩件事要同樣熟。AI 產品不是一次性軟體，它更像一個一直在線上的服務，外面有人可以突然要求你停。

我以前在基礎設施團隊就吃過這種虧。最成熟的團隊不會只問「能不能上」，而是先問「如果要關，怎麼關才不會炸」。AI 團隊常常把自己想成研究團隊，結果一上線就變成服務團隊，偏偏還沒補上服務該有的操作能力。

實操寫法很簡單：你的 release checklist 要同時有 launch path 和 takedown path。不要只寫怎麼開，要把怎麼關、誰負責、誰確認、誰通知，全部寫進去。

• 先寫 rollback 步驟，再寫 launch 步驟。
• 把 model 權重、API routing、前端開關拆開。
• 任何一層出事，都要能單獨切斷，不要整包一起綁死。

這聽起來很基本，但很多團隊真的沒有。大家在 demo 時都很自信，真到要停機，才發現自己只是把風險包裝得比較好看。

沒有 kill switch 的 AI，就是等著出包

我最不愛聽的話之一，就是「先上，之後再補控制」。這句話在 AI 產品上特別危險，因為外部政策、平台條款、法遵要求，常常比你的 roadmap 變得更快。

Anthropic 這件事提醒我，AI 系統需要的是操作控制，不只是 model card 和安全聲明。那些文件不是沒用，但它們頂多是說明書，不能代替真正的控制面。當外部環境突然變了，你需要的是能直接切流量、停功能、保留證據的機制。

也就是說，你的架構要預設「會被迫中斷」。如果你不能把某個版本、某個 endpoint、某個 tenant 獨立停掉，那你根本不是在做可控系統，你是在堆依賴，順便祈禱今天不要出事。

我碰過最典型的場景，是客戶一通電話來問：「可以只關掉這個功能嗎？」結果答案是不能，因為功能跟登入、計費、主應用 shell 全綁在一起。這種設計不叫整合，這叫把自己逼進角落。

實操寫法：把 AI stack 切成可單獨關閉的層次，並且定期演練關閉。

• 模型存取放在 feature flag 後面。
• 環境級控制要能直接關，不要靠臨時改 code。
• 每季做一次「真的關掉」演練，量時間，不要只看文件。

如果你對這些問題的答案是「到時候再看」，那你不是有 incident plan，你是有一份看起來很忙的樂觀清單。

法務和工程不能各講各的

AI 團隊最愛假裝有一道牆，叫做工程歸工程、法務歸法務。實際上這面牆很常只是拖延的藉口。工程嫌法務慢，法務嫌工程衝，最後真正出事時，兩邊都在看對方臉色，沒人知道下一步怎麼走。

這篇報導最有價值的地方，就是它讓我看到壓力不是從產品團隊內部來的，而是外部直接壓進來。這代表你不能等事情發生後，再讓法務幫你翻譯成可以執行的動作。runbook 必須先存在，而且要夠白話。

翻譯一下就是：法遵流程不是放在文件夾裡的 PDF，而是控制平面的一部分。只要某個模型或功能有合規觸發條件，團隊就要知道誰能下指令、誰能執行、誰能對外回應。

我看過最糟的情況，是工程已經有修法，卻卡在「到底能不能動」的灰區。這種延誤很貴，也很傷信任，因為外面的人只會看到你們在拖。

實操寫法：寫一頁 escalation matrix，越短越好，越直接越好。

• 什麼事件由誰接手。
• 外部要求來自誰時，誰有權批准。
• 要停哪個功能、先停哪一層、誰負責驗證。

你也可以參考 NIST incident response basics、ISO/IEC 27035，再把它們縮成你公司看得懂的版本。還有 Anthropic 本身的公開資料，也能拿來對照它們怎麼講安全與治理。

真正難的不是停機，是怎麼講清楚

很多團隊以為事故處理到「功能停掉」就算結束，其實最容易翻車的是溝通。使用者不在乎你內部會議開得多細，他只在乎他的工作流程是不是壞了、資料還在不在、你是不是在裝死。

這也是 AI 團隊很常丟臉的地方：上線前文案寫得很會，出事後卻一句話都擠不出來。沉默不會讓你看起來謹慎，只會讓人覺得你在閃。

也就是說，對外說法要先寫好，不是要你假裝沒事，而是要你在壓力下還能講人話。你只需要回答幾件事：發生什麼事、現在關掉了什麼、使用者會受到什麼影響、下一次更新什麼時候來。

我以前看過團隊花三個小時修 status page 的措辭，結果 support 工單已經爆了。比較好的做法反而很土：先發一則白話公告，醜一點沒關係，重點是準確。

實操寫法：先準備三種版本的通知，不要等 crisis 來才現寫。

• 內部通知：給員工看，講決策和責任。
• 客戶通知：講影響範圍和替代方案。
• 合作方或監管窗口：講狀態、證據、下一步。

三種版本都要回答同一組問題，這樣你才不會每個窗口講不同版本，最後自己打自己臉。

別再把英雄主義當流程

我每次看到這種事件，都會對那種「大家熬夜救火」的故事很反感。不是因為人不努力，而是因為太多公司把熬夜當成美德，卻不去處理為什麼會需要熬夜。

翻譯一下就是：英雄主義是壞系統的稅，不是管理能力。你可以偶爾靠人撐過去，但你不能把這件事當成制度。

AI 團隊真正需要的是 rollback culture，像 SRE 訓練 outage 那樣訓練 reversals。不是因為你預期每週都會出大事，而是因為你承受不起第一次出事就手忙腳亂。

我寧可跟一個能乾淨下線模型的團隊合作，也不要跟一個只會說「我們從沒需要關過」的團隊合作。前者知道風險，後者只是運氣還沒用完。

實操寫法：把 rollback 能力列進「算不算真的上線」的標準裡。

• 10 分鐘內能不能停掉。
• 停掉後誰會自動收到通知。
• 怎麼驗證真的沒流量了。
• 使用者失敗時要怎麼說。

這些問題答不出來，就別急著說你已經把 AI 產品做好了。你只是把風險先放上線而已。

可抄的模板

# AI takedown and rollback runbook（可直接改成你公司版本）

## 觸發條件
當以下任一情況發生，就啟動這份 runbook：
- 監管、法務、平台方或高層要求下線
- 安全審查判定不能繼續運作
- 發生重大事故，需要立即停用模型或功能
- 合作夥伴要求暫停服務

## 角色分工
- Incident Commander：負責決策與時間線
- Engineering Lead：負責停用與驗證
- Legal Lead：確認外部義務與限制
- Comms Lead：負責內外部公告
- Support Lead：處理客戶問題與回報

## 立即動作
1. 凍結所有新版本發布
2. 透過 feature flag 關閉模型路由
3. 確認 API 不再打到模型
4. 保留 logs、metrics、trace
5. 通知內部利害關係人

## 驗證清單
- [ ] 前端已關閉
- [ ] API 已關閉
- [ ] background jobs 已暫停
- [ ] cache 已檢查
- [ ] 監控顯示零 live traffic
- [ ] support 與 sales 已收到最新狀態

## 對外說法模板
內部：
- 發生了什麼：
- 已關閉什麼：
- 誰負責下一次更新：
- 下一次更新時間：

客戶：
- 我們已暫停 [功能/模型]，因為正在處理 [問題]
- 期間請預期部分請求失敗或暫時不可用
- 下一次更新時間：[時間]

## 恢復條件
只有在以下條件都成立時才恢復：
- 法務已確認可以恢復
- 工程已驗證修正有效
- 產品已確認使用者影響範圍
- Comms 已準備好更新公告

## 事後檢討
- 這次是什麼觸發下線？
- 停用花了多久？
- 哪一步最卡？
- 哪些動作應該自動化？
- 哪些 owner 一開始不夠清楚？

你可以直接複製這份，再把括號裡的通用字眼換成你自己的系統名稱和責任人。重點不是寫得漂亮，是讓你真的能在壓力來的時候，照著做。

來源說明：我主要根據 The New York Times 的報導和 Anthropic 公開網站整理。上面這份 runbook、拆解和實操建議，都是我自己的延伸整理，不是原文照抄。