一、概述

生成式人工智能已列入企業的路線圖，但我們不應發布任何設計不安全的產品。LLM 改變了威脅模型：不受信任的自然語言會成為攻擊面，輸出可以被武器化，代理可以代表我們采取行動。我將模型視為在沙盒化、受監控且嚴格授權的環境中運行的不受信任的代碼。

主要風險顯而易見。即時注入（包括隱藏在文件和網頁中的間接攻擊）可以覆蓋策略并竊取數據。擁有過多權限的代理可能會濫用工具并執行不可逆的操作。RAG 可能會在提取或檢索時中毒。隱私和 IP 可能會通過訓練回溯或日志泄露。不安全的輸出處理會將模型文本轉換為 XSS 或代碼執行。對抗性提示可能會導致模型 DoS 和成本失控。

企業現實加劇了風險。AI供應鏈（模型、數據集、插件）尚不成熟，容易出現后門和來源漏洞?？捎^察性與合規性存在沖突——我們需要取證，但又不能過度收集個人數據。模型和插件的更新會悄無聲息地改變行為；如果沒有版本鎖定和重新測試，安全性就會下降。內容來源薄弱，使得欺騙和欺詐更容易發生。員工的影子AI會造成我們無法控制的未經批準的數據泄露。

我的策略是零信任和縱深防御：限制輸入、隔離和代理工具，并凈化輸出。部署前的幾項關鍵措施包括：允許出口和工具代理；RBAC 機制，允許破壞性操作；DLP/PII 掃描，并在每一跳上執行嚴格的架構；版本鎖定，并配備終止開關和回滾機制；防篡改、隱私感知日志；持續的紅隊演練，并與發布門密切相關。如果我們無法執行這些控制措施，我們就需要暫停發布。

讓我們深入了解生成性人工智能安全風險的一些細微差別和細節。

二、生成式人工智能安全面臨的最大挑戰

以下是當今確保生成式人工智能安全的最大挑戰的簡要概述— — 摘自當前標準、紅隊報告和最新研究。

1) 即時注入（以及間接即時注入）是新的“SQLi”。攻擊者無需入侵您的后端，即可入侵您的輸入。聊天、文檔、網站、PDF 文件，甚至日歷邀請中的惡意文本，都可能覆蓋模型的指令、泄露機密信息或導致代理濫用工具。這現在是 OWASP LLM 的頭號風險，最近的紅隊工作表明，“開放網絡上的內容”或上傳文件中的內容可能會無形地指示 LLM 竊取數據或采取不安全的操作。將所有模型輸入視為不可信，包括檢索到的網頁和用戶上傳的內容；將工具隔離在允許列表代理之后，并進行模式匹配以查找越獄線索。（OWASP、微軟）

2) 代理/工具濫用和“過度代理”。一旦模型能夠調用工具——查詢數據庫、發送電子郵件、運行代碼——就創建了新的權限邊界。過度放縱的代理（“自動運行所有內容”）仍然是導致險情發生的主要原因：代理可能會被注入的內容引誘，從而調用強大的操作，或無限地鏈接操作。OWASP 明確列出了“過度代理”；微軟紅隊建議采用嚴格的 RBAC、分步限制、敏感操作的人工審批，以及對模型發起的調用進行嚴格的出口控制。想想“有限自主”，即在任何不可逆的情況下，都由人在環。（OWASP，微軟）

3) RAG 中毒和檢索時攻擊。RAG減少了幻覺，但也引入了新的攻擊面。如果你的索引被中毒（或者你的檢索器過于寬松），模型會很樂意在對抗性段落上扎根。新的研究記錄了 RAG 語料庫數據中毒的成功案例，并且可擴展的防御措施仍在不斷完善。強化措施意味著在 LLM 看到檢索到的塊之前，需要進行門控的提取管道、簽名/精選的來源、每個文檔的敏感度標簽以及運行時檢查（例如，“解釋你的來源”、相似性多樣性和異常過濾器）。（亞馬遜網絡服務公司，AWS 文檔）

4) 隱私泄露和 IP 溢出。大型模型確實會記憶，有時會重復訓練片段或敏感上下文；成員推理和數據提取攻擊仍然是一個活躍的研究領域。供應商已經改進了企業默認設置（例如，“默認不針對 API/企業數據進行訓練”），但數據保留、日志記錄和合法保留仍然可能在訴訟或事件響應中暴露提示/輸出。在輸入和輸出路徑上構建 DLP，優先選擇具有可配置保留期的企業/API 通道，并在每次響應中添加針對 PII/機密的顯式掃描程序。（NIST、OpenAI Platform、The Verge）

5) 模型和人工智能供應鏈風險?；A模型、微調、數據集和代理插件構成了漏洞百出的供應鏈。帶有后門或欺騙性對齊的模型（“潛伏代理”）可以通過安全評估，然后在觸發下出現異常行為；下游庫、嵌入或插件可能會受到攻擊；一種新型的“slopsquatting”攻擊利用LLM，使攻擊者產生不存在的軟件包，然后將其發布。您需要像現代軟件供應鏈安全一樣（甚至更多）的出處、簽名的工件、具有行為審查的模型注冊表和依賴關系安全措施。（CIO Dive、安全中心、趨勢科技）

6) 不安全的輸出處理（“不信任字符串”問題）。將 LLM 輸出視為不可信內容。如果渲染它，它可能會成為存儲型/DOM-XSS；如果執行它，它可以運行任意代碼；如果將其傳遞給工具，它可以執行 SSRF 和數據泄露。OWASP 直接指出了這一點。強制執行嚴格的模式，轉義/驗證任何渲染的輸出，禁止直接執行模型生成的代碼，并在下游系統之前設置“策略判斷器”或后處理器。( OWASP )

7) 拒絕服務攻擊 (DoS) 和成本濫用模型。攻擊者（或僅僅是重度用戶）可以強制執行病態工作負載——非常長的提示、巨大的輸出或對抗性采樣——從而降低服務質量或增加您的令牌費用。這被編纂為 LLM04“拒絕服務模型”。每個用戶和每個操作的速率限制、令牌上限、時間盒代理循環，以及對異常令牌/延遲峰值發出警報。( OWASP )

8) 可觀察性與合規性（日志記錄、可追溯性和審計）。取證需要完整的即時/響應日志和工具追蹤；隱私法和合同限制要求最低限度的保留和屏蔽。最新的 NIST 生成式人工智能概要建議采用結構化日志記錄、變更控制和角色隔離的記錄訪問；在歐盟，《人工智能法案》提出了分階段的義務（例如，GPAI/GFM 規則將于 2025 年 8 月 2 日生效），以及針對高風險用途的上市后監控。通過在數據采集時屏蔽敏感字段、將遙測數據與內容分離以及維護具有范圍訪問權限和明確保留策略的防篡改日志來協調這些要求。（NIST 出版物，歐盟數字戰略）

9) 治理漂移和模型/版本風險。模型、安全設置和插件頻繁變化；提供商的“小更新”就可能改變拒絕行為或越獄防御能力。除非每次更改都重新運行安全測試，否則安全態勢會下降。微軟和 NIST 強調持續的 AI 紅隊測試、版本鎖定和門控發布流程——包括終止開關和回滾——這樣你就可以發布更新而不會再次引入舊的故障。（微軟，NIST 出版物）

10) 內容真實性和下游濫用。即使你的系統是安全的，你的輸出也可能被偽造、清洗或武器化。水印在釋義和翻譯的情況下仍然很脆弱，因此各組織傾向于使用出處（C2PA/內容憑證）和來源簽名，以及對人工智能生成的內容進行用戶可見的披露。追蹤你的輸出流向，在可行的情況下添加出處，并假設單靠水印無法拯救你。（EUR-Lex）

三、接下來的90天該做什么

重點關注三個“不后悔”的舉措。

首先，進行GenAI 安全和隱私審計——繪制出敏感數據可能進入提示或模型訓練的位置，并部署數據丟失預防和請求日志記錄等即時控制措施。

其次，在高價值、低風險的用例（“速贏”象限）上進行試點。例如，內部知識助理或代碼生成助手可以快速展示價值，同時最大程度降低客戶風險。使用“影響-可行性”矩陣對此類用例進行優先級排序。

