GDPRとサポートAI：カスタム識別子も対象です
サポートチームはAIを使って返答を作成し、チケットを処理しています。生産性は上がっています。そしてDPOが設定を確認します。
典型的な顧客メッセージには、名前、メールアドレス、注文IDが含まれています。名前とメールは個人データです。注文IDも個人データです。注文IDはサラ・ジョンソンをあなたの注文データベースと紐付けます。AIベンダーはこれをクロスリファレンスできます。学習データが流出した場合、IDによって再識別が可能になります。
法的根拠なしにこれらのデータを外部のAIベンダーに送信することはGDPR違反です。
注文IDが個人データである理由
GDPR第4条は個人データを広く定義しています。この用語は、識別された、または識別可能な自然人に関するあらゆる情報を対象とします。識別可能性には、識別子を参照した間接的な識別が含まれます。
ORD-4521893のような注文IDは間接的な識別子です。単独では、サラ・ジョンソンを特定しません。しかし、あなたの注文データベースと組み合わせると、特定できます。
GDPR第4条(5)は仮名化を規定しています。注文IDは仮名です。その背後にある人物を明らかにするためには、別の情報源が必要です。注文IDを外部のAIベンダーに送信する場合、個人データを共有していることになります。法的根拠とデータ処理契約が必要です。
ベンダーがあなたのデータベースを持っていない場合も、義務はなくなりません。個人データを共有した事実があります。GDPRは適用されます。
標準的な匿名化ツールの欠陥
サポートチームはGDPRコンプライアンスのためにPII検出を導入することが多くあります。標準的なツールは一般的なエンティティタイプを削除します。
標準的な検出では、顧客名、メールアドレス、電話番号、クレジットカード番号を識別します。これらは適切に処理されます。
標準的な検出では、ORD-XXXXXXX形式の注文IDを識別しません。口座番号、チケット参照番号、内部ユーザーID、サブスクリプションIDも検出できません。これが欠陥です。
結果はこのようになります：「Hi, I'm [PERSON_1] and my order ORD-4521893 hasn't arrived yet. Please email me at [EMAIL_1].」
注文IDはそのまま残っています。CRMにアクセスできる人なら誰でも、すぐにサラ・ジョンソンを見つけられます。匿名化は不完全です。これがコンプライアンス上の問題です。
Chrome拡張機能：ブラウザでの検出
Claude、ChatGPT、GeminiなどのAIツールを使うサポートエージェントはブラウザで作業します。Chrome拡張機能は、カスタム識別子がブラウザの外に出るのを防ぎます。
仕組みはこうです。エージェントがAIツールに顧客メッセージを貼り付けます。拡張機能はその送信先がAIプラットフォームであることを検出します。標準PIIを削除します。次にカスタムパターンを適用します。これらは、あなたの注文ID形式、口座番号形式、およびチームが使用するその他の識別子に一致します。エージェントは清潔なメッセージだけを見ます。元のデータはAIに届きません。
コンプライアンスチームがカスタムパターンを一度設定します。全エージェントに共有プリセットを配布します。エージェントが管理する必要はありません。メッセージを貼り付けるだけです。あとは拡張機能が処理します。
MCPサーバー：APIレイヤーでの検出
一部のプラットフォームはAPIを通じてAIを呼び出します。IntercomはAIを使って返答を作成します。ZendeskはAIを使って返答候補を提案します。MCPサーバーは、これらの設定においてAPIレイヤーで匿名化を追加します。
フローはこうなります。顧客メッセージがサポートプラットフォームに届きます。AIに到達する前に、MCPエンドポイントを通過します。エンドポイントが標準エンティティとカスタムエンティティを削除します。クリーンなメッセージがAIに送られます。AIが返答を返します。個人データは露出していません。エージェントはサポートプラットフォームで返答を確認・編集します。
エージェントは作業方法に変化を感じません。プロセスは同じです。カスタムエンティティはMCP設定で一度定義します。それ以降のすべてのAPI呼び出しで完全なエンティティ検出が機能します。
DPO向け実装チェックリスト
1. AIへのすべてのデータフローをマッピングする。
エージェントがAIを使用する場所をリストアップします。ブラウザツール、APIベースのツール、ファイルアップロードを含めます。
2. 顧客メッセージ内のすべての識別子タイプをリストアップする。
標準PII（名前、メール、電話番号）はデフォルト検出でカバーされます。カスタム識別子（注文ID、チケット参照番号、口座番号）にはカスタムパターンが必要です。
3. カスタムエンティティパターンを追加する。
各フォーマットを定義します。サンプルメッセージでテストします。チームプリセットに保存します。
4. 適切なレイヤーで導入する。
ブラウザベースのAI：共有プリセット付きChrome拡張機能を使用します。API統合のAI：MCPサーバーまたはAPIレベルの前処理を使用します。
5. ROPA（処理活動記録）を更新する。
サポートAIが自動匿名化を使用していることを記録します。対象となるカスタム識別子のタイプをリストアップします。これが技術的保護措置のドキュメントです。
6. 設定をテストする。
すべての識別子タイプを含むテストメッセージを送信します。何もAIに届かないことを確認します。ドキュメントテンプレートは法的コンプライアンスガイドを参照してください。
SaaSサポートチームの実例
あるSaaSサポートチームは社内AIプラットフォームを通じてClaudeを使用しています。顧客メッセージには、名前、メール、注文ID（ORD-XXXXXXX）、サブスクリプションID（SUB-XXXXXXXX）が含まれます。一部のフィーチャーフラグ名には内部識別子も含まれます。
GDPRレビュー前： すべてのコンテンツがAIに送られていました。注文IDとサブスクリプションIDも含まれていました。
カスタムエンティティ検出の有効化後：
ORD-XXXXXXXとSUB-XXXXXXXXがカスタムエンティティとして追加されました。Chrome拡張機能が共有チームプリセットで展開されました。DPOがテストを実施し、AI処理前にすべての識別子が削除されることを確認しました。
エージェントのワークフロー変更： なし。エージェントは同じように作業します。匿名化はバックグラウンドで実行されます。DPOは文書化された保護措置を記録しています。
まとめ
GDPRに準拠したサポートAIは、名前とメールを削除する以上のことをします。注文ID、口座番号、チケット参照番号は個人データです。標準ツールではこれらを検出できません。カスタムエンティティ設定がこのギャップを埋めます。
手順は簡単です。識別子のフォーマットを定義します。サンプルメッセージでテストします。チームに展開します。DPOであれば午後一時間で完了できます。その後は、すべての顧客データが外部AIシステムに到達する前に削除されます。コンプライアンスの効果は継続的に維持されます。