概觀
隨著越來越多的組織採用生成式 AI 技術，理解相關的安全風險變得至關重要。身分和存取管理、資料保護、隱私和合規、應用程式安全和威脅建模等核心安全領域對於生成式 AI 工作負載仍然至關重要，就像對於任何其他工作負載一樣。但除了強調長期安全實務之外，了解生成式 AI 工作負載帶來的獨特風險和額外的安全考量非常重要。
生成式 AI 安全範疇界定矩陣是一個全面的架構，旨在協助組織在整個 AI 生命週期中評估和實作安全控制。它將安全考量分為特定類別，從而可採用有針對性的方法來保護 AI 應用程式的安全。
生成式 AI 安全範疇界定矩陣
用於分類使用案例的心智模型
確定您的範疇
第一步是確定您的使用案例適用的範疇。範疇編號為 1-5，代表貴組織對 AI 模型及其關聯資料擁有的最低擁有權至最高擁有權。
貴組織免費或付費使用公有第三方生成式 AI 服務。這些通常是「消費級」應用程式，可能並非專為企業或商業用途而設計。在此範疇內，您不擁有或查看訓練資料或模型，也無法進行修改或增強。您根據供應商的服務條款調用 API 或直接使用應用程式。
範例：員工透過公開網站與生成式 AI 聊天應用程式進行互動，以為即將推出的行銷活動產生想法。
貴組織使用內嵌生成式 AI 功能的第三方企業應用程式，並且在貴組織與供應商之間建立商業關係。範疇 2 應用程式通常具有針對企業客戶的條款和條件，旨在提供額外的保護。
範例：您使用具有內嵌生成式 AI 功能的第三方企業排程應用程式，協助草擬會議議程。
貴組織使用現有的第三方生成式 AI 基礎模型來建置自己的應用程式。您可以透過應用程式介面 (API) 直接將其與工作負載整合。
範例：建置一個客戶支援聊天機器人，該機器人使用檢索增強生成 (RAG) 來整合您自己的資料，並透過 Amazon Bedrock API 利用 Anthropic Claude 基礎模型。
貴組織透過使用特定於您業務的資料進行微調來完善現有的第三方生成式 AI 基礎模型，產生專門針對工作負載的新增強型模型。
範例：您需要具有深入醫療領域專業知識的模型，以在電子健康記錄 (EHR) 系統中彙總患者記錄。微調可用於調整系統輸出，使其符合醫生期望的風格，並針對領域專業術語對系統進行訓練。
貴組織使用您擁有或取得的資料，從頭開始建置和訓練生成式 AI 模型。您擁有模型的各個方面。
範例：貴組織旨在建立用於產生高品質影片內容的模型，例如建置超慢動作影片插幀的自訂解決方案。透過在專業影片資料上訓練模型，您可以將此進階影片創作技術授權給媒體和娛樂產業的公司。
優先考慮事項
您的工作負載已確定範疇，現在您需要讓您的業務快速且安全地發展。在生成式 AI 安全範疇界定矩陣中，我們識別涵蓋不同類型之生成式 AI 解決方案的五個安全領域。
- 治理與合規 – 為業務提供支援並同時最大限度地降低風險所需的政策、程序和報告。
- 法律與隱私 – 使用或建立生成式 AI 解決方案的特定法規、法律和隱私權要求。
- 風險管理 – 識別生成式 AI 解決方案的潛在威脅和建議的緩解措施。
- 控制 – 用於降低風險的安全控制項的實作。
- 恢復能力 – 如何設計生成式 AI 解決方案，以維持可用性並符合業務 SLA。
讓我們探索一些您應優先考慮的機會範例。
跨範疇安全性考量
治理與合規
管理範疇 1 與範疇 2 時，遵守服務條款、授權合約及資料主權要求至關重要。對於範疇 1 的應用程式，應優先使用公開、非專屬資料，因為服務供應商可能會利用提交的資料最佳化其模型或服務。範疇 2 的應用程式開發需包含完善的控制措施、合約保障及退出選項，以保護組織的專有與敏感資料，確保其不被用於模型訓練或改進。這類應用程式通常是為企業使用案例量身打造。
若任務具有組織或客戶獨特性 (例如彙總專屬/敏感業務資料、生成獨特見解、自動化內部流程)，則可能需要從範疇 3 至範疇 5 打造自訂應用程式。這些範疇讓您能將資料用於訓練、微調或作為模型輸出。例如，即使您未將資料微調或訓練至範疇 3 的大型語言模型 (LLM)，仍可使用檢索增強生成 (RAG)、知識庫與代理程式來優化模型回應與情境化操作，無需微調模型。
在範疇 4 與範疇 5 中，使用領域專屬資料訓練模型，並避免使用個人識別資訊 (PII) 等敏感資料。確保最終模型的分類等級與訓練過程中所用資料的最高敏感度一致。僅有獲得該分類等級授權的使用者，方可執行模型推論。對於 PII 或頻繁變動的交易資料，建議在推論階段透過檢索增強生成 (RAG) 或基於代理程式的工作流程重新導入，而非直接整合至模型本身。
法律與隱私
從法律層面而言，非常有必要了解服務供應商的終端使用者授權合約 (EULA)、服務條款 (TOS)，以及在範疇 1 至範疇 4 中使用其服務所需的其他合約協議。對於範疇 5，法律團隊應針對您模型的外部使用提供專屬的合約服務條款。此外，對於範疇 3 與範疇 4，需同時確認服務供應商的服務使用法律條款，以及模型供應商針對其模型在該服務中使用所訂之法律條款。
若您的業務適用歐盟的一般資料保護規範 (GDPR) 中的「刪除權」或「被遺忘權」要求，亦需考量相關隱私議題。若使用日後可能需應要求刪除的資料來訓練或微調模型，需謹慎考量將會帶來哪些影響。從模型中移除資料唯一完全有效的方法，就是從訓練集中刪除該資料，並訓練新版本的模型。若需刪除的資料僅占總訓練資料的一小部分，此方法並不切實際；且根據模型規模，其成本可能極為高昂。
風險管理
儘管 AI 驅動的應用程式與傳統應用程式相似，但其與大型語言模型 (LLM) 的互動特性，要求額外的警覺性與特定防護措施。至關重要的是識別生成式 AI 工作負載相關風險並展開緩解行動。
風險識別通常可透過風險評估與威脅建模實現。對於範疇 1 與範疇 2，需評估第三方供應商帶來的風險，並了解其風險緩解策略。身為服務使用者，您亦需明確自身的風險管理責任。
對於範疇 3、4 與 5，需實施同時涵蓋 AI 安全與資料安全風險的威脅建模，並重點關注提示注入等 LLM 專屬威脅。這涉及構造可操縱 LLM 回應的輸入內容，可能導致資料外洩或未經授權的存取。NIST、MITRE 和 OWASP 最近發布的指南均指出，提示注入是主要威脅，可與 SQL 注入攻擊等傳統注入攻擊相提並論。在資料傳送至 LLM 前，可透過套用細粒度授權與資料篩選，並使用 Bedrock 防護機制提供額外保護，以緩解此風險。
生成式 AI 中的新興威脅需要調整傳統的網路安全措施，並與開發團隊密切協作，以有效地建立威脅模型並建立量身打造的最佳實務。
控管
實施完善的控制措施對於落實合規、政策與安全要求至關重要，進而可緩解生成式 AI 工作負載相關風險。其中一項核心考量是管理模型的身分識別與存取權限。 不同於傳統資料庫具備細粒度安全控制，基礎模型對於其內部儲存的資料或推論階段提供的資料，並無存取控制概念。因此，在資料做為上下文新增至推論請求前，必須對其實施最低權限存取控制。
若要實現此目標，可透過 Amazon Bedrock 等端點與模型互動的應用程式層來達成。這些應用程式層應整合 Amazon Cognito 或 AWS IAM Identity Center 等身分解決方案，以對使用者進行認證與授權。透過依據角色、屬性與使用者群體來自訂存取權限，可限制特定操作，並協助確保敏感資料得到保護。
此外，隨著 AI 工作負載的演進，需持續評估並更新控制措施，以適應新威脅與資料敏感度變化。整合檢索增強生成 (RAG) 等先進技術，可在不影響模型完整性的前提下提供即時資料。這些策略搭配持續的威脅建模，有助於為生成式 AI 應用程式維持安全且合規的環境。
恢復能力
對於範疇 3、4 與 5，需設定適當的逾時時間，以應對複雜提示與完成內容的處理需求。您可能還需關注提示輸入長度是否符合模型定義的字元限制。此外，需考量彈性設計的現有最佳實務 (如 退避與重試、 斷路器模式)，以達成預期使用者體驗。使用向量資料庫時，建議採用高可用性組態和災難復原計畫，以便抵禦各類故障模式。
除了可能為高度關鍵性工作負載預留或預配置運算資源外，推論與訓練模型管道的執行個體靈活性，亦是重要的架構考量因素。使用 Amazon Bedrock 或 SageMaker 等受管服務時，若實施多區域部署策略，需確認 AWS 區域的可用性與功能一致性。同樣地，若要為範疇 4 與 5 的工作負載提供多區域支援，需考慮到微調或訓練資料在各區域的可用性。若在範疇 5 中使用 SageMaker 訓練模型，需使用 檢查點儲存訓練進度。如此一來，必要時可從最後儲存的檢查點恢復訓練。
請務必檢閱並實施既有應用程式恢復能力最佳實務，這些實務已載於 AWS Resilience Hub，以及「架構良好的結構」的 可靠性支柱與 卓越營運支柱中。