第三，在廣泛推廣之前，實施包含人工審核和關鍵指標（準確度、延遲、每次通話成本）的評估工具。

這些步驟為安全擴展設定了基線。

• 避免已經讓同行絆倒的頂級非受迫性錯誤。錯誤 1：在沒有強大防護措施的情況下部署生成模型——這導致三星等公司的數據泄露和惡意輸出，工程師不小心將機密代碼上傳到了 ChatGPT。解決方案：建立嚴格的提示過濾器、用戶訪問策略和“無敏感數據”規則，直到建立適當的審批流程。錯誤 2：追逐用例而沒有業務一致性——許多團隊構建了華而不實的演示（例如異想天開的圖像生成器），但并不能解決緊迫的業務痛點。相反，應該從明確定義的業務目標和成功指標開始（例如，將呼叫中心處理時間減少 20%）。錯誤 3：跳過評估和監督——在沒有測試幻覺、偏見或性能瓶頸的情況下將生成式 AI 投入生產是失敗的根源。像摩根士丹利這樣的成熟團隊在全公司部署之前會進行嚴格的內部評估和人工反饋循環。從一開始就建立測試、監控和后備計劃。
• 安全和治理刻不容緩。生成式人工智能以新的方式擴大了企業的攻擊面：可能泄露數據或操縱代理工具的提示注入、如果處理不當會執行惡意腳本的模型輸出，甚至開源模型中的供應鏈風險。成熟度較高的公司會像對待任何關鍵任務系統一樣對待生成式人工智能項目——包括威脅建模、基于角色的訪問控制、模型 I/O 加密以及第三方風險審查。同樣，各組織正在建立人工智能治理委員會和“模型風險管理”流程，以便在部署之前審查生成式人工智能用例的合規性、知識產權和道德風險，以符合新興標準（例如 NIST 人工智能風險管理框架、ISO/IEC 23894）和即將出臺的法規（歐盟人工智能法案）。要點是：在項目開始時就解決安全、知識產權和道德問題——后期再改進控制措施要困難得多。
• 數據是差異化因素，也是最難的工作。生成式人工智能依賴于數據，然而 39% 的首席數據官認為數據質量、數據孤島和數據集成是應用生成式人工智能 (GenAI) 的最大障礙。在構建高級模型之前，企業必須理順其數據庫：識別并清理相關數據集，建立可擴展的文檔提取和嵌入管道（進行質量檢查，避免“垃圾進，垃圾出”），并實施訪問控制，確保只使用授權的、符合隱私要求的數據。在實踐中，這可能意味著創建一個包含適當元數據（所有者、時間戳、敏感度標簽）的集中式企業知識向量數據庫，并自動執行數據沿襲跟蹤。早期投資于數據準備的組織（例如，擁有“單一事實來源”知識庫或具有治理功能的數據湖）能夠部署可靠、最新的 GenAI 應用程序，而其他組織則由于無法找到或不可信的數據而陷入“概念驗證煉獄”。
• 人才和文化是 GenAI 計劃的成敗關鍵。理論上，GenAI 可以提高生產力；但實際上，成功取決于人。存在技能缺口：高效的團隊會混合使用數據工程師、機器學習工程師、快速工程師、用戶體驗設計師、領域專家和風險管理官——許多公司仍在努力填補或培養這些職位。提升現有員工的技能至關重要：例如，通過為期 8-12 周的重點培訓項目，培訓軟件工程師進行快速設計和微調，或培訓數據分析師使用 LLM API。同時，變革管理對于解決員工的恐懼和抵觸情緒也至關重要。成功的組織會投資于溝通和培訓，以表明 GenAI 是一種增強工具，而不是工作威脅?？焖僖娦Ш屯该鞯膶υ捒梢詫岩烧咿D變為支持者——例如，在試點項目中，由“ AI 副駕駛”處理重復性任務，以便員工可以專注于更高價值的工作。最后，必須培養高管的支持：知識淵博的支持者會支持切合實際的目標和持續的資金投入，而缺乏知識的高管則可能要么過度興奮，要么過度恐懼。一個可靠的商業案例，加上明確的投資回報率指標（例如，試點結果顯示節省了X小時或客戶滿意度提高了Y%），將有助于獲得并維持高管的支持。
• 嚴格且反復地衡量價值。生成式人工智能是一個新領域——它需要新的 KPI 和實驗性的思維方式。為每個用例預先定義成功指標：輸入指標（例如訓練數據覆蓋率、模型新鮮度）、系統指標（延遲、吞吐量、每次查詢的成本）、質量指標（事實準確率、幻聽頻率、安全完成率），以及最重要的業務成果指標（例如客戶自助服務偏差率、轉化率提升或開發人員速度改進）。許多領先的采用者會運行 A/B 測試或受控部署，以將人工智能增強的工作流程與現狀進行比較。例如，客戶支持團隊可能會衡量人工智能輔助聊天機器人是否能夠在沒有人工交接的情況下解決 30% 以上的查詢。還要衡量可能出現的問題：跟蹤不適當的輸出或停機時間等事件。通過將模型性能與實際業務 KPI 掛鉤，您可以避免虛榮指標的陷阱（例如僅計算聊天次數）。在前 90 天，為這些指標設置一個儀表板和一個節奏（每周或每兩周）來審查進度并重新校準——將 GenAI 部署視為一個持續改進的過程。
• 路線圖展望：安全為成熟企業所用，重點關注新興企業。如前所述，調查顯示，不同成熟度的挑戰存在差異。高成熟度的組織（已在 GenAI 上進行擴展的組織）將安全威脅列為首要風險——這表明，一旦廣泛部署，防止違規、濫用和違反法規就變得至關重要。這些組織正在投資高級措施，例如即時防火墻、帶有 DLP 掃描的模型輸出日志記錄，以及用于治理的強大的模型卡片文檔。相比之下，低成熟度的組織最關心的是找到合適的用例——他們處于探索模式，正在探索 GenAI 能夠真正發揮作用的地方。對他們而言，這意味著在嘗試復雜的特定領域項目之前，應盡早與業務利益相關者接觸，舉辦探索研討會，并可能從一些經過驗證的橫向用例（代碼生成、知識搜索、營銷內容）入手。隨著時間的推移，隨著組織的成熟，挑戰“向右移動”：從創意和人才缺口轉向卓越運營、風險管理和成本優化。成功的 GenAI 路線圖應充分考慮這一演變過程：早期，加倍重視用例選擇和快速取勝策略，以積累發展勢頭；后期，加強治理、安全性和可擴展性，以確保其長久發展。目標是從實驗階段逐步發展成為一個穩定、受管控的 AI 平臺，持續創造商業價值。

