GDPRのデータレジデンシー管理に必要なのは約束ではなく証拠

EU地域を選ぶ機能は役立ちますが、個人データがその地域内にとどまる証明にはなりません。購入者は、稼働中のデータベース、オブジェクトストレージ、ログ、バックアップ、モデルプロバイダーへのリクエスト、テレメトリー、サポートセッションなど、すべてのコピーと、それにアクセスできるすべての人を追跡する必要があります。経路の一つでも約束した境界を越えるなら、データレジデンシーの主張には移転の仕組みと裏付けとなる証拠が必要です。

だからこそ、GDPRのデータレジデンシー管理は、強制可能な事実の連鎖として評価すべきです。管理画面のスクリーンショットが示すのは設定だけです。その設定の対象範囲、管理者が上書きできるかどうか、インシデント時に何が起こるかまでは示しません。調達部門は、重要な主張ごとに、契約上の約束、システムの説明、繰り返し実施できるテストを求めるべきです。

この記事では、AIアプリビルダーを評価する購入者向けに、実務的な基準を示します。特定の移転、法域、リスクプロファイルについて弁護士から受ける助言の代わりになるものではありません。

地域固定はすべてのデータ分類を定義しなければならない

地域固定が信頼できるのは、サプライヤーが地理的な境界と、その対象となるデータの両方を定義している場合だけです。「EUホスティング」は、主データベースがフランクフルトにある一方で、プロンプトは別の場所のモデルエンドポイントに送られ、ログはグローバル分析サービスに保存され、バックアップは地域をまたいで複製されることを意味するかもしれません。サプライヤーがデータフローを図示するまで、そのラベルから分かることはほとんどありません。

データ分類ごとに、許容される国または国の集合を示すデータ保存場所の別紙を求めてください。少なくとも、アプリケーション記録、アップロードファイル、プロンプトとモデル応答、埋め込み、シークレット、認証データ、ログ、メトリクス、トレース、クラッシュレポート、サポート添付ファイル、バックアップを対象にします。「EU」がEUのみを指すのか、より広いEEAを指すのか、あるいは他国を含むサプライヤー独自のグループなのかも明記すべきです。

管理策には明確な適用範囲が必要です。選んだ地域は、ビルダーのワークスペース、生成されたアプリケーションの本番ランタイム、あるいは両方に適用されるのでしょうか。プレビュー環境、ブランチデプロイ、一時的なビルドワーカー、キュー、キャッシュ、検索インデックス、コンテンツ配信キャッシュ、災害復旧コピーにも及ぶのでしょうか。アプリビルダーは完成したデータベースを一つの地域に置きつつ、ソースコード、プロンプト、ビルド出力は別の場所で処理できます。

例外は書面で特定するよう求めてください。購入者がデータ、目的、移転先、保持期間、保護措置を理解していれば、限定的な例外は管理できます。「運用データはグローバルに処理される場合がある」という定義のない条項は目的を損ないます。運用データには、ユーザー識別子、リクエストパス、プロンプトの断片、エラーペイロードが含まれることが多いためです。

最良の証拠は三層を組み合わせます。契約書または注文書では、約束された地域と変更手順を定めます。アーキテクチャ文書では、各データ分類をサービスと場所に対応付けます。API応答やデプロイ記録などの技術記録では、購入者自身のテナントでの設定を証明します。

たとえば、サプライヤーに次のような安定した形式のテナント記録を提出してもらいます。

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

名前は製品によって異なります。重要なのは、すべてを一つの緑色の「EU」バッジにまとめず、ワークスペース、ランタイム、バックアップ、サポートポリシーを区別していることです。誰がこれらの値を変更できるか、購入者が変更を検知できるか、移動後に既存のコピーがどうなるかを確認してください。

バックアップには独自のデータレジデンシーの約束が必要

バックアップには、明示的な保存場所、保持、削除、復元のポリシーが必要です。バックアップは、別のインフラ、アクセス経路、存続期間を持つ別個のコピーです。「保存時の顧客データ」の場所だけを約束するサプライヤーは、バックアップ保管庫、スナップショット、災害復旧レプリカを同じ境界に置くと約束していない可能性があります。

