技術 [Day 13]：LLM-as-a-Judge 到底適合判什麼？

在 Day 12 文章裡談規則式（Rule）Guardrails 時有個界線很明顯：有些事情只要條件寫得夠清楚，根本不需要 LLM As A Judge 來協助...

技術 [Day 11]：實戰-組合 Day 7-Day 10 的心法、以 PII Guardrails 為目標合成測試資料

Day 7 到 Day 10 分別談了 Seed、Stage、Dependency 與 Quality Control。四個部分各自拆清楚後，要把它們接成一條...

技術 [Day 10]：資料生得出來不代表能驗收：替合成管線設計 Quality Control 機制

Day 9 把 redacted_text 和 entity_candidates 接回同一版 source_text。這能避免三份資料各說各話，卻還不能回答一...

技術 [Day 6]：客戶資料不能拿出來，我們要怎麼測 AI Guardrails？

在 Day 5 的文章中我們把「不要洩漏個資」拆成六個可以重跑的驗收情境，而文章最後留了一個很實際的問題：在測試 Guardrails 時三個案例可以手搓一搓生...

技術 [ Day3]：「不要洩漏個資」太模糊：怎麼把政策轉譯成 Guardrails 可以測試的控制項？

Day 2 把 Guardrails 可以介入的位置展開了：從使用者輸入、檢索資料，到工具執行前後，都可能需要控制。但架構圖、流程圖畫完，工程師還有一個問題沒得...

技術 [ Day 2]：在調用 LLM 的流程中到底可以在哪裡加 Guardrails？拆解 7 個防護時機

上一篇，筆者把問題放在企業的 GRC 需求：政策要求系統控制什麼，又要留下什麼證據，才能說明控制確實發生？ 回顧：《Day1：AI Guardrails 不應...

技術 [ Day 1]：AI Guardrails 不應只是 AI Security、更是企業實踐 GRC 的手段之一

談到 AI Guardrails，常見的反應是：「這是 AI Security 的事吧？」也有人會問：「把限制寫進 Prompt 不就好了？」或是：「模型都這麼...

技術 Day25 - LLM 應用安全：OWASP Guardrails 防 Prompt Injection 與資料外洩（含實測）

🔹 前言 在 Day21–Day24，我們已經讓系統 更快、可回滾、能再訓練，並且具備 多模型路由 的能力。 但功能之外，還有另一個不可忽視的挑戰：安全性。 接...