Structuring AI 安全 Teams

Organizational frameworks for building and structuring AI security teams that effectively address the unique challenges of securing AI systems.

概覽

人工智慧安全並不是傳統應用程式安全貼上新標籤。攻擊面根本不同——模型投毒、提示詞注入、資料提取、對抗性範例和模型盜竊在傳統軟體安全中沒有直接的類似物。試圖將人工智慧安全責任移植到現有應用程式安全團隊而不進行結構調整的組織始終會發現差距：機器學習特定的漏洞未被識別，紅隊練習錯過了人工智慧原生攻擊向量，人工智慧系統的安全審查預設檢查基礎設施和 API 認證，而忽略了最重要的模型層風險。 建立有效的人工智慧安全團隊需要深思熟慮的組織設計。團隊必須彌合安全專業知識（威脅建模、對抗性思維、漏洞分析）和機器學習工程知識（模型架構、訓練管道、推論系統）之間的差距。僅僅靠紀律是不夠的。無法讀取模型訓練程式碼的安全專家將錯過資料投毒向量。從未進行過滲透測試的機器學習工程師不會對模型部署持敵對態度。 本文為不同規模的人工智慧安全團隊提供了具體的組織框架——從新創公司的單一嵌入式安全工程師到大型企業的專門人工智慧安全部門。它涉及角色定義、招募策略、協作模型和報告結構，這些結構決定了人工智慧安全團隊是否成功或成為產品團隊圍繞的孤立職能。

組織模型

模型1：嵌入式安全工程師（1-10 ML 工程師）

在早期組織或小型人工智慧團隊中，專門的人工智慧安全團隊是不切實際的。有效的方法是在 ML 團隊中嵌入具有安全意識的工程師，或將 AI 安全作為現有安全團隊中的主要職責。 結構：

CTO / VP Engineering
├── ML Engineering Team (5-10 engineers)
│   └── AI 安全 Lead (embedded, 1 person)
└── 安全 Team (if exists)
    └── Dotted-line relationship with AI 安全 Lead

關鍵角色：

• AI 安全主管（1 人）：具有安全和 ML 背景的工程師。負責對人工智慧系統進行威脅建模，審查模型訓練管道的資料完整性，建立模型部署的安全標準，並對已部署的模型進行基本的紅隊演習。 此人通常是已開發安全技能的 ML 工程師或已投資於 ML 知識的安全工程師。他們在機器學習團隊內進行日常工作，但與任何現有的安全功能保持報告或諮詢關係。 此模型涵蓋的內容：設計期間的威脅建模、訓練管道的安全審查、模型的基本對抗性測試以及建立初始安全標準。 此模式的困境：單身人士成為瓶頸。綜合紅隊演練、持續監控、安全攻關，都在爭取一個人的時間。 不存在主動安全研究或工具開發的專門能力。

模型 2：專門的 AI 安全團隊（10-50 位 ML 工程師）

隨著人工智慧功能的發展，需要一個專門的團隊。該團隊通常位於更廣泛的安全組織內，但與機器學習工程密切合作。 結構：

首席資訊安全官 / 安全副總裁
├── 應用程式安全
├── 基礎建設安全
├－ AI安全團隊（4-8人）
│ ├── AI紅隊領頭 (1)
│ ├── AI紅隊工程師（2-3）
│ ├── AI安全工程師（1-2）
│ └── 機器學習安全研究員 (1)
└── 安全運營
工程副總裁
├── 機器學習工程團隊
│ └── AI安全冠軍（嵌入式、兼職）
└── 機器學習平台團隊
    └── 安全整合接觸點

關鍵角色：

