生成 AI をセキュアにする: データ、コンプライアンス、プライバシーに関する考慮点

本ブログは 2024 年 3 月 27 日に公開された「Securing generative AI: data, compliance, and privacy considerations」を翻訳したものとなります。

生成 AI は世界中の組織や個人の想像力をかき立て、従業員の生産性の向上や顧客体験の変革、さらに多くのことに採用されています。

生成 AI ベースのサービスを使用する場合、アプリケーションに入力した情報が、モデルプロバイダまたはモデルが実行される環境のプロバイダによってどのように保存、処理、共有、使用されるかを理解する必要があります。生成 AI ソリューションを提供する組織は、自社のアプリケーションやモデルの使用方法やトレーニング方法におけるプライバシー、コンプライアンス、セキュリティの検証に役立つように設計された適切な保護手段をユーザーや消費者に対して構築する責任があります。

このブログは、生成 AI をセキュアにするシリーズの続きで、生成 AI ワークロードのデプロイと構築における規制、プライバシー、コンプライアンスの課題に関するガイダンスを提供します。このシリーズの最初のブログ「生成 AI をセキュアにする：生成 AI セキュリティスコーピングマトリックスの紹介」を読むことをお勧めします。このブログでは、ブログシリーズの基礎となる生成 AI のユースケースを特定するのに役立つツールである生成 AI スコーピングマトリックスを紹介しています。

図 1 はスコーピングマトリックスを示しています。

図 1 : 生成 AI スコーピングマトリックス

大まかに言えば、スコーピングマトリックスにより、ユースケースを事前に構築された生成 AI アプリケーション（スコープ 1 と 2 ）と自身で構築する生成 AI アプリケーション（スコープ 3 ～ 5 ）の 2 つのカテゴリに分類できます。5 つのスコープすべてにいくつかの一貫した法律、ガバナンス、コンプライアンス要件が適用されますが、各スコープには固有の要件と考慮事項もあります。各スコープの主な考慮事項とベストプラクティスについて説明します。

スコープ 1 : コンシューマアプリケーション

コンシューマーアプリケーションは通常、一般ユーザーまたは専門家でないユーザーを対象としており、通常はWeb ブラウザーまたはモバイルアプリからアクセスします。生成 AI で最初に話題になったアプリケーションの多くはこのスコープに該当し、標準のエンドユーザー使用許諾契約 (EULA) を使用して無償または有償で提供されます。これらのアプリケーションは特に企業での利用に向けて構築されていないかもしれませんが、広く普及しています。従業員は個人的な用途でこれらを使用したり、業務に役立つような機能を期待しているかもしれません。

多くの大規模組織は、入力されたデータに何が起こるか、また誰がデータにアクセスできるかをコントロールできないため、これらのアプリケーションをリスクと見なしています。これに対応して、組織はスコープ 1 のアプリケーションの利用を禁止します。リスクの評価にはデューデリジェンスを奨励していますが、全面的な禁止は逆効果になる可能性があります。スコープ 1 のアプリケーションを禁止すると、シャドー IT と同様の意図しない結果が生じる可能性があります。たとえば、従業員が個人用デバイスを使用して利用制限のためのコントロールを回避したり、使用されるアプリケーションの可視性が低下するなどです。組織は生成 AI アプリケーションを禁止するのではなく、組織がコントロールでき組織内で使用が許可されているデータの範囲内で、これらのアプリケーションのうち、従業員が効果的に使用できるものがどれかを検討する必要があります。

生成 AI に関連するリスクと許容される使用方法を従業員が理解できるようにするには、具体的な利用ガイドラインを含む生成 AI ガバナンス戦略を策定し、ユーザーがこれらのポリシーを適切なタイミングで認識していることを確認する必要があります。たとえば、組織が発行および管理するデバイスを使用しWeb ブラウザーで生成 AI ベースのサービスにアクセスするときに、会社で公開されている生成 AI 利用ポリシーへのリンクと、スコープ 1 のサービスにアクセスするたびにポリシーに同意を要求するボタンを提供するよう、プロキシまたはクラウドアクセスセキュリティブローカー（CASB）に制御させることができます。これにより、そのようなサービスを利用する前に、従業員がトレーニングを受け、リスクを理解し、ポリシーに同意していることを確認できます。