データベーススナップショット、オブジェクトのバージョン、複製ボリューム、設定バックアップ、プロバイダー管理の復旧コピーを含め、すべてのバックアップコピーの保存場所を確認してください。複製が一国の中にとどまるのか、EEA諸国間を移動するのか、第三国に渡るのかを明示させます。可用性を重視したアーキテクチャでは第2地域が正当化されることもありますが、それで第2の場所が無関係になるわけではありません。

保持に関する回答には、数値とイベントが必要です。通常のバックアップ保持期間、より長いアーカイブ層、期限切れの媒体が復元不能になるまでの時間、契約終了後のバックアップの扱いを入手してください。「ポリシーに従って削除」はテストできません。日次復旧ポイントが所定の期間で失効し、終了したテナントのバックアップは指定のスケジュールでアクセス不能になって期限切れになる、という内容ならテストできます。

論理削除と物理的な失効は異なります。削除済みの記録は、その復旧ポイントが失効するまで暗号化バックアップ内に残ることがあります。これは文書化された保持設計と両立しますが、通常の復元によって削除済みデータが知らないうちに再び有効にならない仕組みをサプライヤーが説明すべきです。成熟した復元手順では、削除マーカーを再適用するか、サービス復帰前に復元後の照合を求めます。

機微な詳細を取り除いた、直近の復元テストの証跡を一つ求めてください。元のバックアップ地域、復元先、関わった人またはサービスロール、承認記録、復元コピーの廃棄を特定できるものです。一般的な災害復旧ポリシーは、誰かがポリシーを書いたことしか証明しません。復元記録は、運用プロセスがコピーの移動先を把握していることを証明します。

暗号化によって保存場所の問題が消えるわけではありません。特に鍵と管理者ロールを分離するとリスクを下げられますが、第三国にあるバックアップは、依然として有効な仕組みと評価が必要な移転になり得ます。調達部門は、鍵の所有者、鍵の場所、復元権限、復旧中にプロバイダー担当者が平文を取得できるかを記録すべきです。

再処理者リストは実際の連鎖を説明しなければならない

有用な再処理者台帳は、各社を目的、データ分類、処理場所、移転根拠に結び付けます。ロゴや法的名称のリストは在庫にすぎず、購入者のデータがどのように動くかを説明していません。AIアプリビルダーは、クラウドホスティング、モデルプロバイダー、監視サービス、メール配信、認証、顧客サポート、不正利用監視に依存することが多いものです。役割ごとに見えるデータの範囲も異なります。

GDPR第28条は、処理者が別の処理者を起用する前に、管理者から事前の個別または包括的な書面による承認を得るよう求めています。包括的な承認の場合、処理者は追加または交代の予定を管理者に伝え、異議を唱える機会を与えなければなりません。調達部門はこの規則を運用要件に変えるべきです。安定した台帳、購入者が監視するチャネルを通じた事前通知、定められた通知期間、明記された異議申立て手続きです。

台帳は再処理者ごとに、次の5点を答えられるべきです。

• データを受領またはアクセスできる法的主体
• サービスと限定された処理目的
• 個人データの分類と影響を受ける製品機能
• 保存およびリモートアクセスが行われる国
• 適用される移転の仕組みと後続の再処理者経路

モデルサービスについて、「クラウドインフラ」を保存場所として受け入れてはいけません。プロンプトがモデルプロバイダーへ送られるか、プロバイダーが保持するか、人がレビューできるか、購入者がプロバイダーを無効化またはエンドポイントを選べるかを確認します。ビルダーが複数のモデルを使う場合、ルーティングロジックが重要です。プロジェクトで選択した地域は、ルーティング層が未承認のエンドポイントへ送るリクエストを制御できません。

変更通知は、変更が有効になる前に届かなければなりません。通知なしで変更可能なWebページでは、調達部門が継続的に手作業で監視し続けることになります。契約文言には、通知に含まれる情報と、正当な異議の後にどうなるかを記載すべきです。サプライヤーがサプライチェーンを一切変えないと約束する必要はありませんが、データの流れが始まる前に購入者が新しい移転を評価する時間は必要です。

デューデリジェンス中に、公開台帳、DPAの付属文書、現行のアーキテクチャまたはデータフロー図という三つを照合するよう求めてください。ベンダー移行後は、文書間で名称や場所がずれることがよくあります。不一致が自動的に管理策の失敗を意味するわけではありませんが、サプライヤーが解消するまでは購入者に信頼できる記録がないことを意味します。

