データ保持を意識した AI API ルーティング: ゲートウェイで ZDR、常駐、およびログ ポリシーを適用
データ保持ポリシーに基づいて AI API トラフィックをルーティングするための実用的なゲートウェイ アーキテクチャ。リクエストの機密性を分類し、プロバイダーの保持動作をマッピングし、互換性のない機能をブロックし、安全な分析を保持し、あらゆる決定を監査します。
セキュリティ チームが知る必要があるのは、どのモデルが最も安価、最速、または最も機能的であるかだけではありません。特定のリクエストを特定のプロバイダー、エンドポイント、リージョン、機能、ロギング モードに法的および運用上送信できるかどうかを知る必要があります。
それは思っているよりも難しいことです。モデルは通常の社内チャットには受け入れられるかもしれませんが、顧客 PII には受け入れられません。プロバイダーは、1 つの API パスに対してデータ保持ゼロを提供する一方で、検索グラウンディング機能はプロンプトと出力を一定期間保存します。リージョンはストレージ常駐をサポートしている場合がありますが、期待した処理モードをサポートしていない場合があります。開発者所有のログは構成可能ですが、プロバイダーの不正行為監視ログは別のポリシーに従います。
実際的な解決策は、保持の決定を個々のアプリケーションからAI API ゲートウェイに移すことです。ゲートウェイはリクエストを分類し、プロバイダーの機能マトリックスに照らして評価し、互換性のない機能をブロックし、承認されたモデル プロファイルのみにルーティングし、デフォルトで生のプロンプトを保存せずにポリシー決定を記録する必要があります。
読者の問題: プロバイダーのプライバシー規約は実行時制御ではありません
ほとんどのチームは、どの AI プロバイダーが承認されているかを示すスプレッドシートまたはセキュリティ レビューから始めます。これは便利ですが、運用ルーティングには十分ではありません。
アプリケーションは実行時の選択を行います:
- このリクエストを処理するモデル ID はどれですか?
- リクエストでは、検索グラウンディング、ファイルのアップロード、コードの実行、バッチ処理、プロンプトのキャッシュ、または保存された会話を使用する必要がありますか?
- リクエストを処理する必要があるリージョンまたはエンドポイントはどれですか?
- システムはデバッグ用に生のプロンプトをログに記録できますか?
- フォールバック ルーティングは同じリクエストを別のプロバイダに送信できますか?
これらの各選択により、保持プロファイルが変更される可能性があります。プレーン チャット モードでは準拠していたリクエストは、開発者がグラウンディングまたは永続的な会話ストレージをオンにすると、非準拠になる可能性があります。信頼性を目的として設計されたフォールバック ルールにより、規制対象のデータが、データ保持ゼロ、データ常駐、または悪用監視制御が承認されていないプロバイダ パスに誤ってルーティングされる可能性があります。
推奨: 保持動作は、プロバイダー アカウントに添付されたドキュメントとしてではなく、第一級のルーティング制約として扱います。
ポリシーを設計する前にエンコードする事実
正確な条件は、プロバイダー、製品、契約、地域、エンドポイント、機能によって異なります。記憶や一度だけの復習に頼らないでください。ソース所有のマトリックスを構築し、条件が変更されたときにそれを更新します。
これが必要な理由については、現在のパブリック プロバイダーのドキュメントがいくつか説明されています。
- OpenAI: API データの常駐性はプロジェクト構成として文書化されており、地域リクエストには地域固有のドメイン プレフィックスが必要です。 OpenAI はまた、地域ごとにストレージ サポートと処理サポートを区別し、米国以外の地域の追加要件についても言及しています。 OpenAI は、米国以外の API データを保管するには、悪用監視制御と修正保存の修正の承認が必要であると述べています。
- Anthropic: Anthropic は、API 関連の商用ユースケースについてデータ保持ゼロを文書化していますが、一部の関連製品やコンプライアンス フィードには、アクティビティ フィードやリモート セッションのトランスクリプトの長期保持など、別個の保持モデルがあることに注意してください。
- Google Gemini: Gemini API 規約は、無料サービスと有料サービスを区別します。無料サービスの場合、Google は製品を改善するために送信されたコンテンツと生成された応答を使用することがあります。有料サービスについては、プロンプトとレスポンスは製品の改善には使用されないと Google は述べています。 Gemini Developer API ZDR のドキュメントには、有料サービスの不正行為を監視するログには通常、プロンプトと応答が限られた期間保持される一方、承認された ZDR プロジェクトではログの前にユーザー コンテンツと識別可能なメタデータが消去されると記載されています。
- 機能固有のストレージ: Gemini のドキュメントには、Grounding with Google Search と Grounding with Google Maps はプロンプト、コンテキスト情報、生成された出力を 30 日間保存し、これらの機能の使用時にそのストレージを無効にする方法はないと記載されています。
- 開発者所有のログ: Gemini API ログのドキュメントには、課金が有効なプロジェクトの場合、開発者所有の API ログはデフォルトで最大 55 日間保持され、開発者は 7 日、14 日、28 日などの短い期間を選択できると記載されています。
- リスク管理: NIST の生成 AI プロファイルでは、AI が生成したコンテンツのプライバシー リスクを監視し、生成 AI ポリシーを既存のデータ、ソフトウェア、法律、コンプライアンス、リスク管理プロセスに結び付けることを推奨しています。
これらは、展開前に現在のベンダーのドキュメントと照合して確認する必要がある事実です。アーキテクチャ上の教訓は安定しています。保持はプロバイダレベルの 1 つのブール値ではありません。
アーキテクチャ: リクエスト パス内のゲートウェイ ポリシー エンジン
保持対応ゲートウェイには 5 つのコア コンポーネントがあります。
<オル>ゲートウェイは、法的なニュアンスをすべて理解する必要はありません。法務、セキュリティ、コンプライアンス、プラットフォームの各チームが承認した決定を強制する必要があります。
ステップ 1: モデルを選択する前にリクエストの感度を分類する
小さな分類分類から始めます。開発者が使用できるほどシンプルであると同時に、ポリシーを推進するのに十分な表現力を備えている必要があります。
機密ラベルの例:
public: 公開ドキュメント、マーケティングコピー、公開ウェブサイトのコンテンツ。内部: 機密性の低い非公開の企業情報。機密: 戦略、契約、顧客の状況、未発表の製品の詳細。customer_pii: 名前、電子メール、住所、アカウント識別子、サポート記録。規制対象: 医療、金融、法律、教育、管轄区域固有の保護データ。source_code: 独自のコード、構成、アーキテクチャ ファイル。認証情報: シークレット、トークン、パスワード、秘密キー。ほとんどのシステムでは、これはルーティングではなくブロックする必要があります。
分類は複数のソースから得られる場合があります:
- アプリケーションが提供するヘッダー（
X-Data-Class: customer_piiなど）。 - テナント ポリシー。承認されたルールによってダウングレードされない限り、規制対象の顧客からのすべてのトラフィックが規制対象として扱われます。
- エンドポイント ポリシー。サポート チケットの要約がデフォルトで
customer_piiに設定されます。 - 認証情報、明らかな PII、またはポリシー違反を検出するための軽量コンテンツ スキャン
推奨事項: 自動検出に完全に依存しないでください。アプリケーションに目的のデータ クラスを宣言してから、スキャンを使用して明らかな不一致を検出するか、より安全なクラスを強制することを要求します。
ステップ 2: プロバイダーの機能マトリックスを作成する
機能マトリックスは、ルーターが評価する信頼できる情報源です。本番構成と同様に、バージョン管理、レビュー、テストを行う必要があります。
フィールドの例:
{
"profile_id": "provider_x.chat.eu.zdr",
"プロバイダー": "プロバイダー_x",
"モデル": "モデル-大",
"api_family": "chat_completions",
"エンドポイント": "https://eu.example-provider.com/v1",
"地域": "eu"、
"processing_residency": ["eu"],
"storage_residency": ["eu"],
"zdr_eligible": true、
"zdr_contract_required": true、
"training_use": "paid_api のトレーニングには使用されません",
"abuse_monitoring": "approved_modified_retention_required",
"developer_log_retention_days": 0、
"raw_prompt_logging_allowed": false、
"サポートされる機能": {
"plain_chat": true、
「ストリーミング」: true、
"tool_calls": true、
"search_grounding": false、
"maps_grounding": false、
"file_upload": false、
「バッチ」: false、
"stored_conversations": false
}、
"last_reviewed": "2026-08-01",
"source_refs": ["security-review-123", "vendor-doc-version-abc"]
}生のモデル ID ではなくモデル プロファイルを使用します。プロファイルは、モデル、プロバイダー、エンドポイント、リージョン、機能セット、および保持体制を組み合わせます。開発者は、model:fastest-large-model だけでなく、model_profile:compliance_summarization をリクエストします。
推奨事項: マトリックスに契約上の前提条件を含めます。ベンダーがどこかで ZDR を提供しているというだけでは、ルートは ZDR によって承認されません。アカウント、プロジェクト、リージョン、エンドポイントが必要な条件を満たしている場合にのみ承認されます。
ステップ 3: コードとしてのポリシー ルールを作成する
ポリシー ルールは、セキュリティ チームとプラットフォーム チームが明示的で、テスト可能で、読み取り可能である必要があります。
疑似コードでのルールの例:
deny if data_class == "credentials"
理由「認証情報をモデルに送信してはなりません」
data_class が ["regulated", "customer_pii"] の場合にのみ許可します
および profile.zdr_eligible == true
および profile.zdr_contract_required_satisfied == true
reason_on_failure「model_profile_not_zdr_eligible」
residency_required == "eu" の場合は拒否します
そして「eu」が profile.processing_residency にありません
理由「region_processing_not_supported」
["confidential"、"customer_pii"、"regulated"] の data_class の場合は拒否しますそして request.raw_prompt_logging == true
理由「raw_prompt_logging_not_allowed」
request.features.search_grounding == true の場合は拒否します
そしてpolicy.requires_zdr == true
および profile.feature_storage.search_grounding_days > 0
理由「grounding_requires_retained_content」
fallback_profile.retention_level < Primary_profile.retention_level の場合は拒否します
理由「fallback_weakens_retention_policy」これらのルールは、プロバイダーの選択前とフォールバック前に再度実行する必要があります。フォールバック ルーティングは、偶発的なポリシー ドリフトの一般的な原因です。プライマリ ルートは準拠している可能性がありますが、フォールバック ルートは単に利用可能なだけです。
ステップ 4: ツールと機能を保持期間を変更する機能として扱う
保持を基本モデル単独のプロパティとしてモデル化しないでください。多くの場合、機能によってストレージ、ロギング、またはレビュー動作が変更されます。
各機能に独自のポリシー フラグを指定します。
- 検索グラウンディング: プロバイダーの条件に応じて、プロンプト、取得したコンテキスト、生成された出力を保存する場合があります。
- 地図または場所の根拠: 場所固有のログまたは保持ルールが導入される場合があります。
- ファイルのアップロード: ファイルはプロンプトや応答とは別に保存される場合があります。
- コードの実行: 一時ファイル、実行ログ、またはサンドボックス アーティファクトが作成される場合があります。
- バッチ ジョブ: 同期 API 呼び出しとは、保持、キューイング、結果保存の動作が異なる場合があります。
- 保存された会話: コンテンツは意図的に保持され、一般的なチャット オプションの背後に隠れてはいけません。
- 評価またはレビュー ダッシュボード: 人間によるレビュー ワークフローや長期間存続するデータセットが作成される場合があります。
推奨事項: テナントおよびルート レベルで保持期間変更機能をオプトインします。開発者が grounding_search=true を有効にした場合、ゲートウェイはリクエストをアップストリームに送信する前に、機能ストレージ ルールに照らしてリクエストを再評価する必要があります。
ステップ 5: 生のプロンプトを保存せずに分析を保存する
保持を意識したルーティングによって、プラットフォーム チームの目が見えなくなることがあってはなりません。コンテンツ ストレージを最小限に抑えながら、有用なAI 使用状況分析を維持できます。
安全なデフォルトのテレメトリ フィールド:
- テナント ID とプロジェクト ID
- ハッシュ化された API キー ID または内部 API キー ID
- モデル プロファイル ID とプロバイダー ID
- タイムスタンプと地域をリクエストする
- 入力、出力、キャッシュされたトークン、および利用可能な場合の推論トークンの数
- レイテンシー、ステータス コード、再試行回数、フォールバックの決定
- 見積もりと確定コスト
- データ分類ラベル
- ポリシーのバージョンとポリシーの決定理由
- 要求された機能フラグと許可される機能フラグ
機密トラフィックについては、デフォルトで生のプロンプトとモデル出力を保存しないようにします。デバッグにコンテンツが必要な場合は、制御されたワークフローを使用します。
- 顧客またはテナントの承認
- 時間枠が狭い
- サンプリング制限
- 編集パス
- 個別のアクセス制御
- 有効期限が短い
- 誰がそれを有効にしたのか、そしてその理由を示す監査ログ
これはトレードオフです。生のプロンプト ログをブロックすると、デバッグ、サポート、品質レビュー、不正行為の調査が困難になります。ただし、デフォルトですべてを保存すると、プライバシー、侵害、コンプライアンスの面がさらに大きくなります。
ステップ 6: 実用的な拒否理由を返す
一般的な 403 禁止 は開発者をイライラさせ、回避策を奨励します。機械が読める安定した理由と人間が読める説明を返します。
応答例:
{
"エラー": {
"タイプ": "ポリシー拒否",
"コード": "grounding_requires_30_day_storage",
"message": "このプロバイダー機能はプロンプト、コンテキスト、および出力コンテンツを保存するため、requires_zdr とマークされたワークロードでは検索グラウンディングは許可されません。",
"request_id": "req_123",
"policy_version": "保持ポリシー-2026-08-01",
"許可されたアクション": [
"disable_search_grounding",
"choose_profile:zdr_plain_chat",
「リクエスト例外」
】
}
}有用な拒否コードには次のものがあります。
model_profile_not_zdr_eligibleregion_processing_not_supportedstorage_residency_not_supportedraw_prompt_logging_not_allowedfeature_requires_content_storagefallback_weakens_retention_policycontract_prerequisite_missingcredentials_detected
ステップ 7: 非表示のバイパスではなく、例外ワークフローを追加します
一部の例外は正当です: インシデント対応、顧客承認のデバッグ、移行テスト、一時的なプロバイダーの制限など。ゲートウェイは例外を永続的なシャドウ ポリシーにせずにサポートする必要があります。
各例外には以下を含める必要があります:
- 承認者の ID
- チームまたはテナントをリクエストする
- チケットまたはリスクレビューのリンク
- ビジネス上の正当な理由
- 許可されるモデルのプロファイルと機能
- 対象となるデータ クラス
- 有効期限
- 追加のロギング要件
推奨事項: 例外を通常のポリシーよりも狭くします。 disable_retention_policy=true などのグローバル スイッチは避けてください。 「テナント A、エンドポイント B のデバッグ プロンプト ロギングを 24 時間、編集とセキュリティ承認付きで許可する」などのスコープ指定されたオーバーライドを優先します。
運用チェックリスト
- バージョン管理されたプロバイダー機能マトリックスを作成する
- プロバイダの条件、契約の前提条件、保持のレビューのために所有者を割り当てます。
- アプリケーションは、データ クラス、常駐要件、要求された機能を宣言する必要があります。
- 機密トラフィックと規制されたトラフィックをデフォルトで生のプロンプト ロギングを行わないようにします。
- ツール、グラウンディング、ファイルアップロード、バッチ、保存された会話を個別の機能フラグとして表現します。
- プライマリ ルーティングの前とフォールバック ルーティングの前にポリシー チェックを実行します。
- ログ ポリシーのバージョン、モデル プロファイル、データ クラス、機能フラグ、拒否理由
- 分析メタデータをプロンプトおよび出力コンテンツから分離しておきます。
- テスト担当者は CI でケースを許可および拒否します。
- プロバイダが条件、リージョン、エンドポイント、機能を変更するたびに、ポリシーの変更を確認する
明示すべきトレードオフ
厳格なルーティングにより選択肢が減ります。 ZDR と常駐の制約により、最新モデル、最も低コストのルート、または機能が豊富なエンドポイントの使用が妨げられる場合があります。
リージョン ルーティングによりレイテンシやコストが増加する可能性があります。最も近い準拠リージョンが目的の処理モードをサポートしていない可能性や、別のプロバイダー パスが必要な場合があります。
機能ゲートは開発者を驚かせます。 開発者は検索を有効にしているだけだと思っているかもしれませんが、セキュリティでは新しい保持動作が見られます。文書化と拒否メッセージにより摩擦が軽減されます。
プロンプトの最小化によりデバッグが複雑になります。 チームには、すべてを保存せずに問題を調査するために、編集されたサンプル、テナント承認のデバッグ ウィンドウ、および強力なメタデータが必要です。
マトリックスにはメンテナンスが必要です。 プロバイダ規約が変更されます。新しいモデルが発売されます。地域が拡大します。機能はベータ版から実稼働版に移行します。マトリックスが古くなると、誤った信頼が生まれるため、マトリックスがないことよりも悪影響を及ぼします。
推奨とは何ですか? 予測とは何ですか?
推奨事項: ゲートウェイでの保存の強制、ルーティング前のリクエストの分類、プロバイダーの機能マトリックスの作成、ポリシーによる保存期間変更機能のブロック、デフォルトで生のプロンプト ロギングを回避し、すべてのポリシー決定をバージョン管理します。
予測: AI プラットフォーム チームは、プライバシーへの取り組みをモデル選択の一部として扱うようになるでしょう。 「どのモデルを使用すべきか?」と考えるのではなく、アプリケーションは、機能、コスト、レイテンシー、常駐、保持の制約を満たすモデル プロファイルを要求します。
予測: プロバイダー固有のプライバシー機能は今後も分岐していきます。要求と応答の形式のみを正規化するゲートウェイでは十分ではありません。制作チームもポリシーの正規化が必要になります。
実行可能な結論
データ保持を意識したルーティングは、別個のコンプライアンス ダッシュボードではありません。これはリクエスト パスに属します。
リクエスト感度分類、バージョン管理されたプロバイダー機能マトリックス、ZDR、常駐、生のロギング、フォールバック、保持期間変更機能のコードとしてのポリシー ルールの小さなセットの 3 つの成果物から始めます。次に、ゲートウェイが明確な拒否理由を返し、デフォルトで生のコンテンツを保存せずに分析を保存します。
この設計では、SDK オプション、環境変数、プロバイダー コンソール、チーム固有の規則に分散されていた決定を一元化します。また、セキュリティ チームとプラットフォーム チームに、どのリクエストが許可されたか、どのポリシー バージョンが適用されたか、どのモデル プロファイルが選択されたか、およびその理由など、実用的な監査証跡を提供します。