スコープ 1 のアプリケーションに関連するいくつかの主要なリスクに対処するには、以下の考慮事項を優先してください。

従業員が現在使用している、または使用しようとしている生成 AI サービスを特定します。
誰がデータにアクセスできるのか、プロンプトや出力などのデータに対して何ができるか、データの使用方法と保存場所など、各サービスのサービスプロバイダの利用規約とプライバシーポリシーを理解します。
モデルプロバイダがモデルのトレーニングに使用するソースデータを理解します。出力が正確で、リクエストに関連していることをどのように知ることができますか？出力が正確でユースケースに関連していることをレビューおよび検証しやすくするために人間ベースのテストプロセスを導入することを検討します。また正確性と関連性についてユーザーからフィードバックを収集して応答を改善するメカニズムを提供します。
受け取った出力の影響や、出力の商業的な利用については、法的ガイダンスを求めてください。スコープ 1 の生成 AI アプリケーションからの出力の所有者を決定したり、(たとえば) 推論中に個人情報や著作権で保護された情報が出力に使用され、その後生成された出力を組織が使用する場合に誰が責任を負うかを決定します。
これらのアプリケーションの EULA とプライバシーポリシーは、最小限の通知で時間の経過とともに変更されます。ライセンス条件の変更は、出力の所有権の変更、データの処理と取り扱いの変更、さらには出力の使用に関する責任の変更が生じる可能性があります。承認された生成 AI アプリケーションのポリシーを監視するための計画 / 戦略 / メカニズムを作成します。変更を確認し、それに応じてアプリケーションの使用を調整してください。

スコープ 1 のアプリケーションでは、入力プロンプトと生成されたコンテンツは公開されているものと考え、これらのアプリケーションでは個人を特定できる情報（PII）、センシティブなデータ、機密データ、独自のデータ、または企業の知的財産（IP）データを使用しないことが最善の方法です。

スコープ 1 のアプリケーションでは、特に従業員が無料または低コストの価格帯で使用している場合、データの所在地と管轄権の観点から見ると、通常選択肢が最も少なくなります。データを保存する国やデータ処理に適用される法律について組織に厳しい要件がある場合、スコープ 1 のアプリケーションは最小限のコントロールしか提供しないため、要件を満たすことができない可能性があります。

スコープ 2 : エンタープライズアプリケーション

スコープ 1 とスコープ 2 のアプリケーションの主な違いは、スコープ 2 のアプリケーションでは契約条件を交渉し、正式な組織間（B2B）の関係を確立する機会が提供されることです。サービスレベルアグリーメント（SLA）とライセンス契約条件が定められ、組織のプロフェッショナルな利用を対象としており、通常はエンタープライズ契約または標準的なビジネス契約条件に基づいて料金が支払われます。締結されている企業契約では、通常、特定のタイプ（および機密性）のデータに対して承認された利用に限定されます。

スコープ 1 のほとんどの側面はスコープ 2 にも当てはまります。ただし、スコープ 2 では、独自のデータを意図的に使用し、組織全体でのサービスの広範な使用を奨励します。リスクを評価する際には、追加で次の点を考慮してください。

利用が許可されているスコープ 2 の各アプリケーションで許容されるデータ分類を決定し、それを反映するようにデータ処理ポリシーを更新し、従業員のトレーニングに含めます。
サービスのデータフローを理解してください。プロバイダに、データ、プロンプト、出力をどのように処理および保存するのか、誰がどのような目的でアクセスできるのかをを尋ねてください。彼らが主張する内容の証拠を提供する認証書や証明書はありますか。また、これらは組織の要求と一致していますか。これらの詳細が、あなたまたはあなたの組織が同意する契約条件に含まれていることを確認してください。
（もしあれば）このアプリケーションで使用するデータの種類について、どのようなデータ所在地の要件がありますか。データの保存場所と、それが法的または規制上の義務と整合するかどうかを理解します。
- 多くの主要な生成 AI ベンダーが米国で事業を展開しています。米国外に拠点を置き、そのサービスを利用する場合、米国との間のデータ転送に関連する法的影響とプライバシー義務を考慮する必要があります。
- データ所在地の選択肢を提供するベンダーは、多くの場合、特定の管轄区域でデータを処理するためにユーザーが使用する必要がある特定のメカニズムを用意しています。場合によってはアカウント作成時に指定したり、アカウントを作成した後に特定の種類の処理を選択したり、特定の地域のエンドポイントに接続してサービスにアクセスしたりする必要がある場合があります。
ほとんどのスコープ 2 のプロバイダは、データを使用して基盤モデルの強化とトレーニングを行いたいと考えています。利用規約に同意すると、おそらくデフォルトで同意することになります。そのようなデータの使用が許可できるかどうかを検討してください。データをモデルのトレーニングに使用すると、同じサービスで後に別のユーザーが出力からデータを受け取るリスクがあります。データの再利用を防ぐ必要がある場合は、プロバイダのオプトアウトオプションを探してください。オプトアウトするためのセルフサービスオプションがない場合は、交渉が必要となる場合があります。
エンタープライズ生成 AI ツールを使用する場合、企業によるツールの使用状況は通常 API 呼び出しによって計測されます。つまり、API への特定の呼び出し回数に対して一定の料金を支払うことになります。これらの API 呼び出しは、プロバイダがユーザーに発行する API キーによって認証されます。これらの API キーを保護し、その使用状況を監視するための強力なメカニズムが必要です。API キーが権限のない第三者に漏れた場合、その第三者は API 呼び出しを行うことができ、その呼び出しはユーザーに請求されます。これらの権限のない第三者による使用も組織によるものと見なされ、モデルをトレーニングする可能性があり（同意した場合）、モデルを無関係なデータや悪意のあるデータで汚染することにより、その後のサービスの使用に影響を与える可能性があります。

スコープ 3 : 事前学習済みのモデル

事前構築済みのアプリケーション (スコープ 1 と 2 ) とは対照的に、スコープ 3 のアプリケーションでは、Amazon Bedrock や Amazon SageMaker JumpStart などのサービスを通じて利用できる事前トレーニング済みの基盤モデルを使用して、独自の生成 AI アプリケーションを構築します。これらのソリューションは、従業員や外部の顧客に使用できます。スコープ 1 と 2 のガイダンスの多くはここでも当てはまりますが、他にも考慮すべき点がいくつかあります。

モデルプロバイダの一般的な機能として、アウトプットが期待と一致しない場合にフィードバックを提供できます。モデルベンダーには、使用できるフィードバックメカニズムがありますか。その場合は、フィードバックを送信する前に、機密コンテンツを削除する仕組みがあることを確認してください。
プロバイダは、商業的に利用するために生成された潜在的な著作権コンテンツに対して法的異議申し立てがあった場合、補償ポリシーをもっていますか。また、それに関する判例はありますか。
プロンプトまたはレスポンスに含まれるデータをモデルプロバイダは使用しますか。もしそうなら、どのような目的で、どの場所で、どのように保護されていますか。また、プロバイダがトレーニングなどの他の目的に使用することをオプトアウトできますか。Amazon では、お客様からのプロンプトやアウトプットを Amazon Bedrock や SageMaker JumpStart の基盤となるモデル (サードパーティ製のモデルを含む) のトレーニングや改善に使用することはなく、人間がそれらをレビューすることもありません。また、お客様のデータをサードパーティのモデルプロバイダと共有することはありません。データはお客様の AWS アカウント内でプライベートに保たれます。
出力検証のプロセス、ガイドライン、およびツールを確立します。ファインチューニングされたモデルに基づいた出力に正しい情報が含まれていることをどのように確認しますか。また、モデルの精度をどのようにテストしますか。例えば :
- アプリケーションがテキストを生成する場合は、テストと出力の検証プロセスを作成し、生成された出力が期待どおりの結果を生成していることを確認するために、定期的に (たとえば、週に 1 回) 人間によるテストを行います。
- 別のアプローチとしては、アプリケーションのユーザーが出力の正確性と関連性に関する情報を送信するために使用できるフィードバックメカニズムを実装する方法があります。
- プログラミングコードを生成する場合、組織内で他のコードをチェックして検証するのと同じ方法でこれをスキャンして検証する必要があります。

スコープ 4 : ファインチューニングされたモデル