DPAは設定を義務に変えるべき

データ処理契約には、購入したサービスに適用される処理指示、安全上の義務、削除条件、監査権、再処理者管理を記載すべきです。製品文書は機能を説明できますが、サプライヤーがこの購入者に対して何を約束したかを決めるのはDPAと注文文書です。

GDPR第28条第3項は、管理者と処理者の契約が対象事項と期間、性質と目的、個人データの種類、データ主体の分類、秘密保持、安全性への支援、削除または返却、適合性を示すために必要な情報などを扱うべきだと定めています。欧州データ保護会議のガイドライン07/2020も重要な注意を示しています。処理契約はGDPRを言い換えるだけでは足りず、要件をどう満たすかと必要な安全性の水準について、具体的な情報を含めるべきです。

この具体性はデータレジデンシーで特に重要です。購入者が選んだ地域、対象環境、承認されたリモートアクセス国、バックアップの場所、承認済み再処理者を示す別紙を添付します。合意した通知または変更手続きなしに、サプライヤーがそれらの場所を実質的に広げられないことを定めます。営業資料に「EU限定」とあっても、DPAがサプライヤーや関連会社の事業地ならどこでも処理できるとしているなら、両者が矛盾したときは契約が優先します。

役割の割り当ても確認してください。購入者の指示に従いサービス提供だけのために使う顧客コンテンツについて、サプライヤーは通常、処理者として行動します。請求、アカウントの安全性、不正防止、自らの法的義務については、別個の管理者の役割を主張することがあります。別の目的があるからといって即座に拒否する必要はありません。すべてのサービスデータを利用できる広い権利に隠さず、目的、データ分類、法的根拠、保持、共有を特定するよう求めてください。

AI学習には曖昧さのない条項が必要です。サプライヤーまたはモデルプロバイダーが、プロンプト、アプリケーションデータ、ソースコード、出力を汎用モデルの学習または改善に使うかを確認してください。使わないなら、その制限をDPAまたは優先する製品条件に書き、再処理者にも及ぼします。設定によって答えが変わるなら、その既定値、管理者、範囲、監査証跡を記録します。

監査条項は、マルチテナント施設への無制限なアクセスを求めずとも、使える証拠を生み出すべきです。独立した保証報告書、ペネトレーションテストの要約、セキュリティ文書、対象を絞った書面回答で、通常のレビューには対応できることがあります。それらで重大な懸念が解消しない場合や、インシデントで管理策に疑義が生じた場合、購入者は追加情報や比例した監査に進める道を残すべきです。

SCCが解決するのは移転の契約面だけ

標準契約条項は第46条に基づく移転手段になり得ますが、署名しただけで、すべての移転が適法かつ十分に保護されていることは証明できません。購入者は適切なモジュールを選び、付属文書を完成させ、後続の移転を図示し、移転先とデータに対して条項が実際に機能するか評価しなければなりません。

欧州委員会の2021年SCCには、当事者の役割に応じた四つのモジュールがあります。EEAの典型的な顧客がEEA外の処理者へデータを送る場合は、モジュール2を使うことがあります。処理者が第三国の再処理者へデータを送る場合は、モジュール3が必要になることがあります。正しい選択は、誰が輸出者か、誰が輸入者か、輸入者がその処理についてすでにGDPRの適用を受けるかによって変わります。すべての契約にモジュール2を貼り付けるのではなく、弁護士に連鎖を確認してもらうべきです。

完成した付属文書は証拠になります。そこには、当事者、データ主体、データの分類、機微なデータと保護措置、移転頻度、目的、保持期間、管轄監督機関、技術的・組織的措置、再処理者を記載します。空欄の付属文書、「すべての顧客データ」のような一般的な説明、後で詳細を埋めるという約束では、条項が実際のサービスから切り離されてしまいます。

EDPBの勧告01/2020は、六段階の手法を示しています。移転を把握し、移転手段を特定し、第三国の法令または慣行を評価し、必要に応じて追加的措置を採用し、正式な手順を完了し、適切な間隔で再評価する方法です。勧告では、第三国からのリモートアクセスも移転として扱います。保存場所の地図だけに注目する購入者が見落としやすい点です。

