AWS、RAGにリアルタイム権限確認を追加
- •Amazon QuickとBedrock Knowledge Basesが、検索時に文書のアクセス権を元システムで確認
- •保存済みACLとGoogle Drive APIによる確認を組み合わせ、言語モデルに渡す前に絞り込み
- •Mondelēz International、4地域の従業員3万5,000人超にAmazon Quickを導入
Amazon QuickとAmazon Bedrock Knowledge Basesは、検索拡張生成(外部文書を検索して回答に活用する方式)の回答に利用者ごとの文書アクセス権を反映するため、アクセス制御リスト(文書へのアクセスを許可する利用者やグループの一覧)をリアルタイムで確認します。AWSによると、Google Driveなど権限の基準となる元システムに検索時点で照会し、検索前の既存フィルタリングと併用します。権限のない人に機密の経営戦略、未公開の財務情報、人事情報をAIアシスタントが提示するリスクへの対策です。
従来は、定期または任意のコネクター同期で元システムの権限をインデックスにコピーし、保存したACLで検索結果を絞る方法が一般的でした。AWSはこの方式に3つの弱点があると指摘します。継承された権限、グループ所属、条件付きアクセス、拒否ルールなど、元システム固有の規則をAIシステムが正しく反映できない場合があること、同期の間にコピー済みの権限が古くなること、SharePointやGoogle Driveの変更がコネクターの更新より先に起きることです。たとえばConfluenceはグループ所属の変更時にイベントを通知しないため、権限を取り消された利用者が次の同期まで回答を通じて情報にアクセスできる可能性があります。
AWSの2段階方式では、Amazon Quickがまずベクトルインデックス(ベクトル形式で検索用データを保持する索引)から関連箇所を探し、保存済みACLで候補を絞ります。次に候補ごとに元システムへリアルタイムで照会します。Google Driveのナレッジベースでは、Quickが管理者提供のサービスアカウント認証情報を使ってGoogle Drive APIを呼び出し、利用者になり代わって個別のアクセストークンを生成します。権限の判定元はGoogle Driveのままで、利用者が閲覧できない文書は除外され、許可された箇所だけが大規模言語モデルに文脈として渡されます。インデックス内の全書類を毎回ライブAPIで確認すると大規模運用では費用がかかりすぎるため、最初の段階で候補を絞るとAWSは説明しています。
AWSによると、この仕組みは効率のためにキャッシュした権限を使いながら、現在のアクセス可否はライブ確認します。従業員の権限が取り消された場合、AIの回答への反映は数時間や数日後ではなく、数分以内になるはずだとしています。また、組織は問い合わせごとに元システム側で権限確認を行うことで、ナレッジベースの対象を広げ、同期頻度の管理を避けられると説明しています。Amazon Bedrockには、コンテンツフィルタリング用のGuardrails、幻覚を減らすための根拠確認、設定可能な安全ポリシーなどの追加機能もあります。
Mondelēz Internationalは、セキュリティ部門とコンプライアンス部門が、同僚に閲覧権限のある情報だけを見せることを優先していたと説明しました。同社によると、Amazon Quickのリアルタイムアクセス制御により、社内審査委員会は導入を進める判断に自信を持てました。同社は4地域で3万5,000人を超える従業員にAmazon Quickを導入しています。AWSは、顧客のコメントを提供した人物として、Mondelēz InternationalのM365イノベーション担当シニアスペシャリスト、ジャマール・ウィギンズ(Jamahl Wiggins)を挙げています。