re:Invent 2024: AWSのGenerative AI監査・コンプライアンス加速
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerating auditing and compliance for generative AI on AWS (COP327)
この動画では、AWS上でのGenerative AIの監査とコンプライアンスについて、AWS Audit ManagerサービスチームのJohn FischerとAndrewが解説しています。Generative AIアプリケーションの責任ある構築・デプロイのためのフレームワークとして、Accuracy、Fair、Privacy、Resilience、Responsible、Safe、Secure、Sustainableの8つのドメインを提示し、Amazon BedrockのGuardrailsやAWS Control Tower、AWS Security Hubなどの具体的なツールを用いた実装方法を説明しています。特に、Foundation Modelプロバイダーとのデータ共有制限や、TLS 1.3による暗号化、KMSキーによるデータ保護など、セキュリティ面での具体的な対策にも深く言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Generative AIの監査とコンプライアンスの概要
AWS上でのGenerative AIの監査とコンプライアンスを加速するためのCOP 327 Cloud Ops 327へようこそ。クリッカーを手に取らせていただきます。本日は、いくつかの重要なトピックについてお話しします。Generative AIの監査とコンプライアンスの違いについて説明し、Generative AIアプリケーションの開発journey全体を通してコンプライアンスについて考えていきます。
AIの分野では、コンプライアンスの様相が異なることはご想像の通りです。多くの未知の要素があり、それは本日のセッション後も変わらないでしょう。Generative AIベースのアプリケーションの開発とデプロイが今まで以上に容易になった一方で、特にAIの責任ある使用に関する問題を考慮すると、それを適切に行うのは実際にはとても難しいのです。私たちは2つのことをご提供したいと思います：Generative AIアプリを責任を持って構築・デプロイするための考え方のフレームワークと、Generative AIアプリをデプロイする際に発生する主要な問題を解決するためのツールとフレームワークです。今回はAmazon BedrockとAWSエコシステムのツールを使用することを前提に進めますが、ハイレベルな考え方は任意のLLMアーキテクチャに適用できます。
ここで、従来のAI/MLワークロードとGenerative AIワークロードの監査とコンプライアンスの違いについて、Claudeに質問したビデオをご覧いただきます。Claudeは規制の状況と倫理的な考慮事項について情報を出力しています。一般的に、私たちはその回答に同意しますが、 これらについて私たち独自の見解もあり、本プレゼンテーションでそれもお伝えしていきます。
従来のAIとGenerative AIの違い
この新しいGenerative AIの世界における監査とコンプライアンスは、かなり異なります。Predictive AIは、その名の通り予測的です。このシステムは有限の入力と有限のデータセットで学習されており、その意味で非常に制約されています。出力として何が得られるかが分かっており、どのような結果が出るかについてよく理解されています。Generative AIは大きく異なります - Large Language Modelを扱うことになりますが、その基本的な特徴の1つは非決定的であることです。同じ入力でも毎回同じ出力が得られることは保証できません。
これまでは主にClassifierを扱ってきました。入力に基づいて物事を分類していました。現在、LLMは分類もできますが、新しいデータも生成します。LLM自体は非常に広範で、より非構造化されたデータ - 文字通り、インターネット全体を対象に学習されています。そのため、あまり制約されておらず、必ずしもあなたのシステムの専門家とは限りません。確かに、モデルをFine-tuningすることで、期待する結果により近づけることはできますが、精度は保証されません。
モデル自体は多くの異なるユースケースに対応しており、技術者向けではなく一般消費者向けのシステムを作り出しています。従来の予測AIは非常に技術的で、システムを通じて簡単に処理できる出力を生成します。一方、Generative AIはより詳細な出力を生成します。確かに制約をかけることはできますが、必ずしも技術的なシステムに直接つながるものではなく、結果を理解するためにビジネスオーナーやマネージャーに向けられるものです。
Generative AIではすべてがコンテキストに依存します。予測AIの場合、S3 bucketが暗号化されているかどうかを文字通り確認できるため、非常に簡単です。しかし、Generative AIの場合、入力、データ、出力にバイアスがないことを確認することは単純なチェックボックスの作業ではなく、はるかに難しい作業となります。これが、リスクとコンプライアンスの観点からGenerative AIについて我々が考えていることです。
AWS Best Practices for Generative AIフレームワークの紹介
このような発表は何度リハーサルしても、必ず何かを忘れてしまうものです。私は自分とAndrewの紹介を忘れていました。私はJohn Fischerで、AWSに約6年間在籍しています。そして、こちらにいる親しい同僚のAndrew Kaneは、Amazonに約10年間在籍しています。私はAWS Audit Managerサービスチームで働いています。Audit ManagerはAWSサービスの使用に関する証拠を収集し、さまざまなフレームワークにマッピングするサービスです。
これを取り上げる理由は、現在、Generative AIに関する規制の状況が比較的未開拓の領域だからです。一般的なAIを規制するNIST AI.100はありますが、Generative AI特有のものではありません。Generative AI特有のISO 42001もありますが、ガイダンスはやや高レベルで、現在、政府の規制も出始めています。EU AI Actがおそらく主要なものです。アメリカのホワイトハウスは規制を策定するための調査を実施しています。規制は一般的にコンプライアンスを意味し、コンプライアンスは一般的に監査を意味します。そしてAWS Audit Managerは証拠の収集を支援します。
このトーク全体を、私たちがAWSで構築したAWS Best Practices for Generative AIというフレームワークを中心に構成していきます。これはISO 42001やNIST AI.100ではありません。これは、より簡単に従えるベストプラクティスのフレームワークで、Generative AIのワークロードを構築する際に、コンプライアンスの観点から注目されそうな事項を体系化するのに役立ちます。完璧ですか？もちろんそうではありません。進化する状況の中で、私たちが考えるベストプラクティスに取り組むのに役立つでしょうか？私たちはそう信じています。このフレームワークは、Deloitte、私たち自身、そしてSecurity Assuranceと呼ばれる内部監査部門との協力で開発されました。
先ほど申し上げた通り、このフレームワークの概要は以下のようになっています。これらがドメインです：Accuracy（正確性）、Fair（公平性）、Privacy（プライバシー）、Resilience（回復力）、Responsible（責任）、Safe（安全性）、Secure（セキュリティ）、そしてSustainable（持続可能性）です。AWS Audit Managerを使用する方なら誰でもこれを確認できます。実際、Audit Managerに接続してこれをダウンロードするだけなら、費用は一切かかりません。それぞれについて詳しい説明があり、本日はこれらのコントロールのいくつかを見ていきます。
Generative AIアプリケーション開発の流れと考慮事項
基本的に、ここでは生成系AIアプリケーションの開発の流れを分析していきます。明らかにこの分野には大きな可能性があります - 効率性の向上、生産性の向上、カスタマーエクスペリエンスの向上が加速されていくでしょう。そしてこれは競争優位性をもたらすことになります。だからこそ皆さんがここにいて、Reinventや、Amazonが行っているAIに関する取り組みに興奮しているわけです。私たちは、これらを責任を持って導入できるようにサポートしています。
私がこれから説明する方法ですが - AmazonではPRという考え方があります。正確にはPR FAQと呼んでいますが、PRは基本的にプレスリリースのことです。Bedrockを含む新製品を導入する際には、必ずPRと呼ばれる1枚の紙に書かれたアイデアから始まります。そこで私も小さなPRを書いてみました。Amazon Web Servicesが「Amazon Ask」というものを導入する、というものです。実はAmazon Askは実在するアプリケーションではありません。ただし、これは私たちの同僚であるPascal Vogelが書いたブログのアーキテクチャに基づいています。このアーキテクチャに興味がある方は、実際にとても面白い内容で、少なくともチャットボット系のアプリケーションを始めるのに役立つと思います。
そして、PRが承認された後、開発者たちが作業を進め、見事にAmazon Askが誕生しました。非常にシンプルなもので、このセッションを通じて実際に操作してみる予定です。しかし、ここに至るまでに、PRが出て、アプリケーションを構築する前に、実際には検討すべき重要な事項がいくつかありました。Andrew、その点について説明してもらえますか？
はい、これらの質問は非常に重要です。私たちはお客様に最初にこれらについて考えていただくことを推奨しています。なぜなら、そうしないと後になって問題が発生する可能性があるからです。これらは最初から考える必要があります。なぜなら、後々の作業すべてに影響を与える可能性があるからです。もし遅すぎると、データ漏洩が発生した後や、監査コントロールを確認して不足していることに気づいた時には、すでに漏洩が起きていて組織内で問題が発生している状態です。そのため、私たちが提供しているこれらの様々な要素を確認し、確実に対応するようお勧めしています。最初の要素は、Johnが先ほど言及したISO 42001のような法律、規制、基準です。これらは良い出発点となる規制です。EU AI Actは、安全性、公平性、データプライバシー、EUの市民への影響、アプリケーションのリスクレベルに応じた組織の在り方などをカバーしようとする、非常に優れた包括的なフレームワークです。アプリケーションのリスクレベルに応じて、異なる事項や異なる領域での対策を考慮する必要があるかもしれません。これらの規制はすでに整備されており、私たちは、これがお客様だけの問題ではなく、EU、米国のホワイトハウスの法案、そして多くの米国の州でも独自のバリエーションが出てきていることを理解していただけるよう努めています。
Accuracyドメイン：正確性の重要性と課題
これらはすべて微妙なニュアンスの違いがあり、これらを把握していないと将来的に問題が発生する可能性があります。これらのAction Modelの開発を見ていく際、その構築、デプロイ、使用方法について責任を持って行う必要があります。なぜなら、最終的にデプロイするのはあなたであり、それらを適切に、そして不公平にならないように機能させる責任があなたにあるからです。
使用するモデルが優れていて、安全で、透明性があり、公平であることを確認するプロセスを整備する必要があります。また、時間の経過とともにアップデート、追跡、モニタリング、評価、アップグレードを行うプロセスも必要です。Amazon Bedrockの主要なモデルの1つであるClaudeのようなサードパーティのモデルを使用する場合、モデルの構築とトレーニングデータの保持は彼らが行っています。彼らがこのデータの公平性とバイアスをテストし、データの出所を確認できるモデルカードを提供します。しかし、独自のモデルを構築したり、ClaudeやBedrock上の他のモデルにFine-tuningを行ったりする場合、そのデータをモデルに追加することで、そのデータのバイアスや不公平性に対する責任者があなたになります。
監査証跡とモニタリングについては、これらを整備する必要があります。その大部分はHuman-in-the-loopプロセスを含みます - リクエスト、プロンプト、レスポンスをログに記録できます。しかし、誰がこれらのプロンプトとレスポンスを確認しているのでしょうか？誰がバイアスのある出力や問題のある出力を監視しているのでしょうか？一般的に、これらを確認し、記録し、分析し、メトリクスを確認し、問題が発生してモデルを見直し、データを追加し、変更を加える必要があるタイミングを判断するには、人間が必要です。
では、Generative AI Best Practice Frameworkの最初の柱である、ドメインについて説明しましょう：Accuracyです。 Amazon AskにCloudTrailデータの分析について質問してみましょう。質問したところ、CloudTrailデータの分析にはAmazon Athenaを使用できるという回答が返ってきました。これは確かに正しいのですが、私たちが実際に尋ねたことではありません。私たちはAmazon Askについて尋ねたのです。つまり、Accuracyの観点から見ると、Amazon Askアプリケーションは完全には正確ではない出力を生成したことになります。
Accuracy は非常に重要です。なぜなら、システムからの出力は正確でなければならないからです。正確でない場合、不正確な応答を返したことでシステムの完全性が疑問視されることになります。作業しているドメインに基づいて、監査やコンプライアンス、テスト記録を通じて、システムが正確であることを証明できなければなりません。データ自体に関しては、信頼できるソースからのものかどうかを判断する必要があります。ランダムなインターネットのウェブサイトからコピーしたものなのか、それとも十分にキュレーションされた信頼できるデータ企業からのものなのでしょうか？また、取得後にデータが改ざんされていないかどうかも重要です。組織内の誰かが親切心からデータの一部を気に入らないと思って変更していないでしょうか？
データが変更された場合、当初そのデータを提供したベンダーは、変更が加えられたことで公平性レベルに関する責任を負えないと言うでしょう。これは評判の低下、財務的損害、法的損害につながる可能性があります。もしユーザーがあなたのアプリケーションを信頼せず、その出力を信用しないのであれば、組織としてのあなたを信頼しなくなります。Athenaの例のように、本来の目的とは異なる使い方をしているという理由で、ユーザーはそのアプリケーションの利用を止めてしまうでしょう。ログメトリクスや運用データから出力を生成し、それを基に下流システムで判断を行う場合、トラフィックに基づいてファイアウォールのポートを閉じるような運用上の判断であれば問題ないかもしれません。しかし、もしそれが誰かの金融申請や法的判断に関する決定を行っているとしたらどうでしょうか？これらは人々に影響を与えるものであり、信頼性や正確性が欠如していれば、それを信用することはできません。
誤情報に関して言えば、Generative AIには常にハルシネーション（幻覚）が見られます。確かに素晴らしい機能ではありますが、情報と出力を確認して正確性を確保するための対策を講じない限り、あなたのシステムもその問題から逃れることはできません。Amazon Bedrockに組み込まれているものを含め、実際に使用できるツールや手法が存在します。
先ほど触れたブランドの評判、そして公平性とバイアスの軽減は非常に重要な考慮事項です。現実世界や特定のドメインを適切に反映していないデータを使用するシステムは、不公平であると見なされます。良質な出力を確保するためには、代表性のあるデータを持つ必要があります。そうでなければ、何らかの差別につながる可能性があります。
安全性とセキュリティは極めて重要な懸念事項です。タクシーサービスや軍事用ドローンなどの自律システムがGenerative AIを使用して自動制御される場合、これらのシステムは慎重に監視される必要があります。このプロセスで不正確な入力を受け取ると、危険な状況が発生する可能性があります。車が誤って人にぶつかったり、ドローンが地面に墜落したりする可能性があります。Large Language Modelを使用して出力を生成することで、問題が発生する可能性があるのです。特に自動車産業では、すでに多くの規制が存在します。単にLLMを車の駆動機構に接続するだけではダメで、既存の規制はすべて適用されます。
これは規制コンプライアンスの話につながります。ホワイトハウスが提案しているGenerative AIの法的フレームワークやEU AI Actは、既存の規制に取って代わるものではありません。Generative AIの出力が素晴らしく、すぐに使用できると考えるお客様もいますが、規制に反する場合は使用できません。例えば、チャットボットに金融アドバイスをさせることは、おそらく最善の選択とは言えません。顧客がそのアドバイスについて苦情を申し立て、人間が関与せず自動プロセスだけだったことが判明した場合、組織は通常、これらの裁判で敗訴します。
Fairドメイン：公平性の確保と評価
これらの懸念に対しては、最近リリースされたAmazon Bedrockのモデル評価機能を使用して対処できます。このシステムではBedrock内のモデルを検証し、私たちのニーズに基づいて適切な回答が得られているかを判断することができます。これは微妙なバランスが必要で、モデルの精度、レイテンシー、コスト、その他の要因を考慮して、ユースケースに最適なものを選択する必要があります。この評価機能では、作成したデータセットを取り込み、それらのデータセットに対してモデルの自動テストを実行することができます。このフレームワークを通じて、プロンプトやあらかじめ用意した応答をテストし、大規模なデータセット全体にわたってメトリクスを生成して分析することができます。
有害性の検出に関する小さな例をお見せしましょう。2行目に入力レコードのプロンプトが表示されており、モデルはそれが実際に何であるかについての応答を返します。この場合、スコアリングに基づいて、これは回答すべきではない質問だと判断しています。有害性チェックにより、モデルやアプリケーションが有害なコンテンツを適切に検出し、不適切な応答をブロックしているかを確認できます。もしこのような問題が通過し始めたら、モデルに何か問題が発生していることがわかり、再確認や再トレーニングの必要性を検討する時期だと判断できます。
先ほど言及したAudit Managerでは、これはフレームワークの一部となっています。Accuracy domainのControl 3.7は整合性チェックをカバーしています。説明では、データが改ざんされていないことを確認することについて説明しています。テスト情報を提供し、自動化された証拠収集がある場合は、それが実際にどのようなものかについて説明します。手動入力が必要な場合は、それらをどのように追跡すればよいかを正確に指示します。約束通り、フレームワークを提供しているわけです。このControl 3.7は、トレーニングデータの整合性監視に依存しており、BedrockとS3へのAPIコールを追跡します。
これらのBedrockとS3へのAPIコールは、トレーニングデータの保存場所が改ざんされていないこと、および一般ユーザーがアクセスできないことを確認するために使用されます。これがそのコントロールの一例です。
ここからFair domainに移りましょう。そして、私たちの良き友であるAmazon Askに戻り、次のプロンプトを入力します：「受付係がオフィスに到着し、熱心に仕事を始めた」というストーリーを続けてください。Amazon Askは次のように返答します：「受付係の彼女は朝早くオフィスに到着し、一日を始めることに意欲的でした。ドアを通って歩いていくと、いつものオフィスの心地よいざわめきが彼女を出迎えました」。このストーリーの何が問題でしょうか？私たちはただオフィスについてのストーリーを続けるように指示しただけで、受付係の性別については何も言及していません。では、受付係についてそのような仮定をすることは本当に公平だったのでしょうか？そしてその仮定を重ねて続けることは本当に公平だったのでしょうか？私はそうではないと思います。
Privacy、Resilience、Responsibleドメイン：データ保護と回復力の確保
Generative AIにおけるFairness（公平性）は、多くの異なる要素を考慮する必要があります。包括性、平等性、公平性、そして多様性を考慮しなければなりません。実世界を正確に反映していないものについては、もちろん、お客様によっては特定のユースケースの性質上、意図的にバイアスのかかったものを求める場合もあります。それは問題ありません。しかし、先ほど述べたように、サードパーティのモデルを使用する場合、彼らのトレーニングデータセットをコントロールすることはできません。Fine-tuningのデータセットは制御できますが、彼らのデータセットは制御できないのです。そのため、モデルカードやエンドユーザーライセンス契約、各種声明を確認し、このモデルを使用すべきかどうかを判断する必要があります。このモデルベンダーは正確で公平なモデルを提供していると考えられるでしょうか？私たちが使用している多くのモデルについては、間違いなくイエスです - それらは優れたモデルです。異なる分野や領域に特化している場合もありますが、モデルカードを見れば、それらが公平であることがわかります。しかし、それを確認し、確実にすることは私たちの責任です。
自社のFine-tuningトレーニングデータを持つ場合、バイアスを導入するのは自分自身であることを認識しておく価値があります。Amazon SageMaker Clarifyのようなツールを使用すれば、追加しようとしているデータのバイアスを検出し、そのデータセットの問題点を本質的に示してくれます。それを基に、より多くのデータを取得したり、データを変更したり、調整したりして、Fine-tuningを行う際により公平なデータセットを作ることができます。
このアセスメントについて特筆すべき点は、これが新しいタイプのものだということです。ビジネスアセスメントでもリスクアセスメントでもなく、これまでにない種類のものです。バイアスアセスメントなのです。そのため、実際の実施方法は異なります。なぜなら、組織がこれまでにこのような評価を行ったことがないからです。まず最初に、メトリクスを定義する必要があります。メトリクスがなければ、測定するものも、ベンチマークとするものもありません。時間の経過とともにどのように変化するかを見る必要があります。そこで定義するのですが、例えば単にDemographic Parity（人口統計的な公平性）だけを見たい場合もあるでしょう。他の要素を見たい場合もあるかもしれません。何を見るかは実際のところ重要ではなく、あなたのビジネスにとって意味のあるメトリクスであればよいのです。
公平性の測定方法とその基準を定義したら、プロセスを開始できます。これは循環的なプロセスです。最初に、データセットの不均衡を探します。何か違和感のあるもの、特定の層が過少代表または過剰代表されているところを探します。トレーニングプロセスを開始する前に、これらの要素がバランスよく分布しているかを確認できます。トレーニングを実施し、先ほど述べたようなモデル評価を行います。これには精度、適合率、正しく想起する能力の評価、そしてすべてのメトリクスの評価が含まれます。すべてが問題なく、素晴らしく、何も懸念がないと判断するか、あるいは何か対処が必要で更なる作業が必要だと判断します。
データと出力を確認し、異なるトレーニングや異なるモデル実行間で、出力に重要な差異がないかを検出しようとします。それができれば、視覚的な補助を活用できます。ROCカーブ下面積のようなもの、棒グラフ、その他視覚的に問題を確認できるものを使用します。これにより、データセットのこの部分が欠けているということが視覚的に確認でき、何か対策が必要だと判断する助けとなります。
明らかな対処法としては、トレーニングデータに偏りがある場合、それを再調整することができます。より多くのデータを収集したり、アンダーサンプリング、オーバーサンプリングを行ったり、データをより代表的なものにするためのさまざまな方法を試すことができます。モデル自体やフレームワーク自体でも対応できます。例えば、Adversarial Debiasingなどの手法を使用することもできます。これらを実施した後は、メトリクスの確認と再実行のサイクルに戻ります。 この新しいAuto Trainが完了したら、Bedrockフレームワークの評価などを使用してメトリクスをチェックし、次のバージョンをプロダクションに投入できるかどうかを判断します。これが私たちが物事を前に進める方法です。
次は、誰もが大好きなプライバシーについて話していきましょう。これについてはAndrewに任せたいと思います。というのも、ヨーロッパでは、 GDPRの影響でより重要な問題となっているからです。私の出身地でもプライバシーは確実に重要なテーマであり、データガバナンスの重要な側面となっています。 これがなければ、システムは適切に機能しません。
私たちは、個人の医療記録や金融記録といったプライベート情報が他の場所に流出したり、他者がアクセスできないようにする必要があります。モデルがアクセスできないようにし、単純なクエリで誤って他人に渡されることがないようにしなければなりません。個人情報が満載の素晴らしいデータセットがあってそれでモデルを学習させた場合、私たちがいつも言っているのは、モデルに入っている情報は、巧妙に作られたプロンプトで抽出できるということです。だからそもそも入れる必要があるのでしょうか？
なぜそれを行うのか、本当によく考える必要があります。意味のある場合もありますが、まったく意味をなさない場合もあります。例えば、病院が特定の症状を持つ患者の平均年齢を公表したいとします。それ自体は問題ありませんが、そのデータセットから特定の患者のデータを削除しても、平均値からその個人の情報が分からないようにするにはどうすればよいでしょうか？Differential Privacyと呼ばれる手法を使用することができます。これは数値自体にノイズを加える数学的な手法です。平均値を取ると概ね正しい値が得られますが、1〜2件のレコードを削除して再度平均を見ても、個人の情報を推測できないような方法で行われます。
Generative AIでも変わらない点があります。同意は依然として極めて重要です。これらのシステムが顧客との大量のQ&Aを生成したり、チャットボットやサポートデスクなどを運営したりする場合、誰かの代わりにレコードにアクセスする許可が与えられているという証拠を記録しておく必要があります。Generative AIシステムも、この同意が実際に存在することを確認できなければなりません。同意が存在しない場合、法的およびプライバシーの観点から、アクセスは拒否されるべきです。
ホワイトハウスや他の米国の州からプライバシーに関する更新情報が出ています。世界を見渡すと、約4分の1の国がこのような法令を施行しています。アプリケーションやワークロードを実行する場所によって、適用される法令が異なります。新しいバージョンや更新が定期的に行われるため、プライバシーに関する更新情報を常に把握しておく必要があります。違反すると多額の罰金が科される可能性があるためです。データ漏洩が発生する前に、エスカレーション手順を整備しておくことが重要です。なぜなら、いざという時に必要な対応手順がないと、時間を無駄にし、ニュースで取り上げられ、評判を落とすリスクがあるからです。
ここでは、実践的なテクニックをいくつかご紹介します。AWS CloudTrail Data LakeとAmazon S3のデータイベントを使用することで、誰がS3のオブジェクトを変更したり、追加したりしたのかを、シンプルなSQLクエリで確認することができます。これにより、リソース上またはリソース内で実行された操作（データプレーン操作やデータイベントとも呼ばれます）に関する情報が得られます。これらは通常、大量のアクティビティを伴うため、デフォルトではCloudTrailはデータイベントを記録しません。データイベントを記録するには、リソースタイプごとにデータイベントを指定する必要があります。
CloudTrailのイベント履歴は、デフォルトではデータイベントを記録しません。次に、EDSテーブルからリクエストパラメータを選択する、CloudTrail Lakeの別のクエリを見てみましょう。 ユーザーIDのARN、イベント名、その他のパラメータに対する条件が設定されています。結果には、バケット名やその他の情報が表示されています。これは、個人情報を保護するための適切な管理が行われているかを確認するために使用できる、実際の監査データです。
エスカレーション手順についてもう一つ重要な点は、それが「もしも」の問題ではなく、「いつ起きるか」の問題だということです。悪意のある人々は私たち善意の人々と同じくらい賢く、巧妙な方法であなたのデータにアクセスしようと常に試みています。最も単純なアプローチでさえ成功することがあるため、エスカレーション手順を準備しておくことが非常に重要です。最近、ある人とランチを共にした際、インシデント対応の机上演習の話を聞きました。CIOなども参加していましたが、監査人が「携帯電話が使えない状況で、データ漏洩が発生した場合、最初に誰に連絡するか」と尋ねたところ、誰も答えられなかったそうです。
AWS Systems Managerには、Incident Managerというサービスがあり、手順を確立するためのRunbookを設定することができます。これらの一部は自動化され、適切な人々に通知を送り、インフラチームにチケットを送信し、運用チームがインシデントの緩和と復旧を行うのを支援します。このあまり知られていないサービスには、インシデント処理、Runbookテンプレート、自動エンゲージメント、チケット発行など、多くの有用な機能が備わっているので、ぜひ皆さんにも確認していただきたいと思います。
Safe、Secureドメイン：Generative AIの安全性とセキュリティ
次は、Resilienceについて見ていきましょう。 システムを確実に稼働させ続けることは、クラウドの大きな約束の一つです。AIシステムもまたResilientである必要があります。これは当たり前のことのように聞こえますが、モデルやシステムは、攻撃、サービス停止、インフラの問題、スケーリングの問題など、あらゆる障害から適応・回復できなければなりません。そして、極めて短時間で使用可能な状態に戻れなければなりません。
Resilienceを実現する方法はいくつかあります。Resilience TestingやTabletop Testingは今でも存在し、うまく機能しています。しかしAWSでは、リージョン間でトラフィックを簡単に移動したり、障害をシミュレートしたり、パフォーマンスを測定するメトリクスを収集したり、システムを素早く復旧させるための回復計画を立てたりすることができます。これらはモデルにも適用する必要があります。Load Balancingは、EC2やその他のサービスタイプで常に行っていることですが、需要に応じて負荷を調整することでコスト効率を確保します。Bedrockのプロビジョニングモデルを1分間に25,000リクエストで実行するのは印象的かもしれませんが、午前4時には1分間に5リクエストしか必要ないかもしれません。モデルをスケールダウンし、実際のニーズに合ったサイズにすることが重要です。
バックアップとロールバックに関しては、モデルだけでなく、トレーニングパラメータやデータもバックアップする必要があります。データの複数のバージョンが必要です。なぜなら、6ヶ月後にバイアスが見つかるかもしれないからです。それは5ヶ月前の最新バージョンで導入されたのでしょうか？それとも3ヶ月前でしょうか？明日のアップデートかもしれません - 誰にもわかりません。そのため、バックアップの保持期間に関する異なるポリシーが、様々な要因に基づいて変更が必要になるかもしれません。Amazon Bedrockには、今年8月にリリースされた新機能があります。 これは、ネットワーク全体で地理的な範囲にわたってResiliencyを導入し、自国や地域で何か問題が発生した場合に、同じ地理的エリア内の別の場所にフェイルバックできるようにするというアイデアです。私はEUの出身なので、EUを例として使用しています。
このサービスには、APJ、EU、US向けのRegion Setがあります。これらはグループ化されています。ヨーロッパのものを見ると、FrankfurtとParisがあり、開発者の観点からは、デプロイメントとインストールに関して一緒に扱われます。もちろん、それぞれは個別のものですが、ユーザーの観点からは一つの大きなエンティティとして呼び出すことができます。
これら3つのリージョンそれぞれにClaudeモデルがデプロイされています。Frankfurt、Paris、Irelandのどこからでも呼び出すことができ、完璧に機能します。しかし現在では、Irelandに対してのみ呼び出すことができます。つまり、EU全体のモデルがある場合、 Irelandで呼び出すと、それら3つのリージョンのいずれかで処理されることが期待できます。容量があればおそらくIrelandで処理されますが、なければ推論リクエストをFrankfurtかParisに移動して処理しようとします。
このシステムが実際に行うことは、モデルが存在し、キャパシティがある場合はアイルランドに留まり、そうでない場合は、パリとフランクフルトのどちらが現時点で最もキャパシティがあるかを確認して、そちらに送信するということです。これはネットワークの問題やサービスの問題に対して効果的です。というのも、このような問題は稀にではありますが実際に発生するからです。このような観点から、サービスを継続的に稼働させるための回復力を備えています。また、特に負荷の高いワークロードで毎分多くのリクエストが発生している場合 - 例えば私やJohnやこの部屋にいる全員が突然大きなスパイクを引き起こしているような場合 - そのキャパシティを別の場所に振り分けて、フランクフルトやパリで処理することができます。
フランクフルト固有の呼び出しを使用するか、Geo全体の呼び出しを使用するかは、お客様が選択できます。すべてはお客様のコントロール下にあります。回復性の観点からお客様が承認しない限り、データを異なるリージョン間で送信することはありません。その他に利用できるツールとしては、おそらくご存じのAWS Configがあります。これは監査と評価を可能にし、リソースタイプを記録し、それらを時系列で追跡するサービスです。バックアップが予定通りに実行されていることを確認したり、トレーニングデータやモデルの保存場所を追跡したりするための多数のルールを使用できます。
Generative AIインフラストラクチャ、マルチAZデプロイメント、ロードバランサーアーキテクチャに対して、望ましい設定ルールを定義できます。これによりAIの可用性に影響を与える設定ミスを防ぐことができます。また、ルールの作成も非常に簡単です。すでに多くのルールが用意されており、前回確認した時点で400以上ありました。結局のところ、それぞれの状況が固有なものであるため、必ずしもすべてのルールがお客様の特定の状況に適用できるわけではありません。CloudFormation Guardを使用すれば、非常に簡単にルールを作成できます。 先ほどの画面でお見せしたルールは、DynamoDBのポイントインタイムリカバリが有効になっているかどうかをチェックするものでした。
Responsible AIについて話すとき、それは実は私たちが議論しているすべてのことに関係します。正確性、公平性、プライバシー、回復力、安全性、セキュリティ、持続可能性について。私の意見では、これらすべてが責任という点に集約されます。 特定のGenerative AIシステムを運用する人は誰でも、その結果に対して責任を負います。生成されるものすべてが彼らの責任であり、それを受け入れなければなりません。意図に関係なく、システムの出力は公平で、正確で、正しいものでなければならず、現地の法律に違反してはいけません。
責任という観点から、AIシステムは優れていて、倫理的であり続け、偏りがなく、代表性を持つ必要があります。これは簡単なことではありません。なぜなら、多くの責任があなたにかかってくるからです。実際に何が起きているのかの内部レビューなど、多くのことを行う必要があります。Generative AIシステムを持つことによるリスクの定義、IP漏洩への対策、ハルシネーションへの対策など。これらの機能については、今年のre:Inventで専用のセッションがあり、実際に行うべきことすべてをカバーしますが、やるべきことは本当にたくさんあります。
汎用的なAIシステムを導入すると、これまでには存在しなかった様々なリスクや攻撃の可能性が生まれます。今週取り上げた他のセクションを見ていただければ、コンプライアンスを維持するためのポイントがいくつか分かるはずです。
Responsible AIは多くの面でこのコンプライアンスという考え方を中心に据えています。Generative AIアプリケーションを構築し、製品を次のレベルに引き上げることは素晴らしいことです。しかし、だからといってHIPAAやその他の規制要件（ISO 27001、PCI、FedRAMPなど）への準拠が免除されるわけではありません。新しいリスク環境を考慮する必要があり、それは構築するAIアプリケーションの一部となります。
入力と出力、つまり学習データとシステムの出力について考慮しなければなりません。このようなフレームワークの様々な柱を見ていくと、AWS Audit Manager 自体がその支援をしてくれます。Audit Managerには32の標準フレームワークが用意されており、これらすべてに対応して証拠を収集し、監査人に直接渡せる証拠パッケージとして出力することで、この作業の一部を簡素化できます。
この作業を簡素化するもう一つの方法が、AWS Configのコンフォーマンスパックです。先ほど申し上げたように、AWS Config は、AWS全体でのリソースタイプの現状を記録するサービスです。また、これらの記録に対して実行できる多数のルールを持ち、各リソースがそれぞれのルールに準拠しているかどうかを確認できます。コンフォーマンスパックは、PCI、GDPR、NIST 853、HIPAAなどに準拠したConfigルールのリストです。Configコンフォーマンスパックを導入すれば、これらのフレームワークの1つ以上に対する準拠状況をチェックするルールセットを確実に手に入れることができます。
次は安全性について見ていきましょう。ここでAmazon Ask の例に戻ってみましょう。これは私のお気に入りの例の一つです。「ハエを退治する最良の方法は何か」と尋ねてみましょう。普通なら、私は「あの小さな電気の出るピンポンラケットみたいなものが一番楽しいよ」と言うところですが、それは私の個人的な意見です。私たちは、Generative AIアプリケーションが安全を保ち、ハエを含むあらゆる生物を傷つける方法を提供しないことを望んでいます。その回答は「申し訳ありませんが、ハエのような昆虫であっても、生き物を殺したり傷つけたりする方法はお勧めできません。ハエを害虫と見なす人もいますが、殺す以外にも人道的な対処方法があります」というものでした。これはかなり安全な回答です。確かにちょっと馬鹿げているかもしれませんが、安全です。プロンプトエンジニアリングを使えば、ハエを殺す方法よりもはるかに複雑で危険な情報を引き出すことができます。そのため、アプリケーションをそのような使用から確実に保護する必要があります。
安全性は、アプリケーションにおいて制限的なポリシーを設定し始める部分です。つまり、アプリケーションに望まない動作をさせないようにするということです。アプリケーションの安全性を確保し、私たちの評判に影響を与えることなく、また公衆やお客様に対して開示したくない情報を漏らすことのないよう、出力を適切にコントロールする必要があります。これらを安全に保ちながら、すべての機能を維持する方法が必要なのです。
Amazon Bedrockを扱う際、Amazon Bedrock Guardrailsという素晴らしいシステムがあります。その目的は、責任あるAIポリシーを支援するための安全対策を設けることです。これには多くの側面があります。例えば、アプリケーションで許容する有害コンテンツのしきい値を設定できます。なぜそんなことが必要かと思われるかもしれませんが、会話の中に不適切な表現や性的な不正行為を含めたくないからです。そういったものは入力にも出力にも望ましくありません。ただし、オンラインゲームのチャットストリームのように、多少の不適切な表現が許容される用途もあるかもしれません。少量なら問題ないでしょうが、生成はさせたくないかもしれません。このように、入出力の許容レベルを自由にコントロールできます。アプリケーションに関しては、個人情報を検出して完全にブロックすることができます。例えば、医療予約のために英国の国民保険番号を提供する必要がある場合、モデルへの入力は問題ありませんが、応答として返ってくる際には編集されるようにすることができます。
これにより、機密情報が出力として送り返されてログに記録されることを防ぎます。また、RAGソリューションにおけるハルシネーション（幻覚）を約75%削減し、モデル単体と比べて有害コンテンツを最大85%まで効果的に阻止できます。このような外部のGuardrailsを設けることで大きな違いが生まれます。そして重要なのは、モデルのコントロール自体とは異なり、これらは完全にユーザーのものだということです。ユーザーが設定し、構成し、実行でき、特定のニーズに合わせることができます。
では、どのように機能するのでしょうか？私たちはGuardrailsの適用についてやや慎重になっています。リクエストが入ってくると、まず定義された最初の5つの項目をチェックします。プロンプト攻撃から始まり、その動作方法を定義します。次の4つはユーザー側のものです。独自のコンテンツフィルター、金融アドバイスの提供など禁止トピックのリスト、個人情報の編集方法、特定の単語やフレーズのブロック方法など、すべてユーザーが決めることができます。これらのルールのいずれかが発動した場合、リクエストはブロックされ、LLMには到達しません。単純に応答を拒否します。すべてが問題なければ、入力をFoundation Modelに渡して応答を生成し、その後もう一度同じプロセスを実行します。なぜなら、悪意のある行為者がGuardrailsをすり抜けて、望ましくないものを含むプロンプトを送信する可能性があるからです。入力時にテストし、出力時にもテストを行い、さらにGroundingと呼ばれる新機能を使用します。これにより、RAG型アプリケーションを使用する際に、出力が正確で、現実的で、基礎となるソースデータと一致していることを確認できます。
GuardrailsはAmazon Bedrock内のすべてのモデルに適用できる優れた機能です。しかし、SageMakerや他の外部機関でGenerative AIを実行している場合でも、リクエストの前後でGuardsを使用することができます。Bedrockに接続する必要はなく、どこで実行しているモデルにも使用できます。昨年末に同僚が公開したブログでは、Amazon CloudWatchを使用してシステムを安全に定期的にモニタリングする方法について説明しています。かなり詳細な内容で、現在でも顧客から技術的な参考資料や確認すべき事項について質問された際に推奨しているものです。実際、このブログを読むことが私たちの出発点であり、とても良い参考資料となっています。
次はセキュリティについてお話しします。これは非常に重要なテーマです。 すべてのものが初日からセキュアでなければなりません。Andy Jassyが常々言っているように、セキュリティはJob Oneの前のJob Zeroなのです。他のすべてに優先されるべきものであり、これまで私たちが長年にわたって語ってきたネットワークセキュリティ、インフラストラクチャセキュリティ、サービスのセキュリティ確保、保存データの暗号化、転送中のデータの暗号化など、すべてが今でも適用されています。今週のre:Inventのセッションをご覧いただくと、Bedrockに関するこれらすべての内容、つまりサービス内でのデータの管理方法、転送中のデータの保護方法、データの使用・非使用の方法について説明しています。
AWSにおけるGenerative AIシステムの構築と利用において、セキュリティは極めて重要です。アプリケーションを構築してモデルを呼び出す際も、同様にセキュリティを確保する必要があります。レスポンスを受け取った後のセキュリティ境界も確実に保護しなければなりません。 Amazon Bedrockはレスポンスを保持しません - 私たちは保存しないのです。レスポンスは例えばS3バケットに保存されることになりますが、それがどのように使用されているでしょうか？通常のSIEMセキュリティシステムに送られて、誰でも見られるダッシュボードに表示されているのでしょうか？考える必要があります。非常に強力で価値のあるこのデータを手に入れた今、それをどうするのか？大切に扱い、セキュアに保護することはあなたの責任です。
Bedrockについて手短に説明させていただきます。お客様のデータは、Foundation Modelプロバイダーと共有されることは一切ありません。プロバイダーは、課金目的以外で、お客様のプロンプト、レスポンス、トレーニングデータ、使用状況を見ることはできません。私たちはBedrockにデータを保存しません。なぜなら、お客様のプロンプトやレスポンスを保持する必要がないからです。サポートに連絡して特定のプロンプトやレスポンスについて問い合わせられても、私たちにはその情報がありません。また、Bedrockを呼び出す際、先ほど説明した冗長性のための地域間連携を除いて、すべてがリージョン内に留まります。Dublinでベドロックを呼び出した場合、リクエスト、レスポンス処理、すべてのガードレールプロセスがDublin内に留まります。転送中のデータは常にTLS 1.2以上で暗号化されます。 TLS 1.2は使用しないでください。1.2をまだ廃止できない理由はありますが、私たちのAPIはすべてTLS 1.3で動作しているので、TLS 1.3を使用してください。
データストレージについては、会話履歴などの保存が必要な項目については、サーバーサイドでAWS KMSキーを使用して暗号化しています。Amazon Bedrock内でRAGソリューションを実装する場合、会話履歴を保存する必要がありますが、それも暗号化されます。お客様がKMSキーを提供される場合、そのキーで暗号化するため、私たちのアカウントに保存されていても、お客様のKMSキーで保護されているため私たちには使用できません。セキュリティとモニタリングに関しては、 先ほど述べたようにすべてがAWS CloudTrailで追跡され、Amazon Bedrockは20以上のコンプライアンス基準に対応しています。私たちの広範なコンプライアンスリストの中でまだ利用できない基準もいくつかありますが、HIPAA、SOC、PCIをお探しの場合、これらはすべて認証済みです。
Sustainableドメインとまとめ：持続可能性と今後の展望
セキュリティを強化するために、AWS Control Towerの使用を検討することができます。これはマルチアカウント環境のセットアップとガバナンスを簡素化するクラウドガバナンスサービスです。検出的、保護的、予防的なコントロールとガードレールを実装できます。Generative AIにおいては、LLMへのアクセスと使用を管理することが極めて重要です。Control Towerを使用することで、承認されたアカウントのみにトレーニングデータとモデルの作成・アクセスを制限し、暗号化を強制し、監査を強制し、最小権限を強制し、LLMデプロイメントの承認ワークフローを実装しながら、継続的なモニタリングと一元的な可視性を実現できます。
もう1つの重要な要素は、クラウドセキュリティ態勢管理ツールであるAWS Security Hubです。Security Hubでは問題点にフラグを立てることができ、AWSサービスだけでなく、サードパーティのソースからの問題も取り込むことができます。Security Hubと連携可能な多くのインテグレーションが用意されています。Security Hubは、リソースの使用状況を評価し、私たち全員に対して合格または不合格のステータスを判定することができます。
サステナビリティは、Amazonにとって全社的に、そしてAWSにとってもあらゆる面で非常に重要です。データセンターに関して言えば、私たちは今でも建設と拡張を続けていますが、以前と比べて同じ施設を建てるのに使用する鉄鋼やコンクリートの量を減らしています。最近のプレス報道では、データセンターの機械的・電気的フレームワークを、より効率的で回復力のあるものに変更し、リソースを最大限に活用している様子が取り上げられました。これには、私たちが開発・製造しているGravitonチップやTrainiumなどのCPUやGPUも含まれており、これらは消費電力あたりの処理能力を最大化することを主な目的として設計されています。
確かにGenerative AIは大量の電力を消費しますが、私たちは increasingly効率的なチップセットを使用することでサービスの効率化に取り組んでいます。また、モデルの再利用というアプローチも採用しています。お気づきかもしれませんが、現在では多くのサービスに文字起こし機能などのAIが組み込まれています。各サービスがそれぞれ独自の生成モデルを構築するのは持続可能ではないため、そのようなことは行っていません。ビジネスの観点から考えてみましょう - お客様がAmazon Bedrockを使用するのは、独自のモデルを構築すると時間とコストと電力の無駄になり、炭素排出量も増加するからです。既存のモデルのFine-tuning？もちろんです。でも、新しいモデルをゼロから構築すること？それは非効率的なので可能な限り避けています。私たちは、モデルの利用を民主化し、実現可能な場所には実装することを目指していますが、新機能のために必要な場合は新しいモデルの開発も行います。
AWSコンソールの課金セクションでアクセスできる興味深いツールとして、Customer Carbon Footprint Toolがあります。このツールを使用すると、サービスの使用状況に基づいてカーボンフットプリントを推定することができます。地域ごとの使用状況に基づいて予測されるカーボンフットプリントを表示し、炭素排出量の多い発生源を特定するためのインサイトを提供します。
この情報は、AIの責任ある使用を推進し、その状況を追跡するのに役立ちます。さらに、カーボンクレジットを取引できる地域では、利用可能なクレジットを追跡する良い方法となります。
このフレームワークでは、Accuracy（正確性）、Fair（公平性）、Privacy（プライバシー）、Resilience（回復力）、Responsible（責任）、Safe（安全性）、Secure（セキュリティ）、Sustainable（持続可能性）という8つのドメインすべてを網羅しています。これら8つのドメインには32の目標があり、その下に113のコントロールが設定されています。各コントロールは自動化、手動、またはその両方で実施できるため、情報の追跡方法について有用な指針となります。
主なポイントとして、従来型AIと Generative AIの違いを理解し、それぞれのコンプライアンス要件について説明しました。また、モデルの正確性、公平性、責任性、安全性を確保するための自動化やツールの活用方法や、プライバシー、回復力、持続可能性、セキュリティを確保するためのインフラ設計についても解説しました。さらに、Generative AIワークロードのコンプライアンスと監査を簡素化するための AWS ツールやサービスの活用方法についても説明しました。
学び続け、好奇心を持ち続けることが大切です。これらのリソースを振り返りたい場合は、右側にある AWS Generative AI ベストプラクティスフレームワークを無料でご利用いただけます。また、Amazon Bedrockのセキュリティとプライバシー、コンプライアンスワークショップ、責任あるAIシステムのコンプライアンスと保証に関する追加リソースもご用意しています。皆様、ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion