生成 AI を利用するためにコンプライアンス関連の話を考える
はじめに
大規模言語モデルをベースとした生成 AI は、組織専用の生成 AI チャットや、業務処理を支援するアプリとして多くの組織に導入されています。本記事では、生成 AI をシステムに組み込んで利用するにあたってコンプライアンス観点での考慮事項を整理します。
法的に正確な解釈が求められるトピックも含むため、本記事は以下の免責事項を踏まえて参照してください。
免責事項
- 本記事は、日本マイクロソフト社員として相談を受けるという前提で執筆していますが、執筆時点での筆者の所属 (日本マイクロソフト) の公式的な見解でありません。
- 本記事は、筆者の調査に基づく断片的な情報がベースとなっており、特定の状況に対する助言を提供するものではありません。記事の内容は、投稿日時点での情報に基づいています。
- この記事の情報を利用して行動を起こす前に、専門家に相談することを強く推奨します。この記事の情報に基づいて行動を取った結果について、ブログの所有者、管理者、作成者、貢献者は一切の責任を負いません。
- この記事に掲載されている情報は、可能な限り正確であるように努力していますが、その正確性や完全性を保証するものではありません。また、筆者は情報が時代遅れになったり、その他の理由で不正確になった場合でも、情報を更新する義務を負いません。
よくある要求事項
私がお客様からコンプライアンス観点の質問として次のようなものをよくいただくことがあります。
「〇〇(コンプライアンスや法規制の名称)対応について社内のしかるべき部署から指摘を受けたので、貴社の見解を提示して欲しい」
本記事では、上記の〇〇に当てはまるよくある事項3つについて整理したいと思いますが、各論に入る前に、まずは全般的なことを整理しておきたいと思います。
全般的な整理
とても重要なポイントとしてまず整理しておきたいのは、「問い合わせ先の会社が回答を出せば解決する類の問題かどうかを正しく認識しておく必要がある」ということです。
そして、多くの場合、「しかるべき部署からの指摘」に対して適切に回答するためには自社側（プロジェクトや担当部署）での検討や準備が必要になります。
例えば、SaaS である Microsoft 365 で提供される Microsoft Teams (以下、Teams) を考えてみましょう。
- Teams には会議を録画する機能があり、ある会議を録画したと仮定します。
- この Teams 録画データには会議の出席者個人の音声が含まれています。
- この時、Teams 録画データに対して会議内の話者個人から削除要請が来たとします。
- 個人情報保護の観点では適切な要求であり、Teams 録画データを削除する必要があります。
さて、このデータは誰が削除することになるでしょうか。
マイクロソフトが提供するオンラインサービスには データ保護追加契約 (Protection Addendum) があり、オンライン サービス上でお客様が作成したデータはお客様に権利があることになります。これは、マイクロソフトがお客様の作成したデータに勝手にアクセスしたり、改変したりすることはないということでもあります。
つまり、前述の設問については「Teams 録画を行った本人」や「社内のMicrosoft 365 管理者」など、Teams を利用する組織側で削除する、ということになります。
つまり、Teams 録画データの個人情報保護が「しかるべき部署からの指摘」だった場合、適切に回答するためには、
- データ削除の依頼を受けて完了させるための体制
- データ削除の依頼を受けて完了させるためのワークフロー
の準備が必要になります。
よく挙がるコンプライアンスや法規制事項と対応の整理
それでは、個々の事項に対する整理をしていきましょう。
GDPR
GDPR は欧州の話だと思われていたのは、今や昔のことではないでしょうか。多くの企業が既に取り組んでいるため、今更という感じもあるかもしれません。（個人の感想です）
さて、GDPR は個人情報保護のためルールなので、先に例として挙げた Teams のように、各種申請の受付や、それに伴うデータ制御のための体制が必要になります。
そして、その前に考えた方がいいなと思うのは「そのシステムは対象となる人物が利用するか？」という点です。少しでも対象者が利用できる可能性があるのであれば対応を考える必要がありますが、どの程度の規模のユーザー数が想定されるかも一度検討してみるとよいでしょう。1万ユーザーあたり1名のために完全自動化された仕組みを準備するのはコスト効率の観点で釣り合わないため、ルールと手順の整理に留めるのも一つの対応の形かと思います。
ここまでくると、対象となるデータは少なからずシステム内に入ってくることになるため、システムを構築して稼働させる場所についても検討が必要になってくると思います。システムを稼働させる基盤として Microsoft Azure を選択した場合は、対象の Azure リソースをどのリージョンで稼働させるかが重要になってきます。
ほとんどのリソースはリージョンを指定して展開できるため、EU圏内や十分性認定を受けている各国のリージョンを指定していくことになると思います。ただし、生成 AI サービスとして登場してきた、 Azure OpenAI Service には、グローバル標準デプロイメントというモデル展開の方式があり、注意が必要になります。
グローバル標準デプロイメントは、AI による推論処理を実行するリージョンを Azure 側の都合（リソース利用状況等を考慮）で動的に決定します。すべてのリージョンが十分性認定のある国に存在すれば何も懸念はないのですが、一部のリージョンは十分性認定のない国にあるために問題となるかと思います。選択肢としては、標準デプロイメントを利用するか、DataZone標準デプロイメントがあり、いずれかを利用して対処することができます。
ここまでを整理すると以下のようになります。
- 利用者の想定属性を明確にする
- GDPR 対象者を含む場合
- どのような状態まで事前準備を実施するかを決定する
- どこでシステムを稼働させるかを決定する
- クラウドのサービスがどのように動作するかを理解して対処する
生成結果における個人情報
前段のGDPRの延長で日本国内向けの話のようではありますが、違った観点になります。
具体的には、
生成 AI が個人情報と思わしきデータを生成してしまったらどうする？
という点です。「思わしき」として曖昧にしているのは、確実に実在する個人であると明言はできないものの、住所や氏名など、個人情報として扱われるデータ項目が含まれていることを指しています。サンプルデータにありがちな、〇〇太郎や〇〇花子のようなものと思っていただくとよいかと思います。
このような結果が生成されるパターンとしては、以下の3つの可能性があるかと思います。
- プロンプトで情報や指示を与えていないが生成 AI モデルが出力
- プロンプトで情報や指示を与えたため、生成 AI モデルが出力
- 微調整で情報を与えたため、生成 AI モデルが出力
後ろの2つのパターンについては、プロンプトの調整、微調整用のデータの調整を実施して、個人情報を含めない形にする必要があるでしょう。
AI モデルの利用者側で対処が難しいのは最初のパターン「プロンプトで情報や指示をを与えていないが生成 AI モデルが出力」です。モデルが既に内包している知識であるため、プロンプトによってある程度抑え込むようなことはできますが、100％ で抑止することはできないため、最終的にはアプリケーション側で応答をチェックして個人情報らしきものが含まれていなければ採用する、のような処理を入れる必要があります。
なお、なぜそのような知識を持ち合わせているのか、についてはモデルの開発側で情報が公開されています。Azure OpenAI Service の場合、モデルは OpenAI 社で開発されていますので、OpenAI 社の公開情報を参照する必要があります。
ここまでを整理すると以下のようになります。
- 個人情報と思わしき結果が生成された経緯を確認する
- 生成 AI モデルが対象データを生成した場合は、アプリケーションで対処する
- プロンプトが原因で対象データを生成した場合は、プロンプトを変更する
- 微調整が原因で対象データを生成した場合は、微調整用のデータを変更する
著作権
ただしくは、著作権侵害といった方がよいかもしれません。2023年9月、マイクロソフトは Copilot を顧客が利用によって、著作権を侵害する可能性があることに気づき、そのための支援策を発表しました。
この Commitment、今は Customer Copyright Commitment (以降、CCC) と名前が変わっており、保護の対象も増えています。Azure OpenAI Service もその対象に含まれています。
この発表は、非常にインパクトがあったため、多くのお客様から「どうすればこの CCC の支援を受けられるのか？」という問い合わせを沢山いただいたようです。
その結果、以下のドキュメントが公開されています。
CCC が適用されるかどうかを考えるにあたって、最低限取り組んでいただきたい事項として整理されています。実際はよく読んでみると、ちゃんとテストしてありますか？という記載もあったりするので、やるべきことのリストとしてそのまま使うのはちょっと難しい部分があります。
この記事でもすべてのパターンを網羅的に説明することは難しいので、私なりの解釈を付け足して濁しておきたいと思います。
- 利用用途ごとにプロンプトで実施すべき事項はプロンプトに手を入れる
- コンテンツフィルターや、コンテンツ理解のための API を使用し、生成結果に対して取り扱いの注意が必要なものかどうかを仕分ける実装を入れておく
- 意図的に著作権を侵害する生成パターンをテストし、回答がシステムから利用者に戻らないことを確認する
- レッドチームを組織し、悪意を持って著作権侵害させられないかを試し、侵害するパターンが見つかった場合は回答がシステムから利用者に戻らないように実装を修正する
- 責任ある AI の原則に立ち、適切な用途であるかに立ち戻って要件の適切さを確認する（+αの解釈）
最後に厳しいことを付け加えておくと、CCC は金銭的なリスクを低減する施策ではありますが、「訴訟があった」という事実を帳消しにできるものではありません。発生確率をゼロにはできない部分ではありますが、「わが社として最大限の対応を行い、その最大限の対策とはこれこれこういうものである」と後から説明や検証で納得していただけるような備えをしていくことが重要だと思います。
おわりに
ずいぶんと文字の多い記事になってしまいましたが、いかがでしたか？
サービスの提供元に相談してみるというのは非常に有効な手段ですが、ほとんどのケースではどこかに責任分界点がありますので、自分たちで対処・検討すべきことを、提供元で対処・開示すべきことを適切に仕分けて、生成 AI 活用の阻害要因とならないようにプロジェクトを進めていきましょう。
Discussion