問題係,傳統 guardrails 多數只係關鍵字或分類器過濾器。呢啲方法往往缺乏操作情境(operational context),結果可能出現兩個問題:
例如跨多步驟嘅提示注入,或者透過工具鏈進行利用,簡單過濾器通常難以發現。
Giskard 將 Guards 設計成一個介乎 AI Agent 同企業系統之間嘅安全層。
與其只檢查 prompt 或最終回應,平台會分析整個代理執行過程,包括:
目標係喺危險行為真正影響生產系統之前就偵測同阻止。
系統唔只係比對關鍵字,而係嘗試理解請求嘅意圖同上下文,例如任務目標、可用工具同資料來源。咁樣 guardrails 可以更準確判斷行為是否合理。
Guards 同時使用多種安全檢測,例如:
當偵測到風險時,系統可以選擇 允許、監控或阻擋 行動。
另一個重點係監察整條 agent execution chain。因為攻擊有時並唔係發生喺輸入或輸出,而係中間步驟,例如:
透過監控整個流程,系統更容易發現潛在問題。
平台嘅核心概念之一係 Policy‑as‑Code。
企業通常有大量治理規則,例如:
Policy‑as‑Code 嘅做法係將呢啲規則轉換成可由系統即時執行嘅控制機制,而唔只係寫喺文件或提示入面。
相關研究指出,AI agent 在受監管或安全關鍵場景中運作時,需要將自然語言政策轉換成可驗證嘅運行時 guardrails,例如建立政策樹(policy tree)並編譯成輕量分類器,用於即時監控行為。
企業可以透過呢種方式設定例如:
由於政策係可版本化同程式化,企業可以隨 AI 系統演進而更新治理規則。
另一個推動企業 AI 治理嘅重要因素係監管。
歐盟人工智能法案(EU AI Act) 採用風險分級制度。若 AI 系統對健康、安全或基本權利有重大影響,就會被列為「高風險系統」,並需要滿足嚴格要求,例如風險管理、透明度、紀錄保存、人類監督同系統穩健性。
像 Giskard Guards 呢類平台,嘗試透過以下方式幫助企業符合要求:
呢啲能力可以協助滿足高風險 AI 系統對監督同技術穩健性嘅要求。
AI agent 治理需求喺高度監管行業尤其明顯。
銀行與保險 可能使用 AI agent 做:
呢啲流程涉及大量敏感金融資料,因此需要確保 agent 不會洩露資料或執行未授權操作。
醫療領域 風險更高。AI agent 可能:
因此 guardrails 必須確保醫療資料保密,並避免自動建議繞過醫護人員監督。
研究亦指出,企業 AI 治理通常需要在基礎架構層面設置政策防火牆,以阻止未授權行動,而唔能單靠模型提示控制。
Giskard 亦將 Guards 定位為歐洲 Sovereign AI(主權 AI)策略嘅一部分。
平台支援本地部署(on‑premise)或受控環境運行,讓企業可以將:
全部保留喺自己嘅基礎設施內,而唔需要完全依賴外部審核 API。
對於需要遵守 GDPR 或 EU AI Act 嘅企業而言,安全與監控基礎設施部署位置往往會影響 AI 系統是否能夠投入使用。
AI Agent 的興起,正在改變 AI 安全系統嘅設計方式。
只分析 prompt 或輸出內容嘅 guardrails,已經難以覆蓋會計劃任務、存取資料同使用工具嘅智能代理系統。
Giskard Guards 代表嘅思路係:
即時監控 AI agent 在整個工作流程中的行為,並用政策規則去控制。
至於呢類平台能否在大規模企業部署中完全避免 AI 失誤,目前仍然有待更多實際案例驗證。但愈來愈多企業開始認為——當 AI agent 進入關鍵業務系統時,呢一層行為級安全機制可能已經變成必需品。