Azure 工作負載中負責任的 AI

負責任 AI 在工作負載設計中的目標是要協助確保 AI 演算法的使用 公平、透明，以及 包容性。 Microsoft Azure Well-Architected Framework 安全性準則相互關聯，並著重於 機密性 和 完整性。 必須備妥安全措施，才能維護用戶隱私權、保護數據，以及保護設計的完整性。 設計不應該針對非預期用途誤用。

在 AI 工作負載中，模型通常會使用不透明的邏輯來做出決策。 用戶應該信任系統的功能，並確信模型會負責任地做出這些決策。 必須防止操縱、內容毒性、IP 侵權和捏造回應等不可接受的行為。

請考慮媒體娛樂公司想要使用 AI 模型提供建議的使用案例。 如果公司未實施負責任的人工智慧和適當的安全性協定，惡意行為者可能會取得模型的控制權。 模型可能會建議造成傷害的內容。 對於組織而言，此行為可能會導致品牌損毀、不安全的環境和法律問題。 因此，在整個系統的生命週期中保持適當的警惕是不可或缺的且不可談判的。

您應該優先考慮安全性和工作負載管理，並在做出設計決策時記住以人為本的結果。 熟悉 負責任 AI 的Microsoft架構，並確保您在設計中測量及實作架構的原則。 下圖顯示架構的核心概念。

本文提供負責任決策、驗證使用者輸入，以及協助確保安全用戶體驗的建議。 它也提供數據安全性的指引，以協助保護用戶數據。

建議

下表摘要說明本文中的建議。

開發負責任 AI 的原則

記錄人工智慧的負責任使用方式。 明確陳述您在生命週期的每個階段套用的原則，讓工作負載小組瞭解其責任。 Microsoft 負責任 AI 的標準提供指導方針，但您必須定義這些指導方針在您的情境中具體意義為何。

例如，政策應包含支持使用者數據透明度和同意設定的機制的檢查清單項目。 在理想情況下，這些機制應該允許使用者選擇不包含其數據。 數據管線、分析、模型定型和其他階段都必須遵守該選擇。 另一個範例是處理 RTBF 的程式。 請洽詢貴組織的道德部門和法律小組，以做出明智的決策。

為數據使用和演演算法決策建立透明原則，以協助用戶瞭解並信任此程式。 記錄這些決定，以維護潛在的未來訴訟的明確歷程記錄。

負責任的 AI 實作包含三個主要角色：研究小組、原則小組和工程小組。 這些小組之間的共同作業應可運作。 如果您的組織有現有的小組，請使用其工作。 否則，請自行建立這些做法。

每個小組都應該有自己的責任。 例如：

• 研究小組會藉由諮詢組織指導方針、業界標準、法律、法規和已知的紅隊策略，進行風險探索。

• 政策團隊會開發專門針對工作負載的政策。 它們納入來自母公司和政府法規的指導方針。

• 工程小組會將原則 實作至其流程和交付專案。 小組會驗證並測試是否遵守。

每個小組都會正式化其指導方針，但 工作負載小組必須負責自己的記載做法。 小組應該清楚記錄任何額外的步驟或刻意偏差，以確保對於允許的內容沒有任何模棱兩可之處。 小組也應該對解決方案中任何潛在缺點或非預期的結果透明。

針對負責任 AI 的政策強制實施治理

設計您的工作負載以 符合組織和法規治理。 例如，如果透明度是組織需求，請判斷其如何套用至您的工作負載。 識別設計、生命週期、程序代碼或其他元件中的區域，其中您應該引進透明度功能以符合該標準。

瞭解必要的治理、責任、審查委員會和報告授權。 請確定您的治理委員會 核准並批准工作負載設計，以避免重新設計並減輕安全或隱私問題。 您可能需要經過多層核准。 下圖概述組織中的一般治理結構。

如需組織原則和核准者的詳細資訊，請參閱 定義負責任的 AI 策略。

確保用戶體驗安全

用戶體驗應以產業指導方針為基礎。 使用 Microsoft Human-AI 體驗設計連結庫，其中包含原則並提供實作指導方針。 它也提供來自Microsoft產品和其他產業來源的範例。

用戶互動的生命週期都有工作負載責任。 他們從使用者的意圖開始使用系統，並在系統錯誤所造成的任何中斷期間繼續進行。 請考慮下列做法：

