金融aiアシスタントは初回質問からデータを制限すべき

ユーザーが手数料について説明を求めているとする。アシスタントを助けようと、ユーザーは自発的に口座のスクリーンショットを添付する。そこには氏名、残高、最近の取引、時には連絡先情報が含まれている。一般的な質問が、回答に必ずしも必要ではない情報の収集を引き起こしてしまうのだ。

プロダクトチームやカスタマーリレーション担当者にとって、最初の判断は、モデルの選択や回答の文章品質よりも、各リクエストが実際に必要とする情報は何か、という点にあるべきだ。取引明細全体を読み取れるアシスタントであっても、デフォルトでその明細を受け取るべきではない。

公開情報と個人情報の分離

情報処理・個人の権利に関する国家委員会（CNIL）は、データ最小化を「追求される目的に必要な範囲で適切かつ関連性があり、限定された」データと定義している。この原則をアシスタントに適用するには、提供されるサービスを正確に記述する必要がある。概念の説明、ヘルプページの検索、個人の状況の調査では、同じコンテキストは必要とされない。

架空のシナリオを考えてみよう。ユーザーが汎用アシスタントに、BYDFiに関する公開情報をどこで確認できるか尋ね、その後、個人の取引履歴のスクリーンショットを追加する。最初のリクエストは文書検索を呼び出すが、添付ファイルは個人情報を導入する。この場合、ユーザー体験はその文書を削除するよう提案し、適切な公式チャネルを通すべきタイミングを明確にすべきだ。このシナリオは設計上の選択を示しており、当該企業が使用するツールを前提とするものではない。

この分離は、最初の画面から明示できる。「サービスを理解する」という入口では、口座データなしの会話が始まり、「自分の案件についてサポートを受ける」という入口では、必要な情報と該当サービスへのアクセス条件が説明される。これにより、訪問者は書き始める前に、何を伝えられるかを知ることができる。

インターフェースでの収集を防止する

利用規約に埋もれた指示は、ファイルを添付する際にはほとんど役に立たない。したがって、注意喚起は関連するフィールドの近くに配置すべきだ。パスワード、接続コード、アクセスシークレットを一切送信しないこと、またリクエストに関係のない情報は削除すること。一般的な質問の場合、最初にファイル添付を無効にし、個人データなしで言い換えを提案することから始められる。

文書が必要な場合、特定の部分のみを要求することで収集範囲を限定できる。画面には、どの行が有用で、どの情報を隠してもよいかを説明すべきだ。自動チェックで特定のリスクのある内容を検出できるが、その誤りは予期しておく必要がある。番号が見落とされたり、無害なテキストがブロックされたりする可能性がある。代替手段へのアクセスは確保されなければならない。

2021年2月19日に公開されたチャットボットに関する助言の中で、CNILは特に、使用前の警告と、予期せず機微データが提供された場合の消去メカニズムを推奨している。これらの推奨事項はGDPRの意味での機微データカテゴリーに関するものだが、すべての金融データが法的にこのカテゴリーに該当するわけではない。とはいえ、口座情報は強力な保護を必要とする場合がある。

会話を超えたデータの追跡、そして公開前のテスト

表示される回答からデータを削除しても、それが処理から消えたことを証明するものではない。チームは、モデルに送信されたもの、技術ログに追加されたもの、サポートツールに保存されたもの、評価データセットに組み込まれたものを調査する必要がある。各コピーについて、目的、許可された人物、保存ルールを特定しなければならない。CNILは、保存期間はこの目的に依存することを指摘している。つまり、案内のための会話と、苦情対応の追跡に必要なやり取りでは、異なる期間が求められる可能性がある。

契約とプロバイダーの設定も具体的な確認に値する。誰がメッセージにアクセスできるのか？モデル改善のための再利用はあるか？削除は様々なシステムにどのように適用されるか？実際に使用されている構成について回答が文書化され、ツールや目的が変更されるたびに再検討されなければならない。

有用なレシピは、通常のリクエストから始め、そこに意図的に余分な情報を追加することだ。一般的な質問に連絡先情報を含めたり、範囲が広すぎるスクリーンショットを添付したり、第三者の文書を関連付けたりする。テストでは架空のデータを使用し、入力からログまでの完全な経路、そして予定されている削除を検証すべきだ。指標としては、不必要に要求された添付ファイル、送信前に回避されたデータ、フィルタリングの誤り、人間の担当者への誘導などを追跡できる。