• AI 紅隊領導者：管理紅隊計畫、規劃參與時間表、制定方法並向領導層報告結果。需要深入了解 AI/ML 攻擊技術和傳統安全評估方法。向 AI 安全團隊經理或直接向 CISO 報告。
• 人工智慧紅隊工程師：針對人工智慧系統執行紅隊交戰。這包括提示詞注入測試、模型提取嘗試、訓練資料推論攻擊、對抗性範例生成以及 ML 依賴關係的供應鏈評估。需要實際的機器學習技能（可以訓練模型）和進攻安全經驗。
• AI 安全工程師：將安全性建置到 ML 平台中。這包括實施模型輸入驗證、為異常模型行為建立監控、設計安全模型服務基礎設施以及為訓練管道建立安全護欄。這些工程師與機器學習平台團隊更緊密地合作，並專注於預防性而非進攻性安全。
• ML 安全研究員：關注 AI 安全研究的最新動態，評估新攻擊技術對組織系統的適用性，開發新穎的探測技術，並為外部研究社群做出貢獻。這個角色對於維持團隊的技術優勢至關重要，但在預算壓力期間往往是第一個被裁減的角色。
• AI 安全冠軍（兼職，嵌入到 ML 團隊中）：接受額外安全訓練並充當團隊內安全意識第一線的 ML 工程師。他們將安全問題回報給人工智慧安全團隊，並確保設計審查中包含安全考量。

模型3：AI安全部門（50+ ML工程師，企業）

擁有大量人工智慧部署的大型組織需要採用更結構化的方法和專門的子團隊： 結構：

CISO
├── AI 安全 Division
│   ├── AI 紅隊 (6-10 people)
│   │   ├── LLM 安全 Specialists (2-3)
│   │   ├── ML Model 安全 Specialists (2-3)
│   │   └── AI Supply Chain Analysts (1-2)
│   │
│   ├── AI 安全 Engineering (4-6 people)
│   │   ├── ML Pipeline 安全 (2-3)
│   │   ├── AI Platform 安全 (2-3)
│   │   └── AI 監控 & 偵測 (2)
│   │
│   ├── AI Governance & Policy (2-3 people)
│   │   ├── AI Risk 評估
│   │   └── AI Compliance & Standards
│   │
│   └── AI 安全 Research (2-4 people)
│       ├── Offensive Research
│       └── Defensive Research
│
├── Application 安全
├── Infrastructure 安全
└── 安全 Operations

該模型引入了大規模所需的子專業化：

• 法學碩士安全專家專注於提示詞注入、越獄、資料提取以及生成式人工智慧系統的獨特攻擊面。
• ML模型安全專家專注於跨傳統ML系統的對抗性範例、模型投毒、模型提取和成員資格推論（分類、推薦、詐欺偵測）。
• AI 供應鏈分析師 評估模型相依性的安全性 - 預訓練模型、資料集、PyTorch 和 TensorFlow 等函式庫以及第三方 AI 服務。
• 人工智慧治理和政策與法律、合規和道德團隊合作，建立人工智慧特定的安全標準，管理人工智慧風險評估，並確保遵守新興人工智慧法規。

角色定義與能力框架

AI紅隊工程師－能力矩陣

1 級（初級，0-2 歲）：
├── 可以執行已建立的提示詞注入測試套件
├── 可以運行對抗性穩健性工具（ART、TextAttack）
├── 了解基本的機器學習模型架構
├── 可以編寫Python腳本進行自動化測試
└── 可以在結構化報告中記錄調查結果
2級（中級，2-5年）：
├── 可以設計和執行客製化的紅隊活動
├── 可以針對特定模型架構開發新穎的攻擊技術
├── 可以端到端地評估訓練管道的安全性
├── 可以評估模型擷取與推論攻擊的可行性
├── 可以向技術和非技術利害關係人展示研究結果
└── 可指導1級工程師
3級（高級，5歲以上）：
├── 可以在複雜的人工智慧系統中領導為期數週的紅隊行動
├── 可以發展新的攻擊方法和工具
├── 可以整體評估組織的AI安全態勢
├── 可以透過安全架構檢討影響AI開發實踐
├── 可以為外部研究和產業標準做出貢獻
└── 可以組成和管理紅隊工程師團隊
4 級（校長/員工，8 歲以上）：
├── 能夠定義與業務目標一致的紅隊策略
├── 可以針對新的威脅類別評估新興的人工智慧架構
├── 可以在產業和監管環境中代表組織
├── 可以為安全工具做出建置還是購買的決定
└── 可以從安全角度影響組織AI策略

招募策略

人工智慧安全人才稀缺，因為它需要跨學科的專業知識。有效的招募策略包括： 僱用學習軌跡，而不是當前交叉點：尋找在一個領域（安全或機器學習）表現出色並具有學習另一領域能力的候選人。一個已經完成了一些機器學習課程並建立了一個簡單模型的強大的攻擊性安全工程師比對兩者都了解很淺的人更好。 內部開發管道：識別對 ML 感興趣的安全工程師和對安全感興趣的 ML 工程師。提供結構化的學習路徑：

安全工程師→人工智慧安全：
1.完成fast.ai深度學習實作課程（4週）
2. 實踐基礎模型訓練流程（2週）
3. 研究AI攻擊論文（Carlini & Wagner、Goodfellow 對抗性範例）
4. Shadow AI 紅隊交戰（2週）
5. 在指導下領導範圍內的人工智慧紅隊演習
機器學習工程師→人工智慧安全：
1. 完整的進攻性安全訓練（OSCP 或同等材料）
2. 研究LLM申請的OWASP Top 10
3. 實施提示詞注入內部工具測試套件
4.影子應用安全評估（2週）
5. 在指導下領導範圍人工智慧安全審查

面試設計：測驗的是對抗性思維，而不僅僅是知識。 面試問題範例：

基於場景：
「您正在審查一個使用協作的推薦系統
過濾。訓練資料包括使用者瀏覽記錄。
帶我了解威脅模型。前 3 名的攻擊是什麼
你會測試什麼，你會如何測試每一項？ 」
預期深度：應辨識資料投毒（操縱
推薦）、模型反演（擷取瀏覽紀錄）、
以及可能的推論攻擊（確定特定使用者是否
位於訓練集中）。應描述具體的測試方法，
不僅僅是命名攻擊類別。
技術：
「這是一個 Python 函數，它透過
休息 API。 [show code] 你看到了什麼安全漏洞？
您將如何在保持模型性能的同時修復它們？ 」
預期：應該識別傳統的網路安全問題
（輸入驗證、速率限制、認證）和 AI 特定
問題（對抗性輸入偵測、模型輸出濾波、
推論拒絕服務成本）。

協作模型

AI 安全與 ML 工程接口

人工智慧安全和機器學習工程之間的關係決定了安全工作是有效的還是戲劇性的。出現了三種協作模式： 諮詢模型（最弱）：設計和實踐完成後，AI 安全審查 ML 團隊的工作。這捕獲了一些問題，但不會影響架構。機器學習團隊可能會抵制需要大量返工的發現。 嵌入式模型（中）：AI 安全工程師參加 ML 團隊設計評審、衝刺計劃和架構討論。他們提供即時安全輸入，但可能會因團隊隸屬關係而失去客觀性。 合作夥伴模型（最強）：AI 安全性保持獨立性，但在 ML 開發生命週期中具有正式的接觸點：

機器學習開發生命週期安全接觸點：
1. 設計階段
   └── AI安全參與威脅建模
       可交付成果：具有優先風險的威脅模型文檔
2. 資料收集階段
   └── AI安全審查資料來源與完整性控制
       可交付成果：資料管道安全評估
3. 訓練階段
   └── AI安全評論 訓練基礎設施安全
       可交付成果：培訓環境安全基線
4. 評估階段
   └－ AI紅隊進行對抗性評估
       可交付成果：對抗性穩健性報告
5. 部署階段
   └── AI安全審查服務基礎設施與監控
       Deliverable: Deployment 安全 checklist signoff
