不是二選一

Day 28 的五張表沒有贏家，Day 1 就說了目標不是分高下。最後一天講的是兩條線怎麼一起用——這也是我實際給金融客戶的建議。

混合架構

                        ┌──────────────── 共用層 ────────────────┐
                        │ eval 語料庫（Day 6）                    │
                        │ 稽核日誌 schema（Day 29）              │
                        │ 回歸測試（Day 25）                     │
                        │ fail 決策矩陣（Day 4）                 │
                        └───────────────────┬───────────────────┘
                                            │
   對外流量／可上雲                            │            內部敏感流量／不出境
   ────────────────                           │            ────────────────────
   Client ─▶ Apigee ─▶ Model Armor ─▶ Gemini  │  Client ─▶ LiteLLM ─▶ L1/L2/L3 ─▶ 本機模型
              │  floor setting 強制            │               │  YAML 政策 ＋ 離線更新包
              └─ 稽核 ──────────────────────▶ SIEM ◀────────── 稽核 ─┘

**共用層是重點。**兩條線用不同的引擎，但用同一套語料驗收、同一種格式記錄、同一張決策矩陣定失效行為。這讓稽核看到的是「一套 AI 護欄政策、兩種執行方式」，而不是兩個各自為政的系統。

三個分流原則

1. 依資料分類分流：資料分級是既有的資安制度，直接沿用。能上雲的等級走 Model Armor，不能的走地端。
2. 依動作風險分流：會呼叫工具、會寫入記憶的 agent 流量，不論資料等級，工具參數那一段一律過地端 L3（Day 22–23）——因為那裡需要可解釋的理由。
3. 地端 L1 對所有流量：台灣 PII checksum（Day 16）便宜到沒有理由不對雲端流量也跑一次。雲端線前面加一層薄薄的 L1，補 Model Armor 在 PII 上的邊界。

這 30 天做到的

回頭對照 Day 1 那兩張 OWASP 表的「主戰場」：

沒做到的（誠實清單）

• 供應鏈本身（LLM03 / ASI04）：Day 1 就說不覆蓋，Day 24 只做了連上之後的內容流。
• 多輪攻擊的長期狀態：Day 9 的「送最後三輪」是折衷，真正的跨 session 鋪陳沒有處理。
• 多模態：全系列只做文字。圖像注入（截圖裡的文字指令）留給 ShieldGemma 2 這類圖像分類器，本系列沒碰。
• 硬體攤提：Day 28 成本表明確標了未計入，地端線的真實 TCO 比表上的數字高。
• n 不足的格子：Day 28 有幾格是空的，因為語料建置沒有跟上。這些格子在 repo 的 results/ 會隨語料成長補上。
• Model Armor 的失效行為：Day 13 無法主動重現服務故障，那一格依文件說明填寫，不是實測。

給三種讀者的一句話

給要選型的資安同行：先過 Day 17 的三關再看 benchmark，然後用 Day 27 的八個問題問廠商。

給要自建的工程師：Day 6 的語料庫比任何模型都重要，先建它。

給要簽核的主管：Day 4 的決策矩陣要有人簽名，Day 28 的表要看來源天數，不要只看數字。

這個系列之後

護欄不是終點。它擋的是內容進出的那一刻，而 agent 的風險越來越多發生在那一刻之外——權限、供應鏈、人的判斷。這個系列把「那一刻」做扎實了，剩下的是架構與治理的事，那是另外的 30 天。

感謝一路看到這裡。所有程式碼、語料建置腳本、評測工具都在 repo，歡迎 issue 與 PR——特別是 zh-TW 攻擊語料，這是整個生態最缺的東西。

追蹤 AId3fend

Instagram @aid3fend。
更多 AI 資安筆記：aid3fend.com