四、案例研究和“有效的方法”

案例研究 1：摩根大通——AI 編碼助手的安全保障。大型金融機構摩根大通部署了內部生成式 AI 來幫助開發人員編寫代碼（類似于 GitHub Copilot）。早期，他們的安全團隊注意到 AI 建議中出現了一些看起來過于熟悉的內部代碼片段，這引發了人們對該模型可能泄露專有算法的擔憂。他們的應對措施是實施嚴格的提示，并僅針對非敏感數據對模型進行微調，同時集成了一個代碼片段檢查器：任何 AI 建議的代碼都會與敏感代碼的哈希數據庫進行比較。如果相似度較高，助手會警告用戶，并且不會顯示該建議。這大大減少了潛在的泄漏。此外，摩根大通禁止使用外部 AI 編碼工具（例如公共 Copilot），并將開發人員引導到具有這些防護措施的內部工具。結果：開發人員仍然可以受益于 AI 自動完成功能，但會受到監督，以防止無意中共享 IP。到2024年，摩根大通報告稱，通過該助手的代碼泄露事件為零，并且他們開源了部分解決方案，作為金融行業其他公司的最佳實踐。有效的措施包括：主動監控捕捉類似的輸出、定制解決方案以剝離敏感數據，以及明確的政策（禁止使用未經批準的工具，并結合安全的替代方案）。