6. 生產階段
   └── AI安全監控模型異常行為
       可交付成果：持續監控儀表板和警報規則
7. 事件回應
   └－ AI安全主導AI特定事件調查
       可交付成果：帶有根本原因分析的事件報告

AI安全與產品安全接口

人工智慧安全團隊也必須與傳統產品安全合作，因為人工智慧系統部署在具有傳統攻擊面的應用程式中。職責分工應明確： AI安全擁有：模型層攻擊（對抗性範例、提示詞注入、資料投毒、模型竊盜）、訓練管道安全、模型供應鏈、AI專用監控。 產品安全擁有：基礎設施安全、API認證與授權、網路安全、傳統Web漏洞、通用供應鏈安全。 共享：輸入驗證（對抗性輸入透過傳統 API 輸入）、輸出處理（模型輸出在應用程式中呈現）和事件回應（根本原因涵蓋人工智慧和傳統元件）。

# 範例: 安全 review responsibility matrix
REVIEW_MATRIX = {
    "model_architecture_design": {
        "primary": "ai_security",
        "consulted": ["ml_engineering"],
        "informed": ["product_security"],
    },
    "api_endpoint_design": {
        "primary": "product_security",
        "consulted": ["ai_security"],
        "informed": ["ml_engineering"],
    },
    "training_data_pipeline": {
        "primary": "ai_security",
        "consulted": ["data_engineering", "ml_engineering"],
        "informed": ["product_security"],
    },
    "model_serving_infrastructure": {
        "primary": "ai_security",
        "consulted": ["product_security", "infrastructure"],
        "informed": ["ml_engineering"],
    },
    "user_input_handling": {
        "primary": "product_security",
        "consulted": ["ai_security"],
        "informed": ["ml_engineering"],
    },
    "model_output_rendering": {
        "primary": "product_security",
        "consulted": ["ai_security"],
        "informed": ["ml_engineering", "frontend"],
    },
}

衡量團隊效率

指標框架

AI 安全團隊需要能夠展示價值的指標，同時又不會激勵適得其反的行為（例如尋找簡單、影響較小的錯誤來增加發現數量）：

# AI安全團隊指標框架
指標={
    「覆蓋率指標」：{
        “ai_systems_with_threat_models”：{
            "description": "具有當前威脅模型的人工智慧系統的百分比",
            “目標”：“> 90%”，
            "measurement": "具有威脅模型的系統數量 < 12 個月/AI 系統總數",
        },
        “red_team_coverage”：{
            "description": "過去 12 個月紅隊紅隊的人工智慧系統百分比",
            "target": "> 80% 的高風險系統",
            "measurement": "測試的系統/高風險人工智慧系統總數",
        },
        「安全審查參與」：{
            "description": "安全參與的人工智慧設計評審百分比",
            “目標”：“> 75%”，
            "measurement": "AI安全出勤評論數/AI設計評論總數",
        },
    },
    「有效性指標」：{
        “mean_time_to_remediate_ai”：{
            "description": "從 AI 漏洞報告到修復部署的平均時間",
            "target": "< 14 天為嚴重，< 30 天為高",
            "measurement": "報告日期與修復部署日期之間的中位數天數",
        },
        「預生產捕獲率」：{
            "description": "生產前發現的人工智慧漏洞百分比",
            “目標”：“> 70%”，
            "measurement": "審查/測試中發現的漏洞/總漏洞（包括產品事件）",
        },
        “red_team_finding_severity”：{
            "description": "紅隊調查結果依嚴重程度分佈",
            "target": "追蹤趨勢 - 不應在臨界/高處增加",
            "measurement": "以嚴重性類別劃分的季度計數",
        },
    },
    「成熟度指標」：{
        “security_champion_coverage”：{
            "description": "擁有經過訓練的安全冠軍的 ML 團隊的百分比",
            “目標”：“> 80%”，
            "measurement": "冠軍隊伍/ML隊伍總數",
        },
        “自動化測試覆蓋率”：{
            "description": "在 CI/CD 中進行自動化安全測試的 AI 系統的百分比",
            “目標”：“> 60%”，
            "measurement": "正在管道中進行人工智慧安全測試的系統/整個人工智慧系統",
        },
    },
}