スコープ 4 はスコープ 3 の拡張であり、アプリケーションで使用するモデルは、提供されたデータを使用してファインチューニングされ、応答が改善され、ニーズにより具体的に応えられるようになります。スコープ 3 の考慮事項はスコープ 4 にも関連します。さらに、次の点を考慮する必要があります。
モデルのファインチューニングに使用されるデータのソースは何ですか。ファインチューニングに使用されるソースデータの品質、その所有者、使用時に著作権やプライバシーの問題にどのようにつながる可能性があるかを理解します。
ファインチューニングされたモデルは、ファインチューニングに使用するデータを含め、関連するデータ全体のデータ分類を継承することに注意してください。機密データを使用する場合は、使用されるデータと同じ分類のようにモデルと生成されたコンテンツへのアクセスを制限する必要があります。
基本的に、モデルのチューニングに使用するデータには注意が必要です。考え方を変えると（訳者注 : 再度モデルのチューニングが必要となるため）コストと遅延が増えるからです。PII に基づいてモデルを直接チューニングし、後でそのデータをモデルから削除する必要があると判断した場合、データを直接削除することはできません。現在のテクノロジーでは、モデルがデータの学習を解除する唯一の方法は、モデルを完全に再トレーニングすることです。通常、再トレーニングには多くの時間と費用がかかります。

スコープ 5 : 自身でトレーニングしたモデル

スコープ 5 のアプリケーションでは、アプリケーションを構築するだけでなく、収集したりアクセスできるトレーニングデータを使用してモデルをゼロからトレーニングすることもできます。現在、モデルが使用するデータ本体に関する完全な情報を提供する唯一のアプローチです。データは、組織の内部データ、公開データ、またはその両方である可能性があります。トレーニングプロセスのさまざまな側面を制御でき、オプションでファインチューニングプロセスも制御できます。データ量、モデルのサイズと複雑さにもよりますが、スコープ 5 のアプリケーションを構築するには、他のどの種類のAIアプリケーションよりも多くの専門知識、費用、時間が必要です。一部のお客様にはスコープ 5 のアプリケーションを作成したいという明確なニーズがありますが、多くのビルダーがスコープ 3 またはスコープ 4 のソリューションを選択していることがわかります。

スコープ 5 のアプリケーションでは、以下の点を考慮する必要があります。

あなたはモデルプロバイダであり、EULA を通じてデータがどのように使用、保存、および維持されるかをモデルユーザーに明確に伝える責任を負う必要があります。
アプリケーションに必要でない限り、PII や機密性の高いデータでモデルを直接トレーニングすることは避けてください。
トレーニングされたモデルには、ソースとなったトレーニングデータと同じ規制要件がすべて適用されます。規制およびコンプライアンス要件に従って、トレーニングデータとトレーニングされたモデルを管理および保護します。モデルがトレーニングされると、トレーニングされたデータのデータ分類が継承されます。
機密情報漏洩の潜在的なリスクを制限するには、アプリケーションユーザーのデータ（プロンプトと出力）の使用と保存を必要最小限に制限してください。

AI 規制と法律

AI 規制は急速に進化しており、これがお客様や、ワークロードの一部として AI を含む新しいサービスの開発に影響を与える可能性があります。AWS では、責任を持って AI を開発し、教育、科学、お客様を優先する人を中心としたアプローチを採用して、責任ある AI をエンドツーエンドの AI ライフサイクル全体に統合することに全力を注いでいます。詳細については、「責任ある AI リソース」をご覧ください。OECD AI Policy Observatory は、さまざまな AI ポリシーや規制を理解するうえで役立ち、自分自身や顧客に影響を与える可能性のある世界中の AI 政策イニシアチブに関する情報を得るための入り口として最適です。このブログの公開時点で、69 か国以上で 1,000 を超えるイニシアチブがあります。

このセクションでは、欧州連合（EU）の人工知能（AI）法（EUAIA）と人工知能に関する米国大統領令という2つの異なる提案から規制テーマを検討します。

AI に関する規制と法制化に関する私たちの提言はシンプルです。規制環境を監視し、必要に応じてプロジェクトの範囲を変更する準備をしておくことです。

