金融サービス企業がAmazon BedrockのClaude 3 Sonnetモデルとナレッジベースを組み合わせた顧客向けローン申請アシスタントを開発している。ナレッジベースのデータソースは顧客固有の財務データを含むS3バケットであり、OpenSearch Serverlessをベクターストアとして使用している。セキュリティ審査で以下の脆弱性が判明した： ①悪意のある入力によりシステムプロンプトの内容が引き出せる（プロンプトインジェクション） ②レスポンスに顧客のSSNや銀行口座番号が露出する可能性がある ③競合他社の金融サービスへの誘導が発生する ④政治・宗教トピックへの回答を試みる これら4つの脆弱性をすべて最小の追加インフラで解決するために最も適切なアプローチはどれか。
Amazon Bedrock Guardrailsは生成AIアプリケーションのセキュリティ制御を一元管理するBedrockネイティブのマネージドサービスであり、問題で挙げられた4つの脆弱性をすべて単一の設定で解決できる。 具体的な対応は以下の通り。 ①プロンプトインジェクション対策：コンテンツフィルターの「Prompt Attack」カテゴリを有効化することで、jailbreakingやシステムプロンプト抽出を試みる悪意ある入力を自動検出・ブロックする。 ②PII露出対策：機密情報フィルターにSSN・銀行口座番号を設定し、レスポンス中の該当文字列をANONYMIZE（マスキング）またはBLOCKで処理する。 ③競合他社誘導・政治・宗教対策：拒否トピックに自然言語で定義することで、これらのトピックに関する入力・出力を検出してブロックする。 Guardrailsはナレッジベース統合もサポートしており、RetrieveAndGenerate APIを通じたRAG結果に対しても同一ポリシーが適用される。 選択肢BのAWS WAFとComprehendの組み合わせは複数サービスの統合管理が必要で運用負荷が高く、LLM特有のプロンプトインジェクションへの対応精度が限定的。 選択肢CのAmazon Macieはデータストアの静的PII検出ツールであり、実行時のモデルレスポンスフィルタリングには対応していない。 選択肢DのSageMaker ProcessingとStep Functionsの構成はバッチ処理向けで、リアルタイム推論用途に適さずプロンプトインジェクション対策も不十分。