案例研究 2：微軟的 Bing Chat——強大的提示隔離。當微軟推出 Bing Chat（由 GPT-4 提供支持）時，用戶很快就找到了提示注入的方法，并揭示系統角色“Sydney”以及開發者指令。這些早期的越獄（2023 年 2 月）得到了廣泛宣傳 [66]。微軟的應對措施堪稱迭代強化的典范：他們首先限制了會話長度（以減輕對話偏離不必要的領域），然后推出了更復雜的提示隔離。他們開始以模型無法輕易泄露的方式對系統提示進行編碼（一些報告表明，他們使用隱藏的標記或詞匯表外的嵌入來作為內部指令）。他們還不斷擴展停用短語列表，并使用越獄嘗試的對抗樣本重新訓練模型。在幾個月內，提示注入的成功率顯著下降。嘗試相同“忽略先前指令”攻擊的用戶發現它們無效。微軟還增加了一個安全系統，如果用戶輸入中出現某些模式（例如“忽略所有規則”），AI 就會拒絕或給出平淡的回答。結果：到 2023 年中期，Bing Chat 的越獄難度明顯增加，恢復了部分公眾信心。微軟公開贊揚了他們的 AI 安全研究人員“紅隊”以及他們從真實世界嘗試中不斷學習的結果。有效的方法：真實世界攻擊數據和模型更新之間的快速反饋循環；分層方法（通過更短的聊天限制暴露并改進及時處理）；以及對用戶透明地說明限制（“對不起，我無法繼續該請求”成為一種常見的安全完成方式）。

案例研究 3：醫療 AI (Syntegra) — 訓練數據的差異化隱私。醫療 AI 初創公司 Syntegra 構建了生成模型來創建合成的患者數據。其核心風險在于，該模型可能會記憶并重復真實的患者記錄 (PHI)，從而違反《健康保險流通與責任法案》(HIPAA)。他們在模型訓練過程中實施了差異化隱私——注入噪聲，使模型無法回憶起超過概率閾值的細節。他們還制定了一項策略：任何試圖獲取完整患者記錄或身份信息的提示都會觸發自動拒絕。在一項測試中，一位內部團隊成員試圖讓模型輸出特定的罕見診斷記錄（他們知道該記錄包含在訓練集中）。該模型生成了逼真的記錄，但關鍵之處在于修改了某些標識符和細節，這表明差異化隱私正在發揮作用（它生成的是復合回憶，而非逐字回憶）。這讓他們有信心在研究環境中部署數據增強功能。他們發表了一篇論文，表明他們的模型在5元語法（五詞序列）之外與訓練數據的精確匹配為零，而且隱私風險低于監管閾值。有效的方法是：將隱私納入模型設計之中，而不是事后才考慮；此外，對個人數據的輸出進行明確的檢查（例如，對社保號或患者姓名進行正則表達式檢查——他們使用已知的患者姓名列表來掃描輸出，除了誤報外，沒有發現其他異常）。該案例表明，技術控制（差異隱私）與領域特定過濾器（醫療PHI檢測）相結合，即使在處理敏感數據時也能確保GenAI的安全使用。

案例研究 4：谷歌 Vertex AI 在 Waymo 的應用——保障機器學習供應鏈安全。Waymo（Alphabet 旗下自動駕駛部門）使用生成模型來模擬場景描述。他們依賴谷歌的 Vertex AI 平臺來部署這些模型。一個顯著的挑戰是模型來源：確保他們使用的任何開源模型（例如用于場景創建的文本生成模型）都經過審查且沒有后門。Waymo/谷歌通過使用“模型注冊表”解決了這個問題，每個模型（即使是第三方預訓練的模型）都會被掃描——他們會對任何新模型運行一系列測試，包括檢查隱藏的觸發器。例如，他們發現一個開放模型在輸入一個看似無關的觸發詞（很可能是研究水?。r會輸出一個特定的短語（“XYZZY”）。他們選擇放棄該模型，轉而采用另一個模型。谷歌隨后在 Vertex AI 中構建了一些功能，允許企業客戶查看模型沿襲（哪個數據集、哪個來源），并將自定義安全內核應用于模型執行（例如谷歌的 gVisor 沙盒）。實際上，Waymo 可以安全地將 GenAI 模型集成到他們的流程中，并高度保證它不會危及更大系統（在他們的案例中，可能是實際的駕駛邏輯）的安全。他們在一次人工智能會議上報告稱，在 18 個月的運行中，他們所有投入生產的生成模型均未引發任何安全問題，這部分歸功于嚴格的供應鏈控制。有效的方法是：像對待代碼一樣對待模型——驗證簽名/哈希值，測試異常行為，并使用支持隔離執行（模型與其他組件之間零信任）的基礎設施。

