Governance by Construction for Generalist Agents

📌 IBM 提出 CUGA：在不微調模型的情況下，為通用 LLM 代理加入五層可編寫的治理機制

你是否曾擔心，讓 AI 代理在企業系統裡自由使用工具時，會不小心觸發違規或暴露敏感資料？隨著代理型應用在醫療、金融等受管制領域的增長，如何在不重新訓練模型的前提下，確保其行為可預測、可審計且符合合規，成為亟待解決的問題。

🤔 治理不能是事後補丁，必須貫穿代理的執行管線

現有做法多半依賴提示詞工程或事後過濾，難以在規劃、工具呼叫、輸出等關鍵節點統一 enforce 政策。當代理需要跨多個工具與介面運作時，這種零散的守則容易留下漏洞，且每次換領域都要重新建構。

🧪 CUGA 的政策即程式碼層：五個結構性檢查點

研究團隊提出一個模組化的 policy‑as‑code 框架，名為 CUGA，它不修改底層 LLM，而是在代理執行的五個關鍵階段插入可編寫的治理原語：

1. Intent Guard – 在規劃之前攔截使用者意圖，阻止惡意或誤導的請求。
2. Playbook – 直接注入系統提示詞，引導推理遵循預先定義的工具序列與決策流程。
3. Tool Guide – 在工具呼叫邊界檢查參數與權限，確保每次調用符合使用規範。
4. Tool Approvals – 作為 Human‑in‑the‑Loop 閘門，對高風險操作（如刪除紀錄、寫入敏感檔案）要求人工確認。
5. Output Formatter – 過濾並結構化最終回應，防止洩漏不應暴露的資訊。

這五個階段共同形成一個運行時治理架構，使政策成為代理執行管線的一部分，而非事後補救。

🔍 醫療場景示範：動態 Playbook 與人工確認

論文以一個醫療工作流為例展示 CUGA 的運作方式：

• 當使用者請求「查閱病人 X 的最近化驗結果並建議後續檢查」時，Intent Guard 首先確認請求屬於合法的醫療查詢。
• Playbook 動態注入一段標準化的工具序列（先呼叫 EMR 讀取，再調用檢驗資料庫，最後產生建議），確保代理不會跳過必要的驗證步驟。
• 若涉及「更新病人用藥紀錄」這類高風險動作，Tool Approvals 會暫停並彈出人工確認視窗。
• 最終，Output Formatter 將回應格式化為符合 HL7/FHI R 標準的訊息，同時移除任何不應該外洩的個人識別資訊。

整個過程無需對底層 LLM 進行 fine‑tuning，完全依賴可編寫的政策模組來達到可預測、可審計的行為。

💡 治理即基礎設施：可組合的原語提升部署速度與安全性

CUGA 的核心貢獻在於將治理抽象為型別化的、可重用的程式碼原語。這意味著：

• 工程師可以像呼叫函式庫一樣，快速組合 Intent Guard、Playbook 等模組，適用於不同領域的代理。
• 政策的變更只需更新對應的原語，無需重新訓練或重新部署模型。
• 因為治理是在執行時插入，代理的語言理解與生成能力保持原樣，同時獲得可審計的行為軌跡。

⚠️ 目前僅展示於醫療場景，尚未進行大規模跨域評估

論文以 demo 的形式呈現 CUGA 在單一醫療工作流中的表現。文件未提供更廣泛的基準測試、不同模型尺寸的消耗分析，或長期運行穩定性的數據。因此，雖然架構概念清晰，但在其他產業（如金融、製造）或更複雜的多代理協作情境下的適用性仍需進一步驗證。

🎯 對工程師的啟示：先定義政策原語，再讓 LLM 發揮語言能力

• 若你的專案需要在不影響模型語言表現的前提下加入合規守則，可參考 CUGA 的五個檢查點設計自己的政策模組。
• 將政策寫成型別化的函式或類別，讓它們在規劃、工具呼叫、輸出階段自動執行，減少對提示詞的依賴。
• 在高風險操作上保留 Human‑in‑the-Loop 確認，既能保持自動化效率，又能降低誤操作風險。
• 隨著專案擴展，可逐漸建立一個政策原語庫，使新領域的代理部署變得「 plug‑and‑play」。

🔗 論文連結
📝 Governance by Construction for Generalist Agents
👤 Segev Shlomov, Iftach Shoham, Alon Oved, Ido Levy, Sami Marreed @ IBM
🔗 https://arxiv.org/abs/2605.20874

你是否已在自己的 LLM 代理專案中嘗試過類似的政策即程式碼做法？歡迎在留言區分享你的經驗與挑戰 👇

#AI #LLM #AgenticSystems #Governance #IBM #CUGA #PolicyAsCode #醫療AI #合規 #工程實踐