移転影響評価は、一般的な法務メモではなく、サービスに合わせるべきです。輸入者と移転先、影響を受けるデータと人、アクセス経路、適用法と慣行、政府アクセスのリスク、後続の移転、追加的措置を特定します。誰が評価を承認したか、どの変更が新たなレビューのきっかけになるかを記録してください。

暗号化が役立つのは、その設計がアクセスリスクに対応している場合だけです。移転先の国にいるサポート担当者やモデルエンドポイントがプロンプトを復号する必要があるなら、通信中の暗号化では、その受領者がデータを読むことを防げません。有用な追加的措置には、厳格なアクセス分離、受領者が再識別用データを持たない場合の仮名化、不透明なまま保てるワークロード向けの顧客管理鍵、アクセスログ、適法な範囲での異議申立てまたは通知義務などがあります。

十分性認定があれば、移転先に対する法的な経路が変わることはありますが、移転先を把握する必要や処理者を管理する必要はなくなりません。どの移転が十分性認定に基づき、どの移転がSCCや別の仕組みに基づくのかをサプライヤーに特定させてください。その答えは、サプライヤーが「GDPRに準拠している」と述べる包括的な一文ではなく、移転台帳に入れるべきです。

サポートアクセスは、担当者のいる場所で行われる処理

EEA外からのリモートサポートアクセスは、データベースがEU地域から一度も出なくても、担当者が個人データを閲覧できるならデータ移転です。サポートの場所、承認、セッションの証拠をデータレジデンシー管理として扱ってください。保存場所と人によるアクセス場所は、別の問いに答えるものです。

サプライヤーに、通常のサポートと特権的なエンジニアリングアクセスを分けるよう求めます。一次対応の担当者には、アカウントのメタデータは必要でも本番コンテンツまでは不要かもしれません。重大なインシデント時には、オンコールのエンジニアが一時的なアクセスを必要とすることがあります。管理策では、各役割に必要最小限のデータと最短の時間だけを与え、本番アクセスにはより強い承認を求めるべきです。

調達部門は、国のリストがない「世界中で時差対応するサポート」ではなく、特定されたアクセス場所または強制可能な地域ポリシーを求めるべきです。サプライヤーは、本番アクセスを取得できる従業員、関連会社、委託先、その勤務国、EEA外の各経路に対する移転手段を開示します。緊急アクセスで場所の制限を上書きできるなら、条件、承認者、期間、購入者への通知を文書化してください。

承認前または概念実証中に、サポートアクセスのテストを行います。

1. 契約済みのEU地域にテスト用テナントを作り、一意の合成顧客レコードを追加します。
2. 通常なら調査が必要なサポートケースを開きますが、レコードそのものをチケットには貼り付けません。
3. アクセスリクエスト、承認者、オペレーターの国、付与された役割、有効期限をサプライヤーに示してもらいます。
4. ログに機微なコンテンツをコピーせず、セッションログにテナント、操作、タイムスタンプ、理由が記録されることを確認します。
5. アクセスを取り消し、役割またはセッションからテナントへ到達できなくなった証拠を求めます。

デューデリジェンスのテストで新たな漏えいを作らないため、合成データを使います。期待する出力は小さな証跡セットです。チケット識別子、承認イベント、一時的な権限、セッション監査記録、失効イベントです。共有サービスで実地テストができない場合は、直近の伏せ字入りサンプルと、文書化した管理策に結び付く説明を求めてください。

緊急時の特別アクセスにも同じ水準の確認が必要です。サービス復旧のため通常の承認を省くことはあっても、本人確認、ログ、有効期限、事後レビューまで省いてはいけません。通常のデバッグに緊急ロールが使われないようサプライヤーがどう防ぐか、そうしたアクセスがあったことを購入者がどう知るかを確認してください。

既定で画面録画を要求しないでください。録画は、個人データや認証情報を含む新たな濃密なコピーを生み出す可能性があります。構造化された監査イベントは、より少ない露出で、よりよい証拠になることが多いものです。誰がどのテナントに、どの国から、どのチケットに基づき、どの役割で、どのくらいの時間アクセスし、どの分類の操作を行ったかを示せます。

証拠は変更やインシデント後も有効でなければならない

調達部門は、担当者、日付、範囲、更新のきっかけを付けて証拠を集めるべきです。営業レビューでの見栄えのよい回答は、サプライヤーがモデルプロバイダーを追加し、サポートチームを移し、バックアップ設計を変更し、新地域を開始すると古くなります。証拠管理は決定後の単なる保管作業ではなく、管理策の一部です。

承認記録では、管理策と証拠の対応表を使います。各項目に、管理上の主張、契約上の証拠、技術的な証拠、更新のきっかけという四つの欄を設けます。

1. 承認済みのワークスペースとランタイムの地域については、注文書と保存場所の別紙を、テナントの地域記録とデータフロー図とともに保管します。地域またはアーキテクチャの変更後に更新します。
2. バックアップの場所については、バックアップと削除のスケジュールを復元テスト記録と組み合わせます。バックアッププロバイダーまたは災害復旧の変更後に更新します。
3. 承認済みの再処理者連鎖については、DPAの承認条項をアーキテクチャと照合した台帳と組み合わせます。追加または交代の通知後にレビューします。
4. 第三国への移転については、SCCまたは十分性認定への参照を、移転台帳と評価に組み合わせます。移転先、法令、アクセスの変更後にレビューします。
5. サポートの場所については、サポートアクセスの別紙を承認、セッション、失効のログと組み合わせます。サポート対象国または役割の変更後に更新します。

各行には双方の担当者を割り当てます。サプライヤー側の担当者は、変更と証拠の依頼に答えます。購入者側の担当者は、通知にプライバシー、セキュリティ、エンジニアリング、法務のレビューが必要かを決めます。責任を負うレビュー担当者のいない共有メールボックスは、運用上の管理策ではありません。

通知の基準を定義してください。サービス状態メールだけを送る新しい再処理者なら、プロンプトを受け取るモデルプロバイダーより軽いレビューで済むことがあります。新しいバックアップ国、サポート場所の拡大、学習利用の変更、契約済み地域の上書きがあれば、購入者の評価が終わるまで新しい機微なデプロイを止めるべきです。

インシデントの証拠は、データレジデンシーの境界が維持されたかを示すべきです。関連する地域設定、管理上の変更、サポートアクセス、エクスポートイベント、再処理者の関与を保存するよう、サプライヤーのインシデント手順に求めます。DPAでは通知義務と協力条件を定め、インシデント対応手順では、影響を受けたデータがどこに保存され、どこから閲覧されたかを答えられる記録を特定します。

認証はこの記録を支えることがありますが、サービス固有の回答に代わるものではありません。保証報告書がアクセス管理やバックアップ管理をテストしていても、あるテナントが購入した正確な地域には何も触れていないことがあります。報告書の範囲と例外を管理策の行に対応付け、残る差を契約またはテナントの証拠で補ってください。

要件はテスト可能な回答を生むように書く

データレジデンシーの要件は、サプライヤーが「はい」「いいえ」「該当なし」で答え、名前の付いた証跡を添付できるように書いてください。漠然とした質問は漠然とした保証を招きます。「GDPRへの取り組みを説明してください」と問えば、洗練されたページが何枚も出て、承認の証拠はほとんど得られません。データ、場所、行動、証明に結び付いた要件なら、欠落がすぐ分かります。

ホスティングに関する実用的な要件は、次のようになります。「サプライヤーは、別紙Bに記載した移転を除き、本番の顧客コンテンツ、プロンプト、生成されたソースコード、認証記録を、別紙Aに列挙した国でのみ保存および処理するものとする」。別紙は文章と同じくらい重要です。別紙Aは承認された境界を定義します。別紙Bは、どこかに埋もれた一般的な権利に頼らず、当事者に例外の名前を挙げさせます。

別々の管理策には別々の要件を使ってください。次の質問は、RFPやセキュリティ付属文書で有効です。

• テナントで選んだ地域を継承しないすべてのサービス構成要素について、データ、国、目的、保持期間を挙げてください。
• 担当者が本番コンテンツにアクセスできるすべての国を特定し、そのアクセスに対する承認およびログの基準を添付してください。
• すべてのバックアップおよび災害復旧の場所、保持期間、削除イベント、許可される復元先を記載してください。
• 現行の再処理者台帳を提出し、プロンプト、ソースコード、アプリケーション記録、サポート添付ファイルを受け取れる主体を明示してください。
• 各第三国移転を十分性認定、SCCモジュール、その他の依拠する仕組みに対応付け、評価の担当者とレビュー日を示してください。