這些案例研究突出了幾個主題：持續測試和迭代（微軟）、內置的預防性隱私/安全技術（Syntegra 的差異隱私）、引導用戶行為的政策和控制（摩根大通的禁令和內部工具）以及供應鏈警戒（Waymo/谷歌）。遵循這些“有效”實踐的組織通常能夠避免重大事故，甚至將安全轉化為競爭優勢（能夠宣稱“我們擁有高度安全的 AI”成為一個賣點）。相反，那些沒有這樣做的組織（也有一些臭名昭著的案例，例如一個 AI 寫作助手通過共享內存泄露了其他公司的數據——未能隔離租戶）則值得警示。

五、30–60–90 天行動計劃

第 0-30 天（立即）：鞏固基礎

• 開展 GenAI 威脅建模研討會（負責人：安全架構師，參與人員：AI 開發主管、運維人員、法務人員）：在前兩周，召集利益相關者，使用 STRIDE 或類似工具繪制潛在威脅圖。識別資產（敏感數據、模型訪問）、入口點（API、用戶輸入）和威脅行為者。輸出威脅模型文檔草稿。成果：GenAI 威脅模型圖以及用例的十大風險列表。
• 實施速效防護措施（責任人：工程經理）：在第 2-3 周，啟用基本的輸入/輸出過濾功能（例如，使用云內容審核 API 或簡單的正則表達式規則）。將提示和響應的最大令牌限制設置為保守的默認值。如果使用外部 API，請確保“不使用數據進行訓練”設置為開啟狀態（例如，OpenAI API 就有此功能）。工件：在 API 設置中配置更改，并設置好過濾代碼。
• 訪問控制審計（所有者：CISO 或其代表）：審核哪些人/哪些內容可以訪問 GenAI 系統。30 天內，如果尚未集成單點登錄 (SSO)，請將 GenAI 應用與單點登錄 (SSO) 集成，并鎖定 API 密鑰。在提示中禁用所有硬編碼憑證。強制執行最小權限：例如，如果只有一個服務帳戶可以調用模型 API，請確保其他帳戶無法調用該網絡或令牌。工件：訪問策略文檔已更新，IAM 角色已調整。
• 制定 AI 安全 RACI 和事件響應計劃（負責人：CISO 團隊，參與人員：AI 產品經理、通訊員）：確定誰是“批準新模型”或“響應 AI 安全事件”等決策的負責人、問責人員、咨詢人員和知情人員。到第 30 天，還要制定一份一頁紙的 GenAI 事件響應計劃——例如，如果檢測到快速注入或發生泄漏，應采取的步驟（例如，“禁用 AI 服務，通知信息安全主管，保存日志，并在 24 小時內與受影響的利益相關者溝通”）。工件：用于 GenAI 風險決策的 RACI 矩陣；事件行動手冊。

第 31-60 天（期中）：強化和測試