報告結構

AI 安全團隊的報告決定其有效性和獨立性： 向 CISO 報告（建議）：保持與 ML 工程組織的獨立性，確保安全發現不會因產品時間表而受到抑制。風險在於該團隊在組織上可能與他們需要合作的機器學習團隊相距甚遠。 向工程副總裁報告（替代）：更接近工程團隊，使協作更容易。風險在於，安全問題可能會被置於功能交付的優先順序之上。此模型需要一位真正致力於安全的工程副總裁。 向 CTO 報告（新興模式）：在 CTO 同時擁有技術方向和安全態勢的組織中，這在 AI 安全問題和技術戰略之間建立了直接聯繫。當 CTO 具有安全背景或真正感興趣時最有效。 避免：直接向 ML 工程團隊負責人報告。這就造成了結構性利益衝突，負責交付人工智慧產品的團隊也是決定優先考慮哪些安全發現的團隊。

逐步建立團隊

大多數組織無法立即聘請完整的人工智慧安全團隊。這是一個分階段的方法： 第 1 階段（第 1-3 個月）：僱用或指定 AI 安全主管。此人對所有人工智慧系統進行初步威脅評估，建立基本安全標準，並與機器學習工程團隊建立關係。 第 2 階段（第 3-6 個月）：聘請第一位 AI 紅隊工程師。開始預定的紅隊評估，從風險最高的人工智慧系統開始。領導者專注於安全工程（建立預防性控制），而紅隊工程師則專注於進攻性評估。 第 3 階段（第 6-12 個月）：擴展到 3-4 人。增加第二名紅隊工程師和一名人工智慧安全工程師，專注於工具和平台整合。在機器學習團隊中建立安全冠軍計畫。 第 4 階段（第 2 年）：根據調查結果和組織 AI 發展，人數增加到 5-8 人。增加專業化（LLM 安全與傳統 ML 安全），增加研究功能，並將治理和政策角色正式化。 關鍵原則是每個階段都應該具有獨立的價值——組織應該看到每個階段的具體安全改進，而不僅僅是對未來能力的承諾。

常見的組織反模式

孤立的實驗室

作為研究實驗室運作的人工智慧安全團隊——發表論文、建構概念驗證攻擊以及在會議上演示技術——但對組織的人工智慧安全態勢沒有營運影響。團隊做出了令人印象深刻的工作，但從未轉化為降低風險，因為不存在與 ML 工程工作流程的整合。 解決方案：要求至少 70% 的團隊能力用於營運安全活動（威脅建模、紅隊評估、安全工程），不超過 30% 用於研究。將研究主題與作戰結果連結起來——研究實際交戰中出現的攻擊技術，而不是抽象的學術問題。

合規性複選框

人工智慧安全功能主要是為了滿足審計要求而存在。該團隊進行年度評估，產生已提交但未採取行動的報告，並且無權要求採取補救措施。當人工智慧安全向合規職能部門而不是營運安全或工程職能部門報告時，就會出現這種模式。 解決方案：確保人工智慧安全團隊擁有補救追蹤權限和在問題未解決時的升級路徑。將尋找補救措施與工程 KPI 聯繫起來，以便在追蹤功能交付的同一儀表板中可以看到未解決的漏洞。

守門人

AI 安全團隊透過冗長的審核流程阻止每次部署，造成如此大的摩擦，以至於 ML 團隊找到了繞過安全的方法。團隊成為每個人都迴避的瓶頸，並且由於審核過程太慢而未經審核就進行部署。 解決方案：從基於門的審核轉變為基於風險的審核。低風險變更（非安全關鍵模型配置的更新、AI 功能的 UI 變更）會經過輕量級自動審核。中等風險的變更（新的 AI 功能發布、模型重新訓練）透過定義的 SLA（例如 3 個工作日）進行標準審查。高風險變更（新的面向客戶的人工智慧系統、人工智慧安全控制的變更）已全面評估。這種分層確保安全審查能力用在最重要的地方。