• 建置透明度。 讓使用者知道系統如何產生其查詢的回應。

  包含模型參考預測之數據源的連結。 這種做法會藉由顯示資訊的來源來增加使用者信心。 數據設計應該將這些來源包含在元數據中。 例如，當擷取增強型應用程式中的協調器執行搜尋時，它會擷取 20 個檔區塊，並將前 10 個區塊以內容的形式傳送至模型。 前10個區塊屬於三個不同的檔。 UI 接著可以在顯示模型的回應時參考這三個源檔。 此透明度會增加使用者信任。

  當您使用代理時，透明度會變得更重要，其在前端介面和後端系統之間充當中介。 例如，在票證系統中，協調流程程式代碼會解譯使用者意圖，並讓應用程式程序設計介面 （API） 呼叫代理程式以擷取必要的資訊。 公開這些互動有助於讓使用者知道系統的動作。

  針對包含多個代理程式的自動化工作流程，請建立記錄每個步驟的記錄檔。 記錄檔可協助您識別並更正錯誤。 他們也會為使用者提供決策的說明，其可讓透明度運作。

  警告

  當您實作透明度建議時，請避免讓使用者被過多資訊淹沒。 使用最少干擾性 UI 方法，採取漸進式方法。

  例如，顯示顯示模型信賴分數的工具提示。 您可以納入連結，例如源文檔的連結，用戶可以選取以取得詳細數據。 這個使用者起始的方法會讓UI保持不中斷，並讓使用者只有在選擇時才能搜尋更多資訊。

• 收集意見反應。 實作意見反應機制。

  避免在每次響應之後，對大量問卷的使用者造成壓倒性。 請改用快速且簡單的意見反應機制，例如按讚或踩，或針對答案的特定層面設置 1 到 5 的評分系統。 這些方法有助於改善系統一段時間，並允許細微的意見反應，而不會受到干擾。 請留意意見反應中的潛在公平性問題，因為使用者響應背後可能有次要原因。

  實作意見反應機制會影響架構，因為需要數據記憶體。 將意見反應視為用戶數據，並根據需要套用隱私控制層級。

  除了回應意見反應之外，還收集用戶體驗有效性的意見反應。 透過系統的監控堆疊收集互動指標。

讓內容安全措施運作

使用自定義解決方案程式代碼、適當的工具和有效的安全性做法，將內容安全性整合到 AI 生命週期的每個階段。 請考慮下列策略：

• 匿名數據。 當數據從擷取移至定型或評估時，請實作一路上的檢查，以將個人資訊外泄的風險降到最低，並避免原始用戶數據暴露。

• 審核內容。 使用即時評估要求和回應的內容安全性 API。 請確定這些 API 可連線。

• 識別並減輕威脅。 將已知的安全性做法套用至您的 AI 案例。 例如，進行威脅模型化，然後記錄威脅及其減輕方式。 紅隊演習等一般安全性做法適用於 AI 工作負載。 紅色小組可以測試模型是否可以操作以產生有害內容。 這些活動應該整合到 AI 作業中。

  如需詳細資訊，請參閱 規劃大型語言模型的紅隊演練及其應用。

• 使用正確的計量。 使用可有效測量模型行為的計量。 計量會根據 AI 模型的類型而有所不同。 在某些情況下，產生模型測量可能不適用於回歸模型。 例如，模型會預測預期壽命，而結果會影響保險費率。 此模型中的公平性問題可能會導致與公平相關的傷害。 此問題源於核心計量測試中的偏差，因為公平性和正確性計量通常相互關聯。 改善精確度，以協助減少與公平相關的傷害。

• 添加適當的儀器。 AI 模型結果必須可解釋。 您需要說明和追蹤推斷的方式，包括訓練數據、計算得出的特徵和基礎數據。 在歧視 AI 中，您可以逐步證明決策的合理性。 不過，對於產生模型，說明結果可能會相當複雜。 記錄決策程式 ，以解決潛在的法律影響並提供透明度。

  您應該在整個 AI 生命週期中實作此可解釋性層面。 數據清理、譜系、選取準則和處理是應追蹤決策的關鍵階段。

工具

整合內容安全性和資料可追蹤性的工具，例如 Microsoft Purview。 您可以從測試呼叫 Azure AI 內容安全性 API，以利進行內容安全性測試。

Azure AI Foundry 提供評估模型行為的計量。 如需詳細資訊，請參閱 產生式 AI 的評估和監視計量。

如需定型模型，請參閱 Azure Machine Learning 所提供的 計量。

檢查傳入和傳出數據

提示插入式攻擊，例如越獄，是 AI 工作負載的共同考慮。 在此情況下，某些使用者可能會嘗試針對非預期用途誤用模型。 為了協助確保安全，檢查數據以防止攻擊，並篩選出不適當的內容。 將此分析套用至使用者的輸入及系統的回應，以協助確保傳入及傳出流程中的內容管理徹底進行。

