什麼時候不該用 AI：六種會翻車的場景

幾乎所有談 AI 導入的文章都在告訴你「可以用在哪」，很少告訴你「哪裡絕對別碰」。但對企業而言，避開一次翻車的價值，往往超過十次成功的嘗試——因為翻車的不是某個任務，而是整個組織對 AI 的信任，以及可能發生的對外損失。這篇整理六種高機率翻車的場景。它們的共同點是：問題不在 AI 不夠聰明，而在場景的條件和 AI 的特性根本不匹配。每一種我們都會講清楚三件事：為什麼會翻車、現在該改用什麼、以及什麼條件成立後可以回頭再評估。

六種會翻車的場景

場景一：結果必須完全準確，且沒有人能複核

典型情境：讓 AI 直接產出對外的財務數字、法規引用、醫療或工程結論，產出直接發出或存檔，中間沒有人檢查。

為什麼會翻車：生成式 AI 的本質是「根據機率產出最像正確答案的文字」，而不是「查證後給出保證正確的答案」。它會用完全自信的語氣輸出錯誤內容——錯誤的數字、不存在的法規條文、編造的引用來源，這在業內稱為幻覺（hallucination）。沒有人複核時，錯誤會一路走到終點。本站對這個機理有專門分析：LLM 幻覺與虛構分析。

改用什麼：需要保證準確的輸出，用「可驗證的系統」：資料庫查詢、報表系統、規則引擎，加上既有的人工複核流程。AI 最多用在「產出草稿給人改」，且改的人要有能力與權責判斷對錯。

什麼條件下可回頭評估：流程中加入了強制的人工複核節點，且複核者有明確的把關標準與責任；或者場景允許「錯了能攔住」（輸出先進沙盒、先給內部看）。

場景二：高頻重複，但規則完全確定

典型情境：每張訂單按固定欄位轉錄進系統、每天固定格式報表、檔案按明確規則改名歸檔。

為什麼會翻車：這不是 AI 會出錯的問題，而是殺雞用牛刀——規則完全確定的工作，傳統自動化（腳本、RPA、表格公式、系統內建的排程）做得更便宜、更快、而且每次都一樣。AI 反而引入不確定性：同樣的輸入可能得到不同輸出，還多了一筆 API 費用和審核負擔。

改用什麼：先問「這件事能不能寫成 if-then 規則」。能，就用確定性工具：n8n 這類流程工具的普通節串接、Excel 巨集、系統原生排程。把 AI 留給規則寫不出來的部分。

什麼條件下可回頭評估：任務中出現了規則無法涵蓋的模糊判斷（例如「從自由文字中理解客戶意圖」），可以把「確定的部分」留給傳統自動化、「模糊的部分」交給 AI，做成混合流程。

場景三：資料高度敏感，且無法本地部署

典型情境：想把客戶身分證字號、病歷、未公開的併購案資料、核心演算法原始碼貼進線上 AI 工具「試試看」。

為什麼會翻車：資料一旦送出公司邊界，你就失去了對它的完整控制：它經過供應商的伺服器、可能進入日誌、條款可能允許用於模型改進。個人帳號的免費版工具風險最高——資料條款和企業版常常不同。外洩的代價（監管處分、客戶求償、商譽）可能遠超這個場景省下的所有成本。

改用什麼：三條路，依序考慮：其一，去識別化後再用（拿掉能識別個人與機密的欄位）；其二，本地部署開源模型（Ollama、LM Studio、vLLM 這類方案，資料完全不出網）；其三，這個場景暫時不用 AI。分級判斷方法見企業資料安全基本盤。

什麼條件下可回頭評估：公司完成資料分級並劃出紅線；採購了資料條款明確的企業版方案並簽訂資料處理協議；或本地部署的軟硬體條件到位。

場景四：需要明確的法律責任歸屬

典型情境：對客戶的正式承諾文件、具有法律效力的通知、需要署名負責的專業意見（法務、審計、醫療、結構計算），希望由 AI 直接產出並發出。

為什麼會翻車：AI 不能承擔法律責任。當產出造成損害，責任會回到使用它的人和公司身上——「這是 AI 寫的」不是免責理由，反而可能被視為未盡注意義務。如果產出還涉及專業執業範圍，由不具資格的一方產出本身就有合規疑慮。具體的責任邊界因行業與司法管轄區而異，必須諮詢你們的合格法律顧問，本文不構成法律意見。

