Azure ワークロードでの責任ある AI

ワークロード設計における責任ある AI の目標は、AI アルゴリズムの使用における公平性、透明性、包括性を保証することです。 Microsoft Azure Well-Architected Framework のセキュリティ原則は相互に関連しており、機密性 と 整合性に焦点を当てています。 ユーザーのプライバシーを維持し、データを保護し、設計の整合性を保護するために、セキュリティ対策を講じる必要があります。 意図しない目的で設計を誤用しないでください。

AI ワークロードでは、多くの場合、モデルは不透明なロジックを使用して意思決定を行います。 ユーザーはシステムの機能を信頼し、モデルがこれらの決定を責任を持って行う自信を持つ必要があります。 操作、コンテンツ毒性、IP 侵害、製造された応答など、許容できない動作を防止する必要があります。

メディア エンターテインメント企業が AI モデルを使用して推奨事項を提供するユース ケースを考えてみましょう。 会社が責任ある AI と適切なセキュリティ プロトコルを実装していない場合、不適切なアクターがモデルを制御する可能性があります。 モデルでは、損害を引き起こすコンテンツが推奨される場合があります。 組織にとって、この動作により、ブランドの損害、安全でない環境、法的な問題が発生する可能性があります。 したがって、システムのライフサイクル全体を通して適切な警戒を維持することは不可欠であり、ネゴシエートできません。

設計上の決定を行うときは、セキュリティとワークロードの管理に優先順位を付け、人間の成果を念頭に置く必要があります。 責任ある AI の Microsoft フレームワーク 理解し、フレームワークの原則を設計で測定して実装していることを確認します。 次の図は、フレームワークの主要な概念を示しています。

この記事では、責任ある意思決定、ユーザー入力の検証、および安全なユーザー エクスペリエンスの確保に関する推奨事項を示します。 また、ユーザー データの保護に役立つデータ セキュリティに関するガイダンスも提供します。

推奨事項

次の表は、この記事の推奨事項をまとめたものです。

責任ある AI のポリシーを開発する

責任ある AI の使用状況に対するアプローチを文書化します。 ワークロード チームが責任を理解できるように、ライフサイクルの各段階で適用するポリシーを明示的に指定します。 責任ある AI に関する Microsoft の標準ではガイドラインが提供されますが、これらのガイドラインがコンテキストに対して具体的に何を意味するのかを定義する必要があります。

たとえば、ポリシーには、ユーザー データの透明性と同意の構成をサポートするメカニズムのチェックリスト項目を含める必要があります。 これらのメカニズムを使用すると、ユーザーはデータの包含をオプトアウトできるのが理想的です。 データ パイプライン、分析、モデル トレーニング、その他のステージはすべて、その選択を尊重する必要があります。 もう 1 つの例として、RTBF を処理するためのプロシージャがあります。 組織の倫理部門と法務チームに相談して、情報に基づいた意思決定を行います。

ユーザーがプロセスを理解して信頼できるように、データ使用とアルゴリズムの意思決定のための透過的なポリシーを作成します。 これらの決定を文書化して、将来の訴訟の可能性について明確な履歴を保持します。

責任ある AI の実装には、研究チーム、ポリシー チーム、エンジニアリング チームの 3 つの重要な役割が含まれます。 これらのチーム間のコラボレーションを運用化する必要があります。 組織に既存のチームがある場合は、そのチームの成果を活用します。 それ以外の場合は、これらのプラクティスを自分で確立します。

各チームには独自の責任が必要です。 例えば：

• 研究チームは、組織のガイドライン、業界標準、法律、規制、既知のレッドチーム戦術をコンサルティングすることで、リスク検出 を実施します。

• ポリシー チームは、ワークロードに固有のポリシーを開発します。 親組織と政府の規制からのガイドラインが組み込まれています。

• エンジニアリング チームは、プロセスと成果物に ポリシーを実装します。 チームは、準拠を検証してテストします。

各チームはガイドラインを正式に作成しますが、 workload チームは、文書化された独自のプラクティスに対して責任を負う必要があります。 チームは、追加の手順や意図的な逸脱を明確に文書化して、許可される内容にあいまいさがないようにする必要があります。 また、チームは、ソリューションの潜在的な欠点や予期しない結果についても透過的にする必要があります。

責任ある AI のポリシーにガバナンスを適用する

組織と規制のガバナンスと に合わせてワークロードを設計。 たとえば、透明性が組織の要件である場合は、ワークロードへの適用方法を決定します。 設計、ライフサイクル、コード、またはその標準を満たすために透明性機能を導入する必要があるその他のコンポーネントの領域を特定します。

