Metrics and KPIs for AI 安全 Programs

Defining, measuring, and reporting metrics and KPIs that demonstrate AI security program effectiveness.

概覽

指標將人工智慧安全專案從難以證明其合理性的成本中心轉變為可以展示、追蹤和優化其價值的功能。如果沒有指標，專案領導者就無法回答基本問題：隨著時間的推移，我們是否變得更安全？我們對人工智慧系統的測試是否足夠？我們發現的漏洞被修復了嗎？與它降低的風險相比，我們對人工智慧安全的投資如何？ 然而，選擇不當的指標可能比沒有指標更糟。一個針對「發現數量」進行最佳化的團隊會產生充滿瑣碎問題的報告，但卻遺漏了系統性問題。衡量「已測試系統百分比」的團隊會倉促進行淺層評估，以犧牲深度為代價來最大化覆蓋範圍。只追蹤「平均修復時間」的團隊會產生壓力，要求透過不充分的修復來結束調查結果。 本文介紹了一個專為人工智能安全專案設計的指標架構。它奠定了NIST AI風險管理框架的測量原則，並針對AI系統測試的獨特特徵調整了既定的安全隱患實踐。此框架平衡了覆蓋範圍與深度、活動與結果、技術嚴謹性與執行溝通。

指標框架設計

AI 安全指標的四個維度

有效的指標計劃可以衡量四個互補的維度： 覆蓋率：我們測試了多少 AI 攻擊面？覆蓋率指標回答了程式是否足夠覆蓋組織的人工智慧系統以及是否測試了每個系統的足夠攻擊面。 有效性：我們在尋找真正的漏洞方面有多擅長？有效性指標評估研究結果的品質和重要性，而不僅僅是數量。 效率：我們的資源運用如何？效率指標評估專案在時間、成本和團隊利用率方面是否處於最佳運作狀態。 影響：組織實際上變得更安全了嗎？影響指標衡量該計劃最終試圖實現的結果——降低風險、更快的修復、更少的生產事故。 每個維度都需要領先指標（顯示未來績效的預測指標）和落後指標（確認過去績效的結果指標）。健康的指標計劃會追蹤這兩種類型以實現主動管理。

指標選擇原則

衡量重要的事情，而不是容易的事情：API 呼叫計數和測試輸出行數很容易衡量，但幾乎無法告訴您任何有關程式有效性的信息。不要因為能產生令人印象深刻的數字就去測量那些微不足道的可用數量。 確保指標驅動正確的行為：每個指標都會產生激勵。在採用指標之前，請問：「如果團隊僅針對該指標進行​​最佳化，會產生良好的結果嗎？」如果不是，則該指標需要一個平衡的配對指標。 將指標置於上下文中：沒有上下文的原始數字毫無意義。 「47項發現」毫無意義。 「12 項評估中的 47 項發現，其中 8 項關鍵發現比上一季增加了 23%」提供了有助於判斷的背景。 趨勢超過閾值：絕對值不如趨勢重要。在不斷增長的人工智慧投資組合中每季度發現 30 個漏洞的團隊與在穩定的人工智慧投資組合中發現 30 個漏洞的團隊的表現有所不同。追蹤一段時間內的趨勢並與背景因素相關聯。

覆蓋率指標

系統覆蓋範圍

人工智慧系統測試覆蓋率：在規定的時間窗口（通常為 12 個月）內已評估的生產人工智慧系統的百分比。 公式：（過去12個月評估的AI系統數量/生產AI系統總數）x 100 目標：NIST AI RMF成熟度為3級或以上的組織為80%+。較低的目標適合建立其計劃的組織。 注意事項：此指標需要準確的人工智慧系統清單，這本身就是一個重大挑戰。包括透過 API 使用的第三方人工智慧服務，而不僅僅是內部開發的模型。依系統風險等級對指標進行加權 - 高風險系統的 100% 覆蓋比低風險系統的廣泛覆蓋更重要。 部署前測試率：部署前測試的新人工智慧系統或主要更新的百分比。 公式：（發布前測試的 AI 部署數量 / AI 部署總數）x 100 目標：高風險系統為 100%，中風險系統為 80%+。 這是一個領先指標。高的部署前測試率預示著更少的生產漏洞。低比率預示著未來的事件。

攻擊表面覆蓋

技術覆蓋率：每次參與測試的適用MITRE ATLAS技術的百分比。 公式：（測試的適用ATLAS技術數/適用ATLAS技術數）x 100 目標：標準業務達 70% 以上，高風險系統綜合評估達 90% 以上。 這個指標可以防止淺層測試。只在每次參與中測試提示詞注入的團隊會失去資料抓取、工具搶奪、模型挖掘等重要的攻擊類別。使用MITRE ATLAS框架作為覆蓋基線，確保系統廣度。 輸入向量覆蓋率：每個人工智慧系統測試的已識別輸入向量的百分比。 公式：（測試的輸入向量數量/已識別的輸入向量總數）x 100 目標：高風險系統 90% 以上。 輸入向量包括直接使用者提示、文件上傳、API 參數、檢索文件 (RAG)、工具輸出以及任何其他資料進入 AI 系統的管道。每個向量都是一個潛在的注入點。