影子小隊

整個組織內的多個團隊在沒有協調的情況下進行人工智慧安全工作：平台團隊建立輸入驗證，數據團隊監控數據投毒，安全團隊運行對抗性測試，產品團隊實施輸出過濾——所有這些都是獨立的，存在重複工作、不一致的標準以及職責邊界上的差距。 解決方案：即使人工智慧安全人才分佈在各個團隊中，也要建立一個協調功能，以保持人工智慧安全態勢的統一視圖，制定通用標準並識別覆蓋範圍差距。這可以是一個虛擬團隊（分散式人工智慧安全從業者的定期會議），而不是組織重組，只要有人有權力和責任來維護統一的觀點。

預算和資源分配

AI 安全團隊的預算通常細分如下：

BUDGET_ALLOCATION = {
    "personnel": {
        "percentage": "65-75%",
        "details": "Salaries, benefits, recruiting costs",
        "note": "The largest cost — AI 安全 talent commands premium compensation",
    },
    "tooling_and_infrastructure": {
        "percentage": "10-15%",
        "details": "Commercial tools, 雲端 compute for 測試, lab environments",
        "note": "GPU instances for 對抗性 測試 can be expensive",
    },
    "training_and_development": {
        "percentage": "5-10%",
        "details": "Conferences, courses, certifications, research materials",
        "note": "Essential for a rapidly evolving field — do not cut this first",
    },
    "external_assessments": {
        "percentage": "5-10%",
        "details": "Third-party AI 紅隊 engagements for independent validation",
        "note": "Even the best internal team benefits from external perspective",
    },
    "operational_costs": {
        "percentage": "5%",
        "details": "Travel, operational expenses, community participation",
        "note": "Participation in AI 安全 community is a recruiting advantage",
    },
}

當預算有限時，首先保護人員和培訓成本。一個工具不足但技能強大的團隊會找到有效的方法。一個裝備精良、缺乏技能或現有知識的團隊不會。

關鍵要點

建立人工智慧安全團隊是一項組織設計挑戰，而不僅僅是招募挑戰。正確的結構取決於組織的規模、人工智慧成熟度和風險狀況。各種規模的關鍵成功因素都是一致的：確保團隊同時擁有安全和機器學習專業知識，與機器學習工程建立正式的協作接觸點，保持足夠的獨立性以誠實地報告結果，並通過與實際風險降低而不是活動量相一致的指標來衡量有效性。 最稀缺的資源是那些能夠對人工智慧系統進行對抗性思考、具有足夠機器學習深度以理解實際可能性的人。組織應該透過交叉培訓計畫投資內部培養此類人才，而不是等待人才市場成熟。

參考文獻

• 微軟（2024）。 「AI紅隊：經驗教訓。」微軟安全部落格。 https://www.microsoft.com/en-us/安全/blog/2024/06/04/ai-red-teaming-lessons/——建立第一批專門的人工智慧紅隊之一的組織經驗教訓。
• NIST AI 100-2 (2024)。 「對抗性機器學習：攻擊和緩解的分類和術語。」國家標準與技術研究所。對人工智慧安全角色和責任進行分類的框架。
• 人擇（2024）。 「負責任的擴展政策。」人類研究。 https://www.anthropic.com/research/responsible-scaling-policy — 為安全團隊設計提供資訊的人工智慧安全評估組織結構範例。
• OWASP (2025)。 「OWASP 法學碩士申請前 10 名。」https://owasp.org/www-project-top-10-for-large-language-model-applications/ — AI 安全團隊必須涵蓋的漏洞類別的參考。