アーキテクチャが合理的に満たせない絶対的な表現は避けてください。「データは決してドイツから出ない」は、海外にいる購入者自身の管理者へのメール配信や、出張中の承認済みユーザーによるアプリケーション閲覧まで意図せず禁じるかもしれません。要件が対象にするのが、サプライヤー管理下の保存と処理、ネットワーク転送、購入者のユーザーによるアクセス、そのすべてのどれなのかを定義します。正確であれば、誰もが違反を特定できるため、保護は強くなります。

質問票を出す前に、必須の管理策と希望を分けてください。EU限定のサポートアクセスが必須なら、そのように明示し、矛盾する設計は却下します。希望であれば、移転手段と保護措置を伴う、文書化された第三国の経路を評価します。購入者がすべての質問を「重要」と呼びながら商談中に半分を免除すると、サプライヤーは信頼できる回答を返せません。

証拠の鮮度を求めてください。アーキテクチャ図と再処理者台帳には有効日を付けます。契約付属文書には、対象とするサービスバージョンまたは提供内容を特定します。運用サンプルは、廃止したシステムではなく現行の管理策から取得します。変更し得る証拠には失効日またはイベントに基づくレビューを設け、署名済みの恒久的な条件は改定されるまで記録に残します。

最後に、矛盾を明確にします。プレミアムプラン、任意設定、顧客の行動、将来の機能に依存する回答は、サプライヤーに特定させます。調達部門は前提条件を注文書に置き、実装の担当者に引き渡せます。設定に依存する管理策は、その設定を有効にする担当者を誰も知らなければ失敗します。

営業文句ではなく主張を評価する

購入者は、重要なデータ経路すべてに、拘束力のある約束、現行のシステム説明、テナント固有または直近の運用証拠という三種類の証明がそろっているかを確認することで、データレジデンシーの準備状況を評価できます。一層でも欠ければ、サプライヤーが「GDPR準拠」かを曖昧に議論するのでなく、具体的なフォローアップができます。

判断状態は四つあります。

• 確認済み: 証拠が一致し、購入するサービスを対象とし、更新の仕組みがあります。
• 条件付き承認: 限定的な不足に担当者、期限、代替管理策があります。
• 制限付き: 定義した低リスクのユースケースに合うデータだけをサービスで扱えます。
• 却下: 重要な移転またはアクセス経路が不明、無制限、または購入者の要件に反して契約上許可されています。

この方法は、調達でよくある二つの悪い習慣も防ぎます。一つは、欧州外にスタッフがいるだけで、彼らが購入者の環境へアクセスできない場合まで、グローバルなサプライヤーを拒否することです。もう一つは、モデルのルーティングやサポートアクセスを確認せずに「EUホスト」の製品を承認することです。事業の地理的な広がりは文脈です。実際のデータフローと強制可能な管理策が、リスクを決めます。

評価は、購入する正確なエディションと設定に適用してください。セキュリティ資料に書かれたエンタープライズ向けの管理策が、無料またはセルフサービスプランには存在しないことがあります。地域の選択はホストされた本番環境だけに適用され、プレビューやビルダーのワークスペースは既定の場所に従うかもしれません。承認済みの設計と、管理者が実際にデプロイできるものを一致させるため、前提条件、プランの制限、設定を注文書に記録します。

Koder.aiはさまざまな国のAWSインフラでアプリケーションを稼働できますが、購入者は、選んだ国、対象構成要素、アクセス経路が証跡セットに記載されるよう求めるべきです。製品の機能は話し合いの出発点であり、調達の証拠が結論を支えます。

個人データをサービスに入れる前に必要な管理策について、ロードマップ上の約束を受け入れてはいけません。ロードマップは将来の再評価を支えることはできます。機能が存在し、サプライヤーが拘束力を持って約束し、説明し、実証できるようになるまでは、ワークロードを制限するか、別の設計を選んでください。

承認記録は、宣伝文句ではなく残余リスクで終えるべきです。許容した国境を越えるアクセス、法的な経路、公開されるデータ、追加的措置、それを受け入れた人を記載します。その記録があれば、プライバシーチームは説明できる根拠を持ち、エンジニアは実際に運用できる境界を得られます。