持續測試覆蓋率

自動掃描頻率：針對生產系統執行自動 AI 安全掃描的頻率。 目標：高風險系統每天一次，中風險系統每週一次。自動掃描補充但不能取代手動評估。 回歸測試覆蓋率：回歸測試套件中包含的先前已識別和修復的結果的百分比。 公式：（迴歸測驗的補救結果/總補救結果）x 100 目標：100% 為關鍵和高度發現，80%+ 為中等發現。

有效性指標

尋找品質

嚴重/高發現率：被分類為嚴重或高嚴重性的調查結果的百分比。 公式：（嚴重 + 高發現值 / 總發現值）x 100 應仔細解釋該指標。非常高的比率（超過 50%）可能表明團隊只報告了重要的發現，而未能全面了解情況。非常低的比率（低於 10%）可能表示測試淺或嚴重程度評級錯誤。適當的範圍取決於受測系統的成熟度－成熟的系統應該有較少的關鍵發現。 結果接受率：被系統擁有者接受為有效的報告結果的百分比。 公式：（接受的發現/報告的發現總數）x 100 目標：90%+。低接受率表示在尋找文件、嚴重性分類或技術準確性方面存在品質問題。單獨追蹤有爭議的發現並分析爭議的模式。 新穎發現率：代表組織人工智慧系統中先前未識別的漏洞類別的發現百分比。 公式：（新漏洞類別中的發現結果/總發現結果）x 100 這是團隊跟上不斷變化的威脅情況的能力的領先指標。新穎發現率下降可能表明團隊正在重複使用相同的測試手冊而不對其進行改進，組織的人工智慧系統在安全方面正在成熟，或者兩者兼而有之。與其他指標相關聯以區分這些原因。

影響驗證

確認可利用率：透過示範確認評估影響的調查結果的百分比。 公式：（已證實的影響論證的調查結果/具有影響聲明的總調查結果）x 100 目標：95%+。每一項聲稱具有特定影響（資料擷取、安全繞過、未經授權的操作）的發現都應該有證明該影響的證據支持。沒有證據的影響索賠會損害可信度。 誤報率：進一步調查後確定為誤報的調查結果的百分比。 公式：（假陽性結果/總結果）x 100 目標：5%以下。追蹤誤報以識別評估方法問題。自動測試中誤報率的上升表示評估標準需要重新校準。

效率指標

資源利用

評估吞吐量：每季完成的評估數量，按團隊規模標準化。 公式：每季完成的評估/全職等效測試人員數 隨著時間的推移追蹤該指標以識別容量趨勢。透過穩定的品質指標提高吞吐量顯示效率的提升。吞吐量增加而品質下降表示團隊的力量過於分散。 評估時間：從評估請求到最終報告交付的平均經過時間。 目標：根據評估複雜度而變化。按評估等級進行追蹤（例如，快速掃描：1 週，標準評估：4-6 週，綜合評估：8-12 週）。增加評估時間可能表示積壓的成長、複雜性的增加或流程效率低。 自動化比率：自動化工具與手動測試執行的總測試工作量（以小時為單位）的百分比。 公式：（自動測試時間/總測試時間）x 100 隨著專案的成熟，這個指標應該會呈現上升趨勢。 然而，不存在通用目標——適當的比例取決於被測試的人工智慧系統的複雜性和新穎性。新的系統需要更多的手動測試；易於理解的系統類型可以透過自動化進行更嚴格的測試。

成本指標

每次評估成本：計劃總成本除以已完成的評估數量。 此指標可以與外部諮詢成本進行比較，並支援特定評估類型的自製與購買決策。 每個發現的成本：項目總成本除以可操作的發現數量。 目標：追蹤趨勢而不是絕對值。每次發現的成本降低表示效率提高（假設發現品質得以維持）。每次發現的成本極低，可能表示發現的問題被一些瑣碎的問題誇大了。

影響指標

修復效果

平均修復時間（MTTR）：從發現報告交付到確認修復的平均時間，以嚴重程度階段。 目標：嚴重 — 7 天，高 — 30 天，中 — 90 天，低 — 180 天。這些目標應與工程領導階層達成一致並納入 SLA 中。 MTTR 是展示該計劃是否正在推動實際安全改進的最單一指標。快速 MTTR 顯示發現的結果是可操作的、溝通良好的，由工程團隊決定優先順序的重要性。緩慢的 MTTR 可能表示發現品質不佳、缺乏工程支援或失敗指導不足。 修復完成率：在商定的 SLA 內修復的問題的百分比（以嚴重程度）。 公式：（SLA 內補救的結果/報告的結果總數）x 100 目標：95%+ 為嚴重，90%+ 為高，80%+ 為中。 每月追蹤該指標並升級趨勢。完成率下降是安全債務不斷增加的預警訊號。 補救驗證率：已通過重新測試驗證的補救結果的百分比。 公式：（已驗證的補救措施/聲稱的補救措施）x 100 目標：嚴重和高為 100%，中等為 80%+。未經證實的補救措施是不可靠的。團隊有時會根據程式碼變更將發現結果標記為已修復，但沒有確認漏洞實際上已緩解。 修復有效率：已驗證的成功消除漏洞的補救措施的百分比。 公式：（成功的補救措施/已驗證的補救措施）x 100 目標：90%+。修復有效率低表示修復指導不足或開發團隊缺乏人工智慧安全專業知識。

