平台上有人問，AI 的可信度分數能不能直接代表安全。我先講結論：分數只能描述模型的把握程度，安全標籤必須對應一條可追溯、可重跑、可申訴的證據鏈。否則 UI 上寫著「高可信度」，事故發生時仍然沒有人知道哪個輸入、哪個版本、哪個決策節點出了問題。

我以前在 fintech 做交易審核，踩過一個很典型的坑。資料庫有 status，log 有 success=true，模型也回傳 0.93，結果客服追查時找不到當時的輸入、policy 版本和人工覆核理由。分數還在，證據已經不在了。

先把決策留成證據

任何影響使用者權益的 AI 決策，都應該產生不可變的 decision record。最低限度要有：

{
  "decision_id": "dec_01J...",
  "trace_id": "tr_8f2c",
  "input_hash": "sha256:...",
  "input_snapshot_ref": "audit/2026/10/29/...",
  "model_version": "risk-2026.10.14",
  "prompt_version": "risk-prompt-v23",
  "policy_version": "policy-18",
  "decision": "manual_review",
  "confidence": 0.78,
  "reason_codes": ["velocity_spike", "new_device"]
}

這些欄位各自回答一個事後問題。hash 用來確認輸入沒有被替換，snapshot reference 讓授權人員取得原始資料，版本欄位讓工程師知道是哪套邏輯做出決定。PII 放在有 retention policy、權限控管和加密的 audit store，record 保存 reference 與 hash。連存取 audit store 的動作也要記錄。

trace_id 要從入口一路傳到 model gateway、feature service、policy engine、queue 和人工介面。每一段再記 span_id 與 parent_span_id。我遇過 API 回覆「已送人工覆核」，實際的非同步 queue publish 卻失敗，前台只留下成功假象。後來把 decision event 和 outbox 綁在同一個 transaction，才沿著 trace 找到問題。

因此，監控不能只寫「模型回覆正常」。至少要能分開看：inference 耗時 840 ms，policy 因 confidence 低於 0.85 轉人工，event 寫入成功，outbox message_id 為 msg_7a19，reviewer 在 10:24 以 A17 覆核。不要讓一個布林值包住五個可能失敗的系統。

可重跑要固定當時世界

很多團隊說系統支援 replay，實際只是把同一段文字送給今天的模型。真正的 replay 必須固定 input snapshot、feature snapshot、model artifact、system prompt、tool schema、sampling 設定、policy、threshold，以及外部服務回應。服務商只保證 production alias 時，最多只能做近似驗證，這個限制要明寫在架構文件。

我會把結果分成兩層。deterministic replay 用固定 artifact 檢查是否得到同一個 decision。forensic replay 允許模型更新，但要求 reason code、policy outcome 和風險邊界可比較。每次都記 replay_run_id、操作者、時間和差異報告，例如：

decision: manual_review -> manual_review
policy: policy-18 -> policy-18
reason_codes: 相同
confidence: 0.78 -> 0.74
差異原因: 原始 model artifact 不可取得

看到這種結果，工程師才知道它能不能當作申訴證據。

人工覆核也要可申訴

人工按下「通過」不能成為一筆覆寫。應該新增 review event，保存 reviewer_id、角色、時間、看到的輸入版本、原始 decision、覆核後 decision、必填 reason code 和介面版本。原始 record 保持不變，決策鏈才不會被最後一次 update 洗掉。

申訴時，案件要

引用原始 decision_id，鎖定歷史 snapshot，重新執行當時 policy，再把差異交給有權限的人處理。不能拿今天更新後的使用者資料代替歷史證據。報告至少列出模型與 policy 版本、reason codes、自動與人工決策時間線、replay 是否成功，以及什麼條件會觸發改判。

分數只能當路由訊號

一套可落地的 policy 可以先這樣設：confidence 大於 0.95 且 reason code 合規才允許自動放行，0.60 到 0.95 進人工，小於 0.60 進高風險流程。schema violation、tool timeout、輸入缺欄位時，直接進例外路徑，高分也不能旁路。

0.95 是 operational threshold，不是真理。先跑 30 天 shadow run，只寫入不影響交易，觀察 decision coverage 是否超過 99%、trace 缺失率是否低於 0.1%、人工 disagreement rate 和 replay mismatch 是否有分類。若高分案件仍有 8% 被人工推翻，就該重做 calibration，不能繼續把它標成高可信度。

讀者可以帶走一張檢查表：immutable decision record、完整 trace、可定位的版本、受控 replay、不可覆寫的人工事件、能引用歷史證據的申訴流程。缺任何一項，安全標籤就只有展示價值。把分數接上自動封鎖按鈕以前，先問一句：這個決策下週能重跑嗎，出了錯能申訴嗎？