テーマ 1 : データプライバシー

英国個人情報保護監督機関（UK ICO）によると、生成 AI の出現によってデータプライバシー法の原則やそれを守る義務が変わることはありません。生成 AI ワークロードで個人データを使用する場合は影響があります。個人データは、モデルの学習時や、入力として AI システムに送信されたり、AI システムによって出力として生成されたりしたときに、モデルに含まれる可能性があります。入力と出力の個人データを使用して、再トレーニングを行うことで、時間の経過とともにモデルの精度を高めることができます。

AI プロジェクトでは、多くのデータプライバシー法により、使用するデータを業務の遂行に厳密に必要な範囲に限定することが義務付けられています。このトピックをさらに詳しく調べるには、英国の ICO が公開している 8 つの質問のフレームワークをガイドとして使用できます。このフレームワークを AI プロジェクトのデータプライバシーリスクを確認するメカニズムとして使用し、法律顧問またはデータ保護責任者と協力することをお勧めします。

簡単に言うと、プロジェクトでは「不要なデータを記録しない」という原則に従ってください。

テーマ 2 : 透明性と説明可能性

OECD AI Observatory では、AI ワークロードのコンテキストにおける透明性と説明可能性を定義しています。まず、AI がいつ使われているかを公開することです。たとえば、ユーザーが AI チャットボットとやり取りする場合は、その旨を伝えます。2 つ目は、AI システムがどのように開発され、トレーニングされ、どのように運用されているかを人々が理解できるようにすることです。たとえば、英国の ICO では、AI システムの仕組みを説明する文書やその他のアーティファクトを提供すべきかについてのガイダンスを提供しています。一般に、透明性は独自のソース、コード、またはデータセットまで開示をする必要はありません。説明可能性とは、AI システムがどのようにして決定に至ったかを影響を受けた人々や規制当局が理解できるようにすることです。たとえば、ユーザーが同意できない出力を受け取った場合、その出力に異議を申し立てることができるようになっている必要があります。

では、これらの法的要件を満たすにはどうすればよいでしょうか。実際には、AI システムの開発と運用のライフサイクル全体にわたって AI 原則をどのように実装したかを文書化したことを規制当局に示す必要があるかもしれません。ICO ガイダンスに加えて、ISO 42001:2023 に基づく AI 管理システムの実装を検討することもできます。

透明性をさらに掘り下げてみると、データの収集方法やモデルのトレーニング方法に関する証拠を規制当局に示す必要がある場合があります。

データ収集プロセスの透明性は、データに関連するリスクを軽減するために重要です。プロジェクトにおけるデータ収集プロセスの透明性を管理するのに役立つ主要なツールの 1 つは、Pushkarna と Zaldivar のデータカード（2022）ドキュメントフレームワークです。データカードツールは、機械学習 (ML) データの構造化された概要を提供し、データソース、データ収集方法、トレーニングと評価の方法、使用目的、モデルのパフォーマンスに影響する決定を記録します。オープンソースまたは公開ソースからデータセットをインポートする場合は、Data Provenance Explorer イニシアチブを確認してください。このプロジェクトでは、ライセンス、作成者、およびデータの出所について、1,800 を超えるデータセットを監査しました。

説明性、ガバナンス、およびレポート作成に関連するリスクを軽減するには、モデル作成プロセスの透明性が重要です。Amazon SageMaker にはモデルカードと呼ばれる機能があります。これを使用すると、ML モデルに関する重要な詳細を 1 か所で文書化し、ガバナンスとレポートを合理化できます。モデルの使用目的、リスク評価、トレーニングの詳細と指標、評価結果と観察結果などの詳細をカタログ化する必要があります。

組織外でトレーニングされたモデルを使用する場合は、標準契約条項 (SCC) に頼る必要があります。SCC では、特にデータがEU から第三国に転送される場合に、モデルがトレーニングを受けた可能性のあるあらゆる個人情報の共有と転送が可能になります。デューデリジェンスの一環として、モデルのベンダーに連絡して、データカード、モデルカード、データ保護影響評価（ISO 29134:2023 など）、または移転影響評価（IAPPなど）を依頼する必要があります。そのような文書が存在しない場合は、そのモデルを使用する決定を下す際に、これを独自のリスク評価に織り込む必要があります。自社製品の透明性の確立に取り組んできたサードパーティの AI プロバイダの例としては、Twilio と SalesForce の 2 つがあります。Twilio は、データとモデルを理解しやすくするために、自社製品に AI 栄養成分表示ラベル (AI Nutrition Label) を提供しています。SalesForce は、利用規約を変更することでこの課題に対処しています。