在某些情況下，您必須進行多個模型調用，例如透過 Azure OpenAI 服務來提供單一用戶端要求。 在這些案例中，將內容安全性檢查套用至每個叫用可能成本高昂且不必要。 請考慮 將工作集中在架構中，同時將安全性保持為伺服器端責任。 假設架構在模型推斷端點前面有閘道，以卸除特定的後端功能。 您可以設計該閘道來處理內容安全性檢查，以應對後端可能不支援的要求和回應。 雖然閘道是常見的解決方案，但協調流程層可以在更簡單的架構中有效地處理這些工作。 在這兩種情況下，您可以視需要選擇性地套用這些檢查，以優化效能和成本。

檢查應該是多模式，並涵蓋各種格式。 當您使用多模式輸入，例如影像時，請務必針對可能有害或暴力的隱藏訊息進行分析。 這些訊息可能不會立即顯示，因此需要仔細檢查。 基於此目的，請使用內容安全性 API 之類的工具。

為了協助強制執行隱私權和數據安全策略，請檢查用戶數據和地面數據，以符合隱私權法規。 請確定數據在流經系統時經過清理或篩選。 例如，來自先前客戶支援交談的數據可作為基礎數據。 在重複使用之前，應該先清理此數據。

適當地處理用戶數據

負責任的做法牽涉到仔細處理用戶數據管理。 此管理包括知道何時使用數據，以及何時避免依賴用戶數據。

• 練習推斷而不共享用戶數據。 若要安全地與其他組織共用用戶數據以取得深入解析， 請使用清除機制模型。 在此案例中，組織會將數據提供給受信任的合作夥伴，以使用匯總的數據來定型模型。 然後，所有機構都可以使用此模型並共用深入解析，而不需要公開個別數據集。 目標是使用模型的推斷功能，而不需共用詳細的定型數據。

• 促進多樣性和包容性。 當需要使用用戶數據時，請運用多樣化的數據範圍，包括代表性不足的內容類型和創作者，以減少與公平性相關的損害。 實作可鼓勵使用者探索新內容和不同內容的功能。 持續監視使用量並調整建議，以避免過度代表任何單一內容類型。

• 尊重 RTBF。 盡可能避免使用用戶數據。 透過準備必要的措施，確保用戶數據能夠被妥善刪除，以協助確保符合 RTBF 要求。

  為了協助確保合規性，可能會要求從系統移除用戶數據。 對於較小的模型，您可以使用排除個人信息的數據來重新定型模型，以移除用戶數據。 對於較大型的模型，其可包含數個較小的獨立定型模型，此程序比較複雜，而且成本與精力相當重要。 尋求處理這些情況的法律和道德指引，並務必在負責任 AI 的原則中包含指導方針。

• 負責任地保留數據。 如果無法刪除數據， 請取得明確的使用者同意數據收集 ，並提供明確的隱私策略。 只有在絕對必要時，才收集並保留數據。 設置措施，以便在數據不再需要時積極移除。 例如，儘快清除聊天記錄，並在保留前匿名敏感數據。 針對靜態數據使用進階加密方法。

• 支援可解釋性。 追蹤系統中的決策，以支援可解釋性需求。 開發建議演算法運作方式的清楚說明。 為使用者提供為何建議特定內容的深入解析。 目標是藉由詳細說明 AI 工作負載及其結果的制定方式、使用的數據，以及模型定型方式，以確保 AI 工作負載及其結果透明且合理。

• 加密用戶數據。 輸入數據必須在使用者輸入數據的那一刻起，在數據處理管線的每個階段加密。 這些階段包括：數據在不同點之間的傳輸、儲存的數據，以及在必要時被推斷的數據。 平衡安全性和功能，並旨在 在整個生命週期保持數據私用。

• 提供健全的存取控制。 數種類型的身分識別可能會存取用戶數據。 針對控制平面和數據平面實作角色型訪問控制，使其涵蓋使用者和系統對系統通訊。

  維護適當的使用者分割以保護隱私權。 例如，Microsoft 365 Copilot 可以根據使用者的特定文件和電子郵件來搜尋並提供答案，同時確保只存取與該使用者相關的內容。

• 減少表面積。 Well-Architected Framework 安全性支柱的基本策略是將受攻擊面和強化資源降到最低。 您應該透過嚴格控制 API 端點、只公開基本數據，以及避免回應中多餘的資訊，將此策略套用至標準端點安全性做法。 平衡彈性與控制之間的設計選擇。

  請確定沒有任何匿名端點。 一般而言，請避免給予使用者比必要更多的控制權。 在大部分情況下，使用者不需要調整超參數，除非是在實驗環境中。 對於一般使用案例，例如與虛擬代理程式互動，用戶應該只控制基本層面，藉由限制不必要的控制來協助確保安全性。

如需詳細資訊，請參閱 azure 上 AI 工作負載的應用程式設計。

下一步