必要なガバナンス、アカウンタビリティ、レビュー ボード、およびレポートの義務について理解します。 ガバナンス協議会 がワークロード設計 を承認してサインオフすることで、再設計を回避し、安全性やプライバシーに関する懸念を軽減してください。 複数の承認レイヤーを通過することが必要な場合があります。 次の図は、組織内の一般的なガバナンス構造の概要を示しています。

組織のポリシーと承認者の詳細については、「責任ある AI 戦略を定義する」を参照してください。

ユーザー エクスペリエンスを安全にする

ユーザー エクスペリエンスは、業界のガイドラインに基づく必要があります。 Microsoft Human-AI エクスペリエンス デザイン ライブラリ を使用します。このライブラリには原則が含まれており、実装ガイドラインを提供しています。 また、Microsoft 製品やその他の業界のソースからの例も示します。

ユーザー操作のライフ サイクル全体でワークロードの責任があります。 システムを使用するユーザーの意図から開始し、セッション全体を通して、およびシステム エラーによって引き起こされる中断中に続行します。 次のプラクティスを検討してください。

• 透明度を構築します。 システムがクエリに対して応答を生成する方法をユーザーに認識させる。

  モデルが予測のために参照するデータ ソースへのリンクを含めます。 この方法では、情報の起源を示すことで、ユーザーの信頼度を高めます。 データ設計では、これらのソースをメタデータに含める必要があります。 たとえば、取得拡張アプリケーションのオーケストレーターが検索を実行すると、20 個のドキュメント チャンクが取得され、上位 10 個のチャンクがコンテキストとしてモデルに送信されます。 上位 10 個のチャンクは、3 つの異なるドキュメントに属しています。 その後、UI は、モデルの応答を表示するときに、これら 3 つのソース ドキュメントを参照できます。 この透明性により、ユーザーの信頼が向上します。

  フロントエンド インターフェイスとバックエンド システム間の仲介役として機能するエージェントを使用する場合、透明性がより重要になります。 たとえば、チケット発行システムでは、オーケストレーション コードはユーザーの意図を解釈し、アプリケーション プログラミング インターフェイス (API) をエージェントに呼び出して必要な情報を取得します。 これらの相互作用を公開すると、ユーザーはシステムのアクションを認識しやすくなります。

  複数のエージェントを含む自動化されたワークフローの場合は、各ステップを記録するログ ファイルを作成します。 ログ ファイルは、エラーの特定と修正に役立ちます。 また、透明性を運用可能にする意思決定の説明もユーザーに提供します。

  注意事項

  透明性に関する推奨事項を実装する場合は、情報が多すぎるユーザーを圧倒しないようにします。 中断を最小限に抑える UI メソッドを使用して、段階的なアプローチを取ります。

  たとえば、モデルの信頼度スコアを示すヒントを表示します。 ソース ドキュメントへのリンクなど、ユーザーが詳細を選択できるリンクを組み込むことができます。 このユーザーが開始するメソッドは、UI の中断を抑え、ユーザーが選択した場合にのみ詳細情報を探すことができます。

• フィードバックを収集します。 フィードバック メカニズムを実装します。

  各回答の後に広範なアンケートを使用してユーザーを圧倒しないようにします。 代わりに、サムアップやサムダウンなどの迅速でシンプルなフィードバック メカニズムを使用するか、1 から 5 のスケールで回答の特定の側面に対する評価システムを使用します。 これらの方法は、時間の経過に伴うシステムの改善に役立ち、侵入することなく詳細なフィードバックを可能にします。 ユーザーの応答の背後には二次的な理由がある可能性があるため、フィードバックの公平性に関する潜在的な問題に注意してください。

  フィードバック メカニズムを実装すると、データ ストレージが必要になるため、アーキテクチャに影響します。 ユーザー データなどのフィードバックを扱い、必要に応じてプライバシー制御のレベルを適用します。

  応答フィードバックに加えて、ユーザー エクスペリエンスの有効性に関するフィードバックを収集します。 システムの監視スタックを使用してエンゲージメント メトリックを収集します。

コンテンツの安全対策を運用化する

カスタム ソリューション コード、適切なツール、効果的なセキュリティ プラクティスを使用して、AI ライフサイクルのあらゆる段階にコンテンツの安全性を統合します。 次の戦略を検討してください。

• データを匿名化します。 データが取り込みからトレーニングまたは評価に移行する場合は、個人情報漏洩のリスクを最小限に抑え、生のユーザー データ漏洩を回避するためのチェックを実装します。