テーマ 3 : 自動化された意思決定と人間による監視

2026 年から施行される EUAIA の最終草案は、AI モデルには人間の介入や上訴権がないため、自動化された意思決定がデータ主体に害を及ぼす可能性があるというリスクに対処しています。モデルからの応答は推論に基づいた確率的な正確性であるため、確実性を高めるために人間の介入をどのように組み込むかを検討する必要があります。これは、人々をプロファイリングしたり、社会的給付の受給について決定を下したりするモデルなど、人々に深刻な社会的および法的影響をもたらす可能性のあるワークロードにとって重要な問題です。AI プロジェクトのビジネスケースを開発する際には、ワークフローのどこに人間による監視を適用すべきかを検討することをおすすめします。

英国の ICO は、ワークロードでどのような具体的対策を講じるべきかについてのガイダンスを提供しています。データの処理に関する情報をユーザーに提供したり、ユーザーが人間の介入を要求したり決定に異議を申し立てたりする簡単な方法を紹介したり、システムが意図したとおりに機能していることを確認するために定期的なチェックを実施したり、AI の決定に異議を唱える権利を個人に与えたりすることができます。

AI に関する米国大統領令には、デリケートな特性に基づく自動的な差別から人々を保護する必要性が記載されています。この命令により、個人の権利が保護され、これらのシステムの成果が公平であることを検証するために、積極的かつ検証可能な措置を講じる責任が AI 製品の開発者に課せられます。

このトピックに関する規範的な指針は、ワークロードのリスク分類を評価し、ワークフローの中で人間のオペレーターが結果を承認または確認する必要があるポイントを特定することです。AI のトレーニングデータまたは意思決定における偏りに対処するには、AI の意思決定を助言として扱う方針を持つことや、それらの偏りを認識してワークフローの一部として手動アクションを実行するように人間のオペレーターを訓練することなどが含まれます。

テーマ 4 : AI システムの規制分類

組織がリスクを管理するためにデータを分類するのと同じように、規制の枠組みの中には AI システムを分類するものもあります。自分に影響を及ぼす可能性のある分類についてよく理解しておくことをお勧めします。EUAIA は、リスクのピラミッドモデルを使用してワークロードタイプを分類しています。( EUAIA によると) ワークロードに許容できないリスクがある場合、そのワークロードは完全に使用禁止になる可能性があります。

禁止されたワークロード
EUAIA は、CCTV や大規模監視システム、公的機関によるソーシャルスコアリングに使用されるシステム、機密特性に基づいてユーザーをプロファイリングするワークロードなど、禁止されている AI ワークロードをいくつか指定しています。規制当局からの最新情報を使用して、開発ライフサイクルの早い段階でワークロードの法的評価を行うことをお勧めします。

高リスクワークロード
また、データプライバシー法でリスクが高いと見なされるデータ処理活動にはいくつかの種類があります。このカテゴリでワークロードを構築する場合は、規制当局によるより高いレベルの精査を予期し、規制要件を満たすためにプロジェクトのスケジュールに追加のリソースを含める必要があります。幸いなことに、透明性、説明のしやすさ、リスク評価または脅威モデルを文書化するために作成したアーティファクトは、レポート要件を満たすのに役立つ可能性があります。これらのアーティファクトの例については、英国の ICO が公開している AI とデータ保護リスクツールキットをご覧ください。

ハイリスクの処理の例としては、ウェアラブル、自動運転車などの革新的なテクノロジーや、信用調査や保険見積もりなどのユーザーへのサービスを拒否する可能性のあるワークロードなどがあります。AI プロジェクトの早い段階で弁護士に相談して、ワークロードを見直し、どの規制文書を作成して管理する必要があるかをアドバイスを受けることをおすすめします。ハイリスクワークロードのその他の例については、こちらの英国の ICO サイトでご覧いただけます。