降低風險

漏洞密度趨勢：隨著時間的推移，每個人工智慧系統的發現數量，按嚴重程度劃分。 漏洞密度的下降趨勢表明，組織的人工智慧系統正在變得更加安全——無論是透過更好的開發實踐還是更有效的修復。每季在整個投資組合中追蹤此指標。 重複率：在現有人工智慧系統中識別並修復後，在新人工智慧系統中重新出現的漏洞類別的百分比。 公式：（新系統中發現的先前在其他系統中發現的漏洞類別/新系統中發現的漏洞類別總數）x 100 高重複率表明紅隊演練的經驗教訓沒有融入開發實踐中。此指標激勵對開發人員訓練、安全開髮指南和防止常見漏洞類別的架構模式的投資。 生產事件相關性：生產中屬於紅隊測試之前識別類別的 AI 安全事件數量與不屬於先前識別類別的 AI 安全事件數量。 該指標展示了紅隊的預測價值。如果生產事故始終發生在紅隊已測試的類別中，則該計劃已得到很好的校準。如果事件發生在未經測試的類別中，則表示覆蓋範圍有差距。

報告和溝通

執行儀表板

設計一個執行級儀表板，讓專案健康狀況一目了然： 標題指標（每月更新）：AI系統測試覆蓋率、關鍵/高發現數、嚴重程度的MTTR、部署前測試率。 趨勢圖（12 個月滾動）：尋找隨時間變化的嚴重性分佈、修復完成率趨勢、覆蓋率趨勢。 風險亮點：未解決的關鍵和高發現（按開放天數計算）、未經測試就部署的新人工智慧系統、已識別的新威脅類別。 資源摘要：團隊利用率、評估積壓、即將進行的計畫評估。

利害關係人特定報告

不同的受眾對相同數據需要不同的看法： CISO/安全領先力：專注於風險指標、覆蓋範圍差距和資源需求。每月報告節奏。 工程領導：專注於尋找數量、修復 SLA 合規性和重複模式。每月報告節奏。 人工智慧產品團隊：專注於特定於其係統的發現、修復指南和部署前測試結果。每次參與加上季度總結。 董事會/審計委員會：關注整體風險狀況、監管合規範圍和同比趨勢。季度報告節奏。

基準測試

如果可能，請根據行業數據對您的指標進行基準測試。來源包括SANS年度安全調查（開始包含特定於AI的指標）、特定於行業的共享資訊組織（用於金融服務的FS-ISAC、用於醫療保健的H-ISAC）、來自AI工具創業的供應商基準報告以及同行組織比較（貫穿CISO的同儕網路）。 基準測試需要謹慎——組織環境差異很大，在沒有環境標準化的情況下比較原始數據可能會產生誤導。專注於基準趨勢和比率而不是絕對值。

常見指標陷阱

虛榮指標：看起來令人印象深刻但不顯示程序健康狀況的指標。 「執行了 10,000 個自動化測試案例」並沒有說明這些測試是否有效或目標系統是否實際上更安全。 遊戲提示：如果團隊根據發現數量進行評估，他們將拆分發現以增加數量。如果根據MTTR進行評估，他們將進行開發人員接受不充分的修復。橫向定性審查來平衡定量指標。 衡量活動而不是結果：工作時間、參加的會議和書面報告衡量的是努力，而不是結果。重點在於衡量安全結果的指標，而不是規劃活動。 忽略背景：發現較少的季度並不一定比發現較多的季度更糟。對較成熟系統的較少發現可能表示安全狀況有所改善。關於新範圍系統的更多發現可能表明測試的有效擴展。始終在上下文中解釋指標。 過度測量：追蹤過多的指標會削弱注意力並產生報告開銷。從 5-8 個核心指標開始，僅在明確需要額外衡量時才進行擴展。

參考文獻

• NIST AI風險管理架構（AI RMF 1.0），2023年1月。 https://www.nist.gov/artificial-intelligence/ai-risk-management-framework — AI風險管理框架，包括MEASURE功能中的測量要求。
• MITRE ATLAS（人工智慧系統的對抗性威脅格局）。 https://atlas.mitre.org/ — 共用覆蓋率指標基礎的技術分類。
• OWASP法學碩士申請前10名，2025年版。 https://owasp.org/www-project-top-10-for-large-language-model-applications/ — 用於尋找分類指標的風險分類。
• SANS研究所。 「安全指標：取代恐懼、不確定性和懷疑。」https://www.sans.org/ - 適用於人工智慧安全方案的通用安全替代方法。