• コンテンツをモデレートします。 要求と応答をリアルタイムで評価するコンテンツ セーフティ API を使用します。 これらの API に到達できることを確認します。

• 脅威を特定して軽減します。 よく知られたセキュリティ プラクティスを AI シナリオに適用します。 たとえば、脅威モデリングを実施し、脅威とその軽減方法を文書化します。 レッド チームの演習などの一般的なセキュリティ プラクティスは、AI ワークロードに適用されます。 赤色のチームは、有害なコンテンツを生成するためにモデルを操作できるかどうかをテストできます。 これらのアクティビティは、AI 運用に統合する必要があります。

  詳細については、「大規模言語モデルとそのアプリケーションに対するレッド チーミングの計画」を参照してください。

• 適切なメトリックを使用します。 モデルの動作を効果的に測定するメトリックを使用します。 メトリックは、AI モデルの種類によって異なります。 場合によっては、生成モデルの測定が回帰モデルに適用されない場合があります。 たとえば、モデルは平均寿命を予測し、結果は保険率に影響します。 このモデルの公平性の問題は、公平性関連の損害につながる可能性があります。 この問題は、一般的に公平性と精度のメトリックが相互接続されるため、コア メトリック テストの偏差に起因します。 公平性に関連する損害を減らすのに役立つ精度を向上させます。

• 適切なインストルメンテーションを追加します。 AI モデルの結果は説明可能である必要があります。 トレーニング データ、計算された特徴、接地データなど、推論がどのようにされるかを正当化し、トレースする必要があります。 差別的 AI では、意思決定を段階的に正当化できます。 ただし、生成モデルの場合、結果の説明は複雑になる可能性があります。 意思決定プロセスを文書化し 潜在的な法的影響に対処し、透明性を提供します。

  この説明性の側面は、AI ライフ サイクル全体を通じて実装する必要があります。 データクリーニング、系列、選択基準、および処理は、決定を追跡する必要がある重要な段階です。

ツール

Microsoft Purviewなど、コンテンツの安全性とデータの追跡可能性のためのツールを統合します。 Azure AI Content Safety API は、コンテンツの安全性テストを容易にするためにテストから呼び出すことができます。

Azure AI Foundry には、モデルの動作を評価するメトリックが用意されています。 詳細については、「 生成 AI の評価と監視メトリックを参照してください。

モデルのトレーニングについては、Azure Machine Learning が提供する メトリックを参照してください。

受信データと送信データを検査する

脱獄などの迅速なインジェクション攻撃は、AI ワークロードにとって一般的な懸念事項です。 この場合、一部のユーザーは意図しない目的でモデルを誤用しようとする可能性があります。 安全性を確保するために、データを検査して攻撃を防ぎ、不適切なコンテンツを除外します。 この分析をユーザーの入力とシステムの応答の両方に適用して、受信フローと送信フローのコンテンツ モデレーションを徹底します。

場合によっては、1 つのクライアント要求を処理するために、Azure OpenAI サービスなどの複数のモデル呼び出しを行う必要があります。 これらのシナリオでは、すべての呼び出しにコンテンツの安全性チェックを適用すると、コストがかかり、不要になる場合があります。 セキュリティ サーバー側の責任として維持しながら、アーキテクチャで動作することを中心に検討してください。 アーキテクチャに、特定のバックエンド機能をオフロードするためのゲートウェイがモデル推論エンドポイントの前にあるとします。 バックエンドがネイティブでサポートしていない可能性がある要求と応答のコンテンツの安全性チェックを処理するようにゲートウェイを設計できます。 ゲートウェイは一般的なソリューションですが、オーケストレーション レイヤーは、より単純なアーキテクチャでこれらのタスクを効果的に処理できます。 どちらの場合も、必要に応じてこれらのチェックを選択的に適用できるため、パフォーマンスとコストが最適化されます。

検査はマルチモーダル で、さまざまな形式に対応する必要があります。 画像などのマルチモーダル入力を使用する場合は、有害または暴力を受ける可能性のある非表示のメッセージを分析することが重要です。 これらのメッセージはすぐには表示されない可能性があるため、慎重な検査が必要です。 この目的には、Content Safety API などのツールを使用します。

プライバシーポリシーとデータセキュリティポリシーを適用するには、ユーザーデータを検査し、プライバシー規制に準拠するための基礎データを調べます。 データがシステムを通過する際に、データがサニタイズまたはフィルター処理されていることを確認します。 たとえば、以前のカスタマー サポートの会話からのデータは、基礎となるデータとして機能します。 このデータは、再利用する前にサニタイズする必要があります。

