2025 證券下單前風控：我反對用 LLM 放行下單（Opinion）
前提
排除
我先把立場講死：在「對外服務 + 必須人審 + 內控稽核」的下單前風控檢核裡，我反對用 LLM 當「放行裁決器」。
LLM 可以幫你整理證據、寫出可讀的審核摘要、把缺口點出來；但它不該決定「放行/阻擋」。不是因為 LLM 不夠聰明，而是因為你承擔不起責任鏈變成黑箱。
你可能會想反駁我：「我們有人審啊。」
我也看過很多團隊這樣講——然後上線後反而更容易出事，因為人審被迫背下一個它根本無法回放的決策。
Premise（本文前提）
- 對外服務：客戶/外部系統會依你輸出行動（不是內部 demo）。
- Human‑in‑the‑loop：任何 AI 輸出最終必須人類審核。
- 內控稽核：你必須能事後重放、交代快照/版本/批准人。
- 定位：你在做「交易輔助的下單前檢核流水線」，不是自動交易代理。
Exclusions（本文排除）
- 你要做自動下單/自動交易決策：那是另一套安全與責任模型；這篇不提供合理化。
- 你做不到版本與快照留存：沒有證據鏈，你不該上 LLM。
- 你沒有 kill switch / 降級路徑：系統出事時你停不下來，那你更不該把裁決交給模型。
理由 1：你存了對話，不等於你存得起「當時的世界」
我最怕的一句話是：「我們都有 log。」
因為很多人講的 log，是聊天記錄、prompt、以及模型回覆。這些東西在稽核語境下常常不夠，原因很簡單：稽核要的不是當時的說法，而是當時的世界。
你要能回答的問題長這樣：
- 當時用的是哪個倉位快照？來源是什麼？時間戳是多少？
- 當時套用的是哪一版限制表？哪一版規則？誰批准那次變更？
- 當時的例外/豁免是否存在？有效期限？批准人？
如果你把「放行」交給 LLM，就算最後有人審，你也會遇到這個尷尬：
人審按下批准的那一刻，並不等於人審理解了「當時的世界」。
它很可能只是理解了模型寫的一段摘要。
我的判斷標準很粗暴：
同一份 evidence bundle（快照 + 版本 + 規則結果 + 批准紀錄），能不能在乾淨環境重跑出同結果？
不能，就不要談「模型裁決」。
理由 2：人審不是護身符；沒有 kill switch 的人審只是在背鍋
你以為「有人審」就安全，現實常常相反：
當模型、依賴服務、或資料源開始不穩，人審會變成背鍋點——因為系統故障會被包裝成「人也同意了」。
我想像的真實場景是這樣的：
- 上午一切正常，LLM 的摘要很順、很像人講話
- 下午遇到尖峰時段，延遲變長、快照偶爾取不到
- 團隊為了 SLA，把一些檢核關掉、把 LLM 當成「最終裁決」加速通過
- 最後事故發生時，紀錄長得像：「人審批准 + 模型說合理」
你很難用「我們有人審」保護自己，因為你沒有把系統的停損條款寫進流程。
所以我反對 LLM 當裁決器的另一個原因是：
只要你接受「裁決 = 可以被降級、可以被停止」，你就會自然把裁決留在 deterministic checks，而不是留在 LLM。
理由 3：你會低估 prompt 注入/繞路心智，然後把例外流程玩爛
下單前檢核一定會遇到例外：臨時額度、特殊客戶、臨時風控參數調整。
最容易被玩壞的地方，是你把例外流程變成「寫一段看起來合理的理由」。
一旦 LLM 被賦予裁決權，你等於提供一個新的攻擊面：
不是「規則對不對」，而是「誰比較會寫理由」。
我寧可讓 LLM 做一件事：把例外需要的證據列出來、把缺口指出來，讓人審去決定是否批准；
我不希望 LLM 去做另一件事：替例外做裁決。
我願意承擔的 trade-off（我不是裝全能）
如果你接受「LLM 不當裁決器」，你會失去一些看起來很誘人的東西：
- 你沒辦法做到極致自動化：因為最後那一步你要留給 deterministic checks + 人審。
- 你要多做工程：你得做 evidence bundle、版本策略、事件留存、降級路徑。
- 你要接受結果更「乾」：規則引擎的輸出不像人講話，但它可追責、可重放。
我願意承擔這些 trade-off，因為在金融內控裡，這些不是成本，是保命錢。
行動建議：如果你現在就要上線「下單前檢核」
我會照這個順序做（先把底線打滿）：
1) 先定義 evidence bundle：每一次檢核要封存什麼（快照/版本/原因碼/批准紀錄）。
2) 裁決層 deterministic：規則引擎說 pass/fail；LLM 不得覆蓋。
3) LLM 只做說明：摘要、對照、缺口提示；把人審的注意力導向「缺什麼證據」。
4) 寫死 kill switch：缺快照/版本不明/超時 → 自動降級到規則直出 + 人工處理。
如果你要「框架怎麼選」的清單結論（LangGraph / Semantic Kernel / AutoGen），我已經寫成 Set：
2025 證券下單前風控檢核：LangGraph vs Semantic Kernel vs AutoGen 低後悔選擇（Set）
如果你要看「為什麼這樣做才能被稽核時活下來」，我也寫了 Analysis：
2025 證券下單前風控檢核：為什麼要把 AI 代理鎖在「證據鏈」而不是「裁決」（Analysis）
一段帶假設的算例：你把裁決交給 LLM，事故成本會用「工程師時間」加倍付回來
這不是統計報告，是我用來做 sizing 的保守估算（你可以把數字換成你的現實）。
- 假設：一年 2 次需要對外交代的爭議/稽核抽查（含客訴、內控抽樣、或交易爭議）
- 假設：每次要還原「當時的世界」需要 2 位工程師 + 1 位風控/產品，各投入 2 個工作天
- 假設：工程師日成本抓 NT$8,000（很保守），風控/產品日成本抓 NT$6,000
那麼單次成本約是：
- 2 位工程師 × 2 天 × 8,000 = 32,000
- 1 位風控/產品 × 2 天 × 6,000 = 12,000
- 合計 ≈ 44,000/次（還沒算會議、跨部門溝通、以及「最後仍可能拼不出來」的代價）
一年 2 次就是 ≈ 88,000/年。更糟的是：這種成本通常不會寫進你的預算表，但會直接吃掉交付節奏、拖垮信任。
我反對 LLM 當裁決器，核心不是「怕模型答錯」；而是你把裁決交給它後，會把本來可以在設計階段解掉的問題，變成事後用人力硬補的問題。
邊界條件：什麼情況我允許「看起來像放行」的 LLM 決策？
我不是說 LLM 永遠不能做任何決策，我說的是：不要在對外下單前檢核裡，把它放到裁決位置。
如果你符合下面這幾條，我可以接受你做「看起來像放行」的自動化（但仍然不是 LLM 最終裁決）：
- 只在沙盒/紙上交易（paper trading）：結果不會直接影響真實下單
- deterministic checks 仍是最終 gate：LLM 只能做建議，無法覆蓋規則結果
- evidence bundle 做得出來：你能重放當時快照/版本/原因碼
- 有明確 kill switch：出事能立刻降級到純規則 + 人工
一旦你不符合這幾條，我就會回到原本立場：不要讓 LLM 放行。
FAQ
LLM 在下單前檢核裡，最適合做什麼？
最適合做三件事：整理證據、對照歷史、指出缺口。它越像「審核助理」，越安全；越像「裁決官」，越危險。
如果我真的很想把放行自動化，最安全的做法是什麼？
把「放行」留在 deterministic checks，讓 LLM 只做「建議與說明」。你可以自動化很多事，但不要自動化責任鏈。
只要有人審，為什麼還不夠？
因為人審不等於可回放。稽核會問「當時的世界」，不是問「當時人看了什麼摘要」。你如果沒封存快照/版本/原因碼，人審最後只會變成背鍋點。