改用什麼：人署名、人負責的流程不變，AI 降級為「輔助」：幫負責人整理素材、產生草稿、檢查遺漏，最終判斷與署名由具資格的自然人完成，並保留人工決策的紀錄。導入前的法務盤點見AI 合規與風險邊界。

什麼條件下可回頭評估：法務與合規部門確認了該場景的使用邊界、複核責任人與紀錄保存方式之後，AI 可以固定為草稿輔助角色。注意：「AI 直接對外承擔專業責任」這個方向本身，短中期內都不建議期待。

場景五：任務本身定義不清

典型情境：「用 AI 優化我們的管理」「讓 AI 幫我們提升客戶體驗」——說不出輸入是什麼、輸出長什麼樣、做對了怎麼判斷。

為什麼會翻車：AI 是放大器，不是定義器。人都講不清楚的任務，AI 只會把混亂執行得更快、更大量。專案會陷入「產出很多、可用的很少、沒人說得清哪裡不對」的狀態，最後團隊對 AI 失去信心。

改用什麼：先做人該做的事：把任務寫成 SOP——輸入是什麼、步驟有哪些、輸出標準是什麼、誰驗收。寫 SOP 的過程中你多半會發現，真正的問題不是缺 AI，而是流程本身沒理清楚。

什麼條件下可回頭評估：當你能拿出一份書面標準，讓兩個新同事照著做能得到差不多結果時，這個任務才準備好交給 AI。

場景六：量太小，不值得建流程

典型情境：一個月做一次的報告、一年兩次的簡報，想為它搭建知識庫、建自動化工作流。

為什麼會翻車：任何 AI 工作流都有固定成本：資料整理、提示詞調校、測試、上線後的維運。低頻任務攤不平這些成本，而且因為太久沒用，每次用都要重新熟悉，維運的知識也會過期。算下來不如手動做，或臨時用聊天型工具單次處理。

改用什麼：低頻任務直接用通用對話工具「隨手做」：把材料貼進去、單次完成、人檢查後使用。不建知識庫、不建自動化、不寫提示詞模板。成本估算方法見AI 成本怎麼算。

什麼條件下可回頭評估：業務量成長讓頻率上來了（從每月一次變成每天一次），或者這個流程被證明是高價值、值得標準化時。

對照總表

場景	翻車的根本原因	現在改用	回頭評估的條件
必須全對且無人複核	幻覺無人攔截	可驗證系統加人工複核	加入強制複核節點
高頻但規則確定	不確定性多餘	腳本、RPA、表格公式	出現規則寫不出的模糊判斷
資料敏感且無法本地化	資料出界失控	去識別化、本地部署、或不用	分級完成、企業條款到位
需要法律責任歸屬	AI 無法負責	人署名，AI 僅輔助	法務確認邊界與紀錄方式
任務定義不清	混亂被放大	先寫 SOP	兩個新人照做結果一致
量太小	固定成本攤不平	聊天型工具單次處理	頻率或價值顯著上升

常見誤區

誤區一：「AI 不行」等於「永遠不行」。 上面每個場景都附了回頭評估的條件。不該用是「現在的條件下不該用」，條件變了結論就會變。把這篇當檢查表定期重跑，而不是當黑名單。

誤區二：用別的公司的結論套自己的場景。 「某行業都能用 AI 做某事」不代表你能：你們的資料敏感度、複核人力、監管環境都不同。判斷永遠從自己的六題開始。

誤區三：把「先上了再說」當成敏捷。 在容錯高的內部場景快速試驗是敏捷；在對外、涉法、涉敏資料的場景「先上了再說」，是把公司暴露在無法回收的風險裡。

誤區四：六種場景之外的都放心用。 這篇列的是最高風險的六種，不是完整風險清單。任何新場景上線前，都先問一遍：錯了誰發現、誰負責、代價多大。

下一步

• 判斷完「該不該用」，接下來判斷「用哪個」：選 AI 工具的判斷框架。
• 場景三與場景四的完整展開：企業資料安全基本盤與AI 合規與風險邊界。
• 確認場景安全之後，動手建第一個流程：不寫程式做出你的第一個 AI 工作流。