PII匿名化パターン
個人を特定できる情報(PII)は、エンタープライズデータ全体に存在します。 サポートチケットには、顧客名と連絡先詳細が含まれます。 HRレコードには、従業員の個人情報が含まれます。 営業レコードには、見込み客データが含まれます。 PIIカテゴリには、名前、メールアドレス、電話番号、国民識別番号、健康データ、金融口座の詳細が含まれます。 Genieはこのデータを取得、処理、保存し、LLMに渡します。つまり、このデータは外部モデルによって処理されます。
これにより、多くの組織でコンプライアンス上の問題が生じます。 PIIはLLMに到達してもよいのでしょうか。 答えは、ユースケース、データの機密性、組織の規制上の義務によって異なります。 このページでは、PIIを管理できる3つのレイヤー、各レイヤーを適用するタイミング、およびレイヤーの実装方法について説明します。
PIIの3レイヤーモデル
GenieワークフローにおけるPII匿名化には、3つの介入ポイントがあります。 それぞれ異なるレイヤーで動作し、異なる目的を果たします。 適切なアプローチでは、データの機密性と特定のユースケース要件に応じて、1つ、2つ、または3つすべてのレイヤーを使用します。
- レイヤー1:コンテンツがナレッジベースに書き込まれる前に、PIIを削除または置換します。 ナレッジベースにPIIが含まれることはありません。 LLMは匿名化されたコンテンツを取得します。
- レイヤー2:スキルは外部システムからデータを取得し、結果をGenieに返す前に匿名化します。 LLMは匿名化されたデータを受け取り、元のPIIを見ることなくそれについて推論します。
- レイヤー3:LLMに対して、ユーザー入力または取得したデータからPIIを削除してから、スキルに渡すか保存するよう指示します。 これは最も柔軟なレイヤーですが、信頼性は最も低くなります。 決定論的な処理ではなく、LLMが指示に従うことに依存します。
レイヤー1:ナレッジベース取り込み前の匿名化
ナレッジベース取り込み前のレイヤー1匿名化ガイドラインについては、次のセクションを確認してください。
レイヤー1を使用するタイミング
次の場合はレイヤー1匿名化を使用します。
- 取り込むコンテンツに、Genieの取得タスクに不要なPIIが含まれている場合
- 元のPIIを見るべきでないユーザーがナレッジベースにアクセスする場合
- 規制要件により、LLMがアクセス可能なベクトルストアへのPII保存が禁止されている場合
例
- 顧客名と連絡先詳細を含むクローズ済みサポートチケットを取り込む場合。 チケットコンテンツを検索可能にしつつ、顧客PIIがナレッジベースに保存されないように、取り込み前に匿名化します。
- HRアシスタントのナレッジベース用にHRレコードを取り込む場合。 ポリシー取得のユースケースに不要な従業員の個人情報詳細を削除します。
レイヤー1の実装方法
レイヤー1匿名化は、コンテンツがナレッジベースに書き込まれる前に、ナレッジベース取り込みレシピで実行されます。
標準的な実装では、匿名化用のPythonスクリプトを使用するオンプレミスエージェントを使用します。 オンプレミスエージェントはネットワーク内で実行され、ソースシステムからの生コンテンツを処理し、匿名化変換を適用して、匿名化されたコンテンツをナレッジベース取り込みステップに渡します。
このレイヤーで一般的な匿名化手法には、次のものがあります。
- 固有表現の置換:検出された名前、メールアドレス、電話番号、その他の識別子を汎用プレースホルダーに置き換えます。
John Smith at [email protected] reported...はThe employee at [EMAIL_REDACTED] reported...になります - 一貫した仮名化:PIIを汎用プレースホルダーではなく一貫した仮名に置き換え、同一人物がドキュメント内または関連ドキュメント全体で常に同じ仮名にマッピングされるようにします。 これにより、実際の身元を公開せずに、特定の人物の履歴について推論する能力を維持できます。
Customer_Aは、取り込まれたすべてのチケット全体で同じ人物を一貫して指します。 - データ最小化:取得ユースケースに不要なPIIを含むフィールドまたはドキュメントセクションを削除します。 トラブルシューティング目的で取り込まれたサポートチケットには、顧客の請求先住所は必要ありません。 取り込み前にそのセクション全体を削除します。
このレイヤーでエンティティ検出と置換に一般的に使用されるPythonライブラリには、spaCy、Presidio、およびPII検出用に設計された同様のNLPツールがあります。
制限事項
レイヤー1匿名化は前処理ステップです。 スキル出力や会話内のユーザー自身のメッセージなど、他のチャネルを通じてGenieに到達するPIIには影響しません。 レイヤー1は、取り込まれたナレッジベースコンテンツ内のPIIのみを保護します。
レイヤー2:LLMに到達する前のスキル出力での匿名化
LLMに到達する前のスキル出力におけるレイヤー2匿名化ガイドラインについては、次のセクションを確認してください。
レイヤー2を使用するタイミング
次の場合はレイヤー2匿名化を使用します。
- スキルがPIIを含むデータを外部システムから取得する場合
- Genieがタスクを完了するために実際のPII値を必要とせず、匿名化または集計された情報のみを必要とする場合
- 組織のデータガバナンスポリシーにより、特定のPIIカテゴリをLLMに渡すことが禁止されている場合
例
- サポートチケット取得スキルが、顧客名、メール、電話番号を含むチケット詳細を取得する場合。 Genieが分析に必要とするのは、チケットの件名、説明、ステータスのみです。 Genieに返す前に、顧客の連絡先フィールドを匿名化します。
- HRデータスキルが、給与、健康保険プラン加入、個人住所を含む従業員レコードを取得する場合。 Genieが必要とするのは、従業員名と休暇残高のみです。 返す前に他のすべてのフィールドを除去します。
レイヤー2の実装方法
レイヤー2匿名化は、外部システムAPI呼び出しとReturn responseステップの間で、スキル内で実行されます。
外部システムからデータを取得し、出力がReturn responseステップにマッピングされる前に匿名化を適用するデータ変換ステップを追加します。 変換は次のように実装できます。
- フィールド除外:スキルの出力マッピングにPIIフィールドを含めません。 Genieが顧客のメールアドレスを必要としない場合は、返却スキーマに含めないでください。 これは厳密な意味での匿名化ではありませんが、同じ結果を実現します。 PIIがLLMに到達することはありません。
- Workatoレシピステップでの置換:レシピ内のFormulaステップまたはカスタムRuby/Python関数を使用して、特定のフィールド値を出力にマッピングする前に匿名化された同等値に置き換えます。
- オンプレミスエージェント処理:チケットの説明や通話メモなどの非構造化テキストフィールド内のPII検出など、より複雑な匿名化要件の場合は、Genieに返す前に、Python匿名化スクリプトを実行するオンプレミスエージェントを通じて出力をルーティングします。 これにはより多くのインフラストラクチャが必要ですが、PIIが完全には除外できないフリーテキストフィールドに現れるケースに対応できます。
出力スキーマの原則
レイヤー2匿名化で最も信頼性の高いアプローチは、Genieが必要としないPIIを除外するよう、最初からスキル出力スキーマを設計することです。 Genieがタスクに必要なものだけを返すことは、スキル設計の中核となる原則です。 この原則には、PII機密データに対するセキュリティ面があります。 出力スキーマから除外されたフィールドは、匿名化ではなく設計によって保護されます。
スキルに匿名化ロジックを追加する前に、Genieがそのフィールドを実際に必要とするかどうかを確認してください。 不要な場合は、出力スキーマから除外します。 匿名化は、Genieが情報を必要とするものの、匿名化された形式で受け取るべきフィールドに対してのみ適切なアプローチです。
制限事項
レイヤー2匿名化は、ユーザー自身が会話に持ち込むPIIには影響しません。 自分自身の個人情報、または同僚の連絡先詳細をチャットに入力するユーザーは、レイヤー2の制御を完全に回避します。 また、Genieがナレッジベースから取得するPIIにも影響しません。 これはレイヤー1で対応します。
レイヤー3:LLMレベルの匿名化
レイヤー3のLLMレベル匿名化ガイドラインについては、次のセクションを確認してください。
レイヤー3を使用するタイミング
次の場合はレイヤー3匿名化を使用します。
- スキルに渡す前または保存する前に、PIIを含む可能性があるユーザー提供コンテンツを処理するユースケースの場合
- Genieが応答する前に自身の出力からPIIを除去する必要がある場合。たとえば、入力に顧客データが含まれ、そのデータを応答にそのまま表示すべきでない要約ユースケースです
- 組織が、レイヤー1と2で処理されないPIIを捕捉する多層防御レイヤーを必要とする場合
例
- 顧客フィードバックを処理するGenie。 ユーザーが、顧客名と連絡先詳細を含む生のフィードバックテキストを貼り付けます。 Genieには、要約して保存する前にフィードバックを匿名化するよう指示します。
- 通話トランスクリプトを要約するGenie。 トランスクリプトには、顧客名と連絡先詳細が含まれます。 Genieには、ストレージスキルに渡す前に、要約内の識別可能な情報を汎用参照に置き換えるよう指示します。
レイヤー3の実装方法
レイヤー3匿名化は、特定のアクションの前にPIIを特定して置換するようGenieに指示するジョブ説明の指示を通じて実装されます。
PII HANDLING
Before passing any data to a skill or
storing any content, apply the following
anonymization rules:
- Replace customer names with "the customer"
or "Customer_[number]" if multiple customers
are involved
- Replace email addresses with [EMAIL_REDACTED]
- Replace phone numbers with [PHONE_REDACTED]
- Replace national ID numbers, account numbers,
and financial identifiers with [ID_REDACTED]
- Replace physical addresses with [ADDRESS_REDACTED]
Apply these replacements consistently within
a single processing task. If "John Smith"
is referred to later in the same content
as "Mr. Smith" or "John", apply the same
replacement to all references.
Do not apply anonymization to:
- The requesting user's own authenticated
identity from the skill trigger context
- Names of employees within your organization
when used in their professional capacityレイヤー3の制限事項
レイヤー3は、LLMが匿名化の指示に一貫して従うことに依存します。 LLMは確率的です。 PIIインスタンスを見落としたり、置換を一貫せずに適用したり、あいまいなコンテキストで識別子をPIIとして認識できなかったりすることがあります。
レイヤー3を、高機密PIIに対する唯一の匿名化制御にしてはいけません。 これは多層防御レイヤーであり、レイヤー1と2でカバーされないケースを捕捉するのに有用ですが、単独で機能するほど十分な信頼性はありません。
健康情報、金融口座データ、国民識別番号、GDPR、HIPAA、またはCCPAの対象データなどの規制対象データカテゴリについては、主要な匿名化メカニズムとしてレイヤー1またはレイヤー2の制御を適用します。 レイヤー3は補助レイヤーとして使用します。
ユースケースに適したレイヤーの選択
適切なレイヤーの組み合わせは、データの機密性、規制要件、およびワークフロー内でPIIが出現する場所によって異なります。
ユースケースに適したレイヤーを選択するには、次の表を使用してください。
| PIIソース | 推奨レイヤー | メモ |
|---|---|---|
| ドキュメントから取り込まれたナレッジベースコンテンツ | レイヤー1 | オンプレミスエージェントを使用して取り込み前に匿名化 |
| スキルによって返される構造化データ | レイヤー2 | 不要なPIIフィールドを出力スキーマから除外し、必要だが機密性の高いフィールドには置換を適用 |
| スキル出力内のフリーテキストフィールド(説明、メモ) | レイヤー2 | Genieに返す前に、オンプレミス匿名化スクリプトを通じてルーティング |
| 会話内でユーザーが提供したコンテンツ | レイヤー3 | LLM指示のみ。 コンテンツがスキルに渡される場合は、レイヤー2で補完 |
| Genie出力内のPII(要約、レポート) | レイヤー3 | 応答前に匿名化するようLLMに指示 |
| 規制対象の健康データまたは金融データ | レイヤー1と2 | 規制対象データカテゴリについては、レイヤー3のみに依存しないでください。 レイヤーの組み合わせを使用します。 |
プロダクションでの匿名化のテスト
PIIを処理するGenieをデプロイする前に、実際のPIIパターンを含む現実的なデータで匿名化制御をテストします。 テストPIIとして[CUSTOMER_NAME]を使用するテストでは、匿名化ロジックがDr. Sarah Williamsを正しく処理できるかどうかは明らかになりません。
各レイヤーを個別にテストします。
- レイヤー1:データを取り込み、ソースコンテンツ内の既知のPIIをナレッジベースで検索して、それが置換または削除されていることを確認します。
- レイヤー2:現実的なソースデータを使用してテストレシピ内でスキルを直接呼び出し、出力を検査して、Return responseステップの前にPIIフィールドが除外または置換されていることを確認します。
- レイヤー3:テストモードに切り替え、現実的なPIIパターンを含むコンテンツをGenieに提供し、そのコンテンツを要約または処理するよう依頼します。 応答とスキル入力を検査して、PIIが指示に従って処理されたことを確認します。
Last updated: