データ主体アクセス要求（DSAR）が届いた。連絡先の人物が、あなたが保有する自分のデータを開示するよう求めている。GDPRでは30日以内、CCPAでは45日以内に対応しなければならない。
従来のCRMであれば、そのリクエストはSQLクエリ1本とCSVエクスポートで完結する。しかしアウトバウンドワークフローを実行するAIシステムでは、データマップが最新の状態であっても4〜6時間の手作業が必要になることがある。最新でなければ、時計は容赦なく進み続ける。
これは法律の問題ではない。運用の問題だ。
AIシステムがDSARの対象範囲を広げる理由
従来のデータベースはレコードを行単位で保存する。識別子でクエリを実行し、行をエクスポートすれば完了だ。
AIシステムは少なくとも4か所に同時にデータを保存する。
- 構造化レコード — CRMフィールド、連絡先テーブル、アクティビティログ
- ベクトル埋め込み — 検索に使用される連絡先データのセマンティック表現
- コンテキストウィンドウログ — モデルに渡されたプロンプトと応答の完全な履歴
- ファインチューニングまたは評価データセット — モデルの動作をトレーニングまたはスコアリングするために使用された連絡先データ
DSARは法的にこれらすべてを対象とする。要求者はデータがどのストアに存在するかを気にしない。あなたが運用者であり、義務はあなたにある。
AIを活用した平均的なアウトバウンドワークフローは、連絡先がシステムに入った最初の1週間以内に4つのストアすべてに触れる。つまり、8日目に提出されたDSARに対応するには、すべてのレイヤーにわたってデータを特定・抽出・確認する必要がある。
運用上の3つの失敗ポイント
1. 不完全なデータマップ
ほとんどの運用者はCRMのスキーマを説明できる。しかし、AIパイプラインが書き込むすべてのダウンストリームストアを説明できる者は少ない。
ワークフローが連絡先レコードをエンリッチメントするとき、そのデータはどこに保存されるのか。モデルがリードをスコアリングするとき、そのスコアは保存されるのか。どこに？検索ステップがベクトルインデックスからコンテキストを取得するとき、その取得イベントはログに記録されるのか。
2分以内にこれらの質問に答えられないなら、データマップは不完全だ。不完全なデータマップは、DSARへの対応が遅延するか、不完全になるか、あるいはその両方を招く。GDPRにおける不完全な対応はコンプライアンス違反であり、部分点が認められる状況ではない。
2. インデックス化されていないベクトルストア
ベクトルデータベースはセマンティック類似検索に最適化されており、識別子による検索には向いていない。連絡先のメールアドレスや人物IDでベクトルストアを検索することは、ほとんどの実装においてネイティブな操作ではない。
そのため、DSARが届いたとき、ベクトルストアを担当するエンジニアはカスタムの抽出スクリプトを書かなければならない。多くの場合、締め切りに追われながら初めて書くことになる。実際、このステップだけでDSAR対応の総労働コストの2〜3時間を占める。
解決策はアーキテクチャレベルにある。書き込み時にすべてのベクトルレコードに識別子インデックス付きのメタデータを組み込むことだ。すべての埋め込みにcontact_idフィールドを追加するコストはインジェスト時にほぼゼロだ。抽出時には数時間を節約できる。
3. 誰もレビューしないコンテキストウィンドウログ
LLM APIの呼び出しコストは十分に安いため、ほとんどのチームはすべてをログに記録し、何もレビューしない。ログは存在する。しかしデータ主体ごとに整理されていない。
アウトバウンドシーケンス中にモデルに渡されるコンテキストウィンドウには、連絡先の氏名、会社、役職、推定されたインテントシグナル、過去のインタラクション履歴が含まれることがある。これはGDPRおよびCCPAの定義における個人データだ。
これらのログが連絡先レベルのインデックスを持たないフラットファイルや非構造化ブロブストアに保存されている場合、DSAR対応のために取得するには数百万行に及ぶログ全体のフルテキスト検索が必要になる。大規模になると、それは30分で終わる作業ではない。
運用上の答えはベクトルストアと同じだ。書き込み時にすべてのログエントリに連絡先識別子をタグ付けすること。後から改修するのではなく、最初から組み込むこと。
コンプライアンスの責任はモデルプロバイダーではなく運用者にある
OpenAI、Anthropic、その他すべてのモデルプロバイダーは、あなたがAPIを通じて送信する入力に対するデータコントローラーとしての地位を否定している。利用規約は明確だ。あなたがコントローラーであり、モデルに入力するデータを決定するのはあなたであり、その取り扱いに責任を負うのもあなただ。
これは法的な細則ではない。システム設計上の制約だ。
2025年、EUおよびカリフォルニア州の規制当局はAI固有のデータ取り扱いに関するガイダンスを積極的に発行している。方向性は一貫している。AIシステムを展開し、その目的を決定する主体がデータコントローラーであり、それは運用者だ。
DSARワークフローなしにAIシステムを構築することは、エラーハンドリングなしに構築するのと同じカテゴリのミスだ。問題が起きるまでは正常に動作し、問題が起きたときにはコストが集中し、時間的プレッシャーにさらされる。
機能するDSARワークフローの姿
本番環境に対応したAIシステムのDSARワークフローには5つのコンポーネントがある。
- パイプラインが書き込むすべてのストアを網羅した、バージョン管理された完全なデータマップ
- すべてのベクトル埋め込みに対する識別子インデックス付きメタデータ
- 保持ポリシーを持つ、連絡先タグ付きのコンテキストウィンドウログ
- 各ストアに対する文書化された抽出手順（必要になる前に少なくとも1回テスト済み）
- タイムスタンプと25日間の社内締め切りを持つ対応トラッカー（法的締め切りの前にバッファを確保）
いずれも複雑ではない。しかしすべてに意図的な設計が必要だ。最初から組み込んだチームはDSAR1件あたり約30分で対応できる。後から改修したチームは4〜6時間かかる。それも、何も欠けていないと仮定した場合の話だ。
AIシステムを構築または運用していて、DSARワークフローが文書化されていないなら、それが次に取り組むべき課題だ。