• 紅隊模擬（負責人：安全測試團隊）：在 45 天內進行一次正式的紅隊演習。使用內部安全人員或聘請外部專家模擬針對 GenAI 系統的攻擊。他們應該嘗試快速注入、數據泄露、插件濫用等攻擊方式。記錄有效的方法和發現的漏洞。成果：紅隊報告，其中包含發現結果和補救措施。
• 實施高級控制（所有者：工程部門）：基于早期經驗，部署更強大的解決方案。如果提示注入存在風險，請考慮使用開源庫（例如微軟的 PromptGuard）或用于清理提示的商業工具。如果使用工具/代理，請在第 60 天之前實施工具代理模式：禁止模型到互聯網的直接調用。建議部署一個“影子模型”來評估輸出（一種技術：將輸出通過第二個模型運行，檢查其是否符合策略，以此作為安全網）。成果：更新的架構圖，顯示新的控制組件（例如，API 前端的 WAF、用于任何代碼執行的安全沙盒）。
• 演練和培訓（負責人：SecOps 負責人）：在第 50 天左右，針對 GenAI 漏洞場景進行一次事件響應演練。例如：“如果模型開始從訓練中返回敏感數據怎么辦？立即行動！” 演練通知法務部門、提取日志等步驟。找出漏洞（例如日志不易搜索，然后改進）。同時，對開發和運維人員進行安全實踐培訓：為大語言模型 (LLM) 提供 OWASP Top 10 指南。此外，還要確保業務連續性：如果 AI 服務因安全原因關閉，我們是否有后備方案（例如恢復到非 AI 流程）？做好規劃。成果：演練后行動報告；更新后的 SOP；團隊培訓出席名單。
• 模型和數據治理檢查點（所有者：數據治理負責人）：到第 60 天，審查輸入模型的數據（在提示或微調中），并確保合規。如果未完成，則對數據進行分類，并確定哪些數據不能在 GenAI 中使用。此外，創建一個流程：任何新模型或重大提示變更上線前，都需要安全審查簽字確認。在開發工作流程中將其正式化（可以是部署流水線中的檢查清單）。工件：GenAI 數據使用策略（例如，“提示中不包含 PHI”；“僅使用來自已批準注冊表的模型”）；以及發布流程中的門控檢查清單（可以集成到 CI/CD 流水線中）。

第 61-90 天（長期強化和治理）：

• 外部審計/審查（所有者：CISO）：在此階段，如果資源允許，可以聘請外部公司根據框架對 GenAI 系統進行審計（例如云提供商的安全審查或專業的 AI 安全公司）。他們可能會評估配置、查找未知漏洞，并確保您的控制措施符合標準（例如 NIST AI RMF 等）。工件：外部審計報告以及針對任何發現的緩解計劃。
• 優化指標和監控（負責人：具備 SecOps 技能的 AI 產品經理）：到第 90 天，對指標進行微調。您可能發現初始閾值過于敏感或不夠敏感。調整警報閾值（例如，可以將違規率穩定在 0.5% 左右，如果違規率超過 1%，則設置警報）。實施一個儀表板，由安全和產品團隊每周共同審查。還可以考慮針對某些警報實施自動響應：例如，如果某個 IP 觸發 5 次快速注入失敗，則通過 WAF 自動阻止該 IP 24 小時。工件：GenAI 的實時安全儀表板；自動響應與手動響應的運行手冊。
• 持續改進與治理委員會（負責人：首席風險官/AI治理委員會）：大約在第90天，與AI治理小組（如果存在，或者創建一個由IT、風險、法務和業務負責人組成的小組）召開一次審查會議。匯報GenAI的安全現狀：已完成的工作、剩余的風險以及任何事故。以此為基礎更新政策和投資需求（或許您可以決定資助內部“安全LM”的開發，或購買更好的監控工具）。確保GenAI安全成為企業風險登記冊的一部分，并每季度更新。成果：治理會議紀要，其中包含諸如“所有GenAI用例必須接受安全評估——在第四季度前實現100%合規”或“為季度紅隊演練和員工培訓分配預算”等決策。

關鍵決策的 RACI：例如，“批準使用新的 GenAI 工具（例如，新的插件）”

——負責人：AI 產品經理，問責人：CISO（或代表），咨詢人：法務、隱私官，知情人：開發團隊。另一個：“緊急關閉 GenAI 服務”——負責人：SecOps 主管，問責人：CIO，咨詢人：AI 開發主管及法務（負責客戶影響），知情人：支持團隊、通訊。提前擁有此 RACI 可確保在危機時刻，每個人都知道誰在發號施令。

通過遵循這個“30-60-90”計劃，組織應該能看到切實的改進：到90天，GenAI應用程序將不再是一個“黑匣子”，而是一個受監控、可控制且責任明確的系統。組織將從臨時的安全措施轉變為可重復的流程——隨著GenAI應用的擴展，這一點至關重要。