テーマ 5 : プロファイリング

EUAIA は、個人をプロファイリングをするワークロードにも特に注意を払っています。英国の ICO では、このワークロードを「個人に関する特定の個人的側面を評価するため、特に自然人の職務遂行能力、経済状況、健康、個人の好み、興味、信頼性、行動、場所、移動に関する側面を分析または予測するために個人データを使用するあらゆる形態の個人データの自動処理」と定義しています。私たちのガイダンスとしては、AI プロジェクトの早い段階で法務チームにレビューを依頼すべきだということです。

プロジェクトが組織のリスクアペタイトの範囲内にあるかどうかを判断しやすくするために、規制審査をタイムラインに組み込むことをお勧めします。法律は急速に変化しているため、法的環境を継続的に監視することをお勧めします。

テーマ 6 : 安全

ISO 42001:2023 では、AI システムの安全性を「人の生命、健康、財産、環境を危険にさらすことなく、どのような状況でも期待どおりに動作するシステム」と定義しています。

米国の AI 権利章典では、人々には安全でないシステムや効果のないシステムから保護される権利があると述べています。2023 年 10 月、バイデン大統領は安全、安心、信頼できる人工知能に関する大統領令を発行しました。これは、AI システムの使用状況を理解し、その使用によって影響を受けるコミュニティの利害関係者を関与させる必要があることを強調しています。大統領令には、AI システムの文書化、統制、テスト、および独立した検証についても記載されており、これは前に説明した説明可能性のテーマと密接に一致しています。ワークロードについては、説明可能性と透明性の要件を満たしていることを確認し、安全性に関する懸念が生じた場合に規制当局に見せるアーティファクトを用意してください。OECD はここで規範的なガイダンスを提供しており、ワークロードのトレーサビリティとリスク管理に関する ISO 23894:2023 AI ガイダンスなどを用いた定期的かつ適切なリスク評価の必要性を強調しています。

結論

生成 AI は組織にとって新しいテクノロジーかもしれませんが、現状他の分野で使用している既存のガバナンス、コンプライアンス、プライバシーのフレームワークの多くは、生成 AI アプリケーションにも適用されます。生成 AI モデル、プロンプト入力、アプリケーションからの出力のトレーニングに使用するデータは、環境内の他のデータと同じように扱い、既存のデータガバナンスとデータ処理ポリシーの範囲内にある必要があります。特に子供や脆弱な人々がワークロードの影響を受ける可能性がある場合は、個人データに関する制限に注意してください。独自のデータを使用してモデルをファインチューニングする場合、使用されているデータを確認し、データの分類、データの保存場所と保護方法と場所、データおよびトレーニングされたモデルにアクセスできるユーザー、エンドユーザーが表示できるデータを把握してください。生成 AI の使用目的、使用方法、遵守すべきデータ保護ポリシーについてユーザーをトレーニングするプログラムを作成してください。第三者から入手したデータについては、それらのサプライヤーのリスク評価を行い、データの出所を確認するのに役立つデータカードを探してください。

通常、規制や法律の策定と制定には時間がかかりますが、生成 AI にはすでに既存の法律が適用されており、AI に関する他の法律も生成 AI を含むように進化しています。担当の弁護士が、これらの変更に関する最新情報を常に把握できるように支援してくれるはずです。独自のアプリケーションを作成するときは、アプリケーションがもたらすリスクに応じて、アプリケーション
が制限されたり禁止されたりする可能性があるため、事業を展開する場所にすでに存在する可能性のある他の多くの法律や規制に加えて、草案段階の新しい法律や規制（EU AI 法など）と、それが自分に影響するかどうかを知っておく必要があります。

AWS では、生成 AI のビジネス価値を組織内でより簡単に実現できるようにしています。これにより、生成 AI による顧客体験の改革、生産性の向上、成長の加速が可能になります。生成 AI セキュリティのその他の分野について詳しく知りたい場合は、以下に記載する「生成 AI をセキュアにする」シリーズの他の記事をご覧ください。

このブログについて質問がある場合は、Generative AI on AWS re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

翻訳はプロフェッショナルサービス本部の保里善太と藤浦雄大が担当しました。

Amazon Web Services ブログ