ユーザー データを適切に処理する

責任あるプラクティスには、ユーザー データ管理の慎重な処理が含まれます。 この管理には、データを使用するタイミングと、ユーザー データへの依存を回避するタイミングの把握が含まれます。

• ユーザー データを共有せずに推論を実践する。 分析情報を得るためにユーザー データを他の組織と安全に共有するには、クリアリングハウス モデルを使用。 このシナリオでは、組織は、集計データを使用してモデルをトレーニングする信頼できるパートナーにデータを提供します。 その後、すべての機関がこのモデルを使用し、個々のデータセットを公開することなく分析情報を共有できます。 目標は、詳細なトレーニング データを共有せずにモデルの推論機能を使用することです。

• 多様性と包摂性を促進する。 ユーザー データが必要な場合は、過小評価されているジャンルや作成者を含むさまざまなデータを使用して、公平性関連の損害を軽減します。 ユーザーが新しいさまざまなコンテンツを探索することを奨励する機能を実装します。 継続的に使用状況を監視し、単一のコンテンツ タイプが過剰に表示されないように推奨事項を調整します。

• RTBF を尊重します。 可能な場合は、ユーザー データの使用を避けてください。 ユーザー データが確実に削除されるように必要な対策を講じることで、RTBF への準拠を確保します。

  コンプライアンスを確保するために、システムからユーザー データを削除する要求がある場合があります。 小規模なモデルの場合は、個人情報を除外するデータを使用してモデルを再トレーニングすることで、ユーザー データを削除できます。 複数の小規模な独立してトレーニングされたモデルで構成できる大規模なモデルの場合、プロセスはより複雑になり、コストと労力が大幅に増加します。 これらの状況の処理に関する法的および倫理的なガイダンスを求め、責任ある AI のポリシーにガイダンスを含めるようにします。

• 責任を持ってデータを保持します。 データを削除できない場合は、 データ収集に対する明示的なユーザーの同意を保持し 明確なプライバシー ポリシーを提供します。 絶対に必要な場合にのみ、データを収集して保持します。 不要になったときにデータを積極的に削除する操作を行います。 たとえば、実用的なチャット履歴をすぐに消去し、保持前に機密データを匿名化します。 保存状態のこのデータには高度な暗号化方法を使用します。

• 説明可能性をサポートする。 説明性の要件をサポートするために、システム内の決定をトレースします。 レコメンデーション アルゴリズムのしくみの明確な説明を作成します。 特定のコンテンツが推奨される理由に関する分析情報をユーザーに提供します。 目標は、AI ワークロードとその結果が透過的で正当であることを確認するために、決定方法、使用するデータ、モデルのトレーニング方法を詳しく説明することです。

• ユーザー データを暗号化します。 入力データは、ユーザーがデータを入力した時点から、データ処理パイプラインのすべての段階で暗号化する必要があります。 これらのステージには、あるポイントから別のポイントに移動するデータ、格納されているデータ、必要に応じて推論されるデータが含まれます。 セキュリティと機能のバランスを取り、ライフサイクルを通じてデータを非公開にすることを目指します。

• 堅牢なアクセス制御を提供します。 複数の種類の ID がユーザー データにアクセスする可能性があります。 ユーザーとシステム間の通信をカバーするように、コントロール プレーンとデータ プレーンの両方にロールベースのアクセス制御を実装します。

  プライバシーを保護するために、適切なユーザー セグメント化を維持します。 たとえば、Microsoft 365 Copilot は、ユーザーの特定のドキュメントや電子メールに基づいて回答を検索して提供し、そのユーザーに関連するコンテンツのみにアクセスできるようにします。

• 表面積を削減します。 Well-Architected Framework セキュリティの柱の基本的な戦略は、攻撃対象領域を最小限に抑え、リソースを強化することです。 API エンドポイントを厳密に制御し、重要なデータのみを公開し、応答で余分な情報を回避することで、この戦略を標準のエンドポイント セキュリティ プラクティスに適用する必要があります。 柔軟性と制御の間で設計の選択のバランスを取ります。

  匿名エンドポイントがないことを確認します。 一般に、ユーザーに必要以上の制御を与えないようにします。 ほとんどのシナリオでは、実験環境を除き、ユーザーはハイパーパラメーターを調整する必要はありません。 仮想エージェントとの対話などの一般的なユース ケースでは、ユーザーは不要な制御を制限することでセキュリティを確保するために重要な側面のみを制御する必要があります。

詳細については、「Azureでの AI ワークロードのアプリケーション設計」を参照してください。

次の手順