データ保持を意識した 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 開発者 API ZDR のドキュメントによると、有料サービスの不正行為を監視するログは通常、プロンプトと応答を一定期間保持する一方、承認された ZDR プロジェクトはログを記録する前にユーザー コンテンツと識別可能なメタデータを消去します。
- 機能固有のストレージ: Gemini のドキュメントには、Google 検索によるグラウンディングと Google マップによるグラウンディングは、プロンプト、コンテキスト情報、生成された出力を 30 日間保存し、これらの機能の使用時にそのストレージを無効にする方法はないと記載されています。
- 開発者所有のログ: Gemini API ログのドキュメントには、開発者所有の API ログは、課金が有効なプロジェクトではデフォルトで最大 55 日間保持でき、開発者は 7、14、または 28 日などの短い期間を選択できると記載されています。
- リスク管理: NIST の生成 AI プロファイルでは、AI が生成したコンテンツのプライバシー リスクを監視し、生成 AI ポリシーを既存のデータ、ソフトウェア、法律、コンプライアンス、およびリスク管理プロセスに結び付けることを推奨しています。
これらは、展開前に現在のベンダーのドキュメントと照合して確認する必要がある事実です。アーキテクチャの教訓は安定しています。保持は 1 つのプロバイダー レベルのブール値ではありません。
アーキテクチャ: リクエスト パス内のゲートウェイ ポリシー エンジン
保持対応ゲートウェイには 5 つのコア コンポーネントがあります:
- リクエスト感度分類子: ルーティング前にワークロードにラベルを付けます。
- プロバイダー機能マトリックス: では、プロバイダー、モデル、エンドポイント、リージョン、保持、ロギング、機能の動作について説明します。
- コードとしてのポリシー ルール: セキュリティ要件を実行時の許可、拒否、またはレビューの決定に変換します。
- フィーチャー ゲート レイヤー: 明示的に許可されていない限り、保持期間を変更するフィーチャーをブロックします。
- 監査および分析レイヤー: は、デフォルトで生のプロンプトを保存せずに有用なメタデータを記録します。
ゲートウェイは法的なニュアンスをすべて理解する必要はありません。法務、セキュリティ、コンプライアンス、プラットフォームの各チームが承認した決定を強制する必要があります。
ステップ 1: モデルを選択する前にリクエストの感度を分類する
小さな分類分類から始めます。開発者が使用できるほどシンプルであると同時に、ポリシーを推進するのに十分な表現力を備えている必要があります。
機密ラベルの例:
public: 公開ドキュメント、マーケティング コピー、公開 Web サイトのコンテンツ。internal: 機密性の低い非公開企業情報。confidential: 戦略、契約、顧客の状況、未発表の製品の詳細。customer_pii: 名前、メールアドレス、住所、アカウント識別子、サポート記録。regulated: 医療、財務、法律、教育、または管轄区域固有の保護されたデータ。source_code: 独自のコード、構成、アーキテクチャ ファイル。credentials: シークレット、トークン、パスワード、秘密鍵。ほとんどのシステムでは、これはルーティングではなくブロックする必要があります。
分類は複数の情報源から得られる場合があります:
X-Data-Class: customer_piiなどのアプリケーション提供のヘッダー。- テナント ポリシー。承認されたルールによってダウングレードされない限り、規制対象の顧客からのすべてのトラフィックが規制対象として扱われます。
- エンドポイント ポリシー。サポート チケットの要約はデフォルトで
customer_piiになります。 - 認証情報、明らかな PII、またはポリシー違反を検出するための軽量コンテンツ スキャン。
推奨事項: は自動検出に完全に依存するわけではありません。アプリケーションに目的のデータ クラスを宣言してから、スキャンを使用して明らかな不一致を検出するか、より安全なクラスを強制するように要求します。
ステップ 2: プロバイダー機能マトリックスを作成する
機能マトリックスは、ルーターが評価する信頼できる情報源です。本番構成と同様に、バージョン管理、レビュー、テストを行う必要があります。
フィールドの例:
{
"profile_id": "provider_x.chat.eu.zdr",
"provider": "provider_x",
"model": "model-large",
"api_family": "chat_completions",
"endpoint": "https://eu.example-provider.com/v1",
"region": "eu",
"processing_residency": ["eu"],
"storage_residency": ["eu"],
"zdr_eligible": true,
"zdr_contract_required": true,
"training_use": "not_used_for_training_on_paid_api",
"abuse_monitoring": "approved_modified_retention_required",
"developer_log_retention_days": 0,
"raw_prompt_logging_allowed": false,
"supported_features": {
"plain_chat": true,
"streaming": true,
"tool_calls": true,
"search_grounding": false,
"maps_grounding": false,
"file_upload": false,
"batch": 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: compliant_summarization をリクエストします。
推奨事項: マトリックスに契約上の前提条件を含めます。ベンダーがどこかで ZDR を提供しているというだけでは、ルートは ZDR によって承認されません。アカウント、プロジェクト、リージョン、エンドポイントが必要な条件を満たしている場合にのみ承認されます。
ステップ 3: コードとしてのポリシー ルールを作成する
ポリシー ルールは、セキュリティ チームとプラットフォーム チームが明示的で、テスト可能で、読み取り可能である必要があります。
疑似コードのルールの例:
deny if data_class == "credentials"
reason "credentials_must_not_be_sent_to_model"
allow only if data_class in ["regulated", "customer_pii"]
and profile.zdr_eligible == true
and profile.zdr_contract_required_satisfied == true
reason_on_failure "model_profile_not_zdr_eligible"
deny if residency_required == "eu"
and "eu" not in profile.processing_residency
reason "region_processing_not_supported"
deny if data_class in ["confidential", "customer_pii", "regulated"]
and request.raw_prompt_logging == true
reason "raw_prompt_logging_not_allowed"
deny if request.features.search_grounding == true
and policy.requires_zdr == true
and profile.feature_storage.search_grounding_days > 0
reason "grounding_requires_retained_content"
deny if fallback_profile.retention_level < primary_profile.retention_level
reason "fallback_weakens_retention_policy"これらのルールは、プロバイダーの選択前とフォールバック前に再度実行する必要があります。フォールバック ルーティングは、偶発的なポリシー ドリフトの一般的な原因です。プライマリ ルートは準拠している可能性がありますが、フォールバック ルートは単に利用可能なだけです。
ステップ 4: ツールと機能を維持率を変える機能として扱う
基本モデル単独のプロパティとして保持をモデル化しないでください。多くの場合、機能によってストレージ、ロギング、またはレビュー動作が変更されます。
各機能に独自のポリシー フラグを与えます:
- 検索グラウンディング: は、プロバイダーの条件に応じて、プロンプト、取得されたコンテキスト、生成された出力を保存する場合があります。
- 地図または場所の根拠: 場所固有のログまたは保持ルールが導入される場合があります。
- ファイルのアップロード: ファイルはプロンプトや応答とは別に保存される場合があります。
- コードの実行: は、一時ファイル、実行ログ、またはサンドボックス アーティファクトを作成する可能性があります。
- バッチ ジョブ: は、同期 API 呼び出しとは異なる保持、キューイング、および結果ストレージの動作を行う場合があります。
- 保存された会話: コンテンツは意図的に保持されるため、一般的なチャット オプションの背後に決して隠すべきではありません。
- 評価またはレビュー ダッシュボード: は、人間によるレビュー ワークフローや長期間存続するデータセットを作成する可能性があります。
推奨事項: テナント レベルとルート レベルで保持期間変更機能をオプトインします。開発者が grounding_search=true を有効にした場合、ゲートウェイは、アップストリームに送信する前に、機能ストレージ ルールに照らしてリクエストを再評価する必要があります。
ステップ 5: 生のプロンプトを保存せずに分析を保存する
保持を意識したルーティングによってプラットフォーム チームの目が見えなくなることがあってはなりません。コンテンツ ストレージを最小限に抑えながら、有用な AI 使用状況分析を維持できます。
安全なデフォルトのテレメトリ フィールド:
- テナント ID とプロジェクト ID
- ハッシュ化または内部 API キー ID
- モデル プロファイル ID とプロバイダ ID
- リクエストのタイムスタンプとリージョン
- 入力、出力、キャッシュされたトークン、および利用可能な場合の推論トークンの数
- レイテンシ、ステータス コード、再試行回数、フォールバック決定
- 見積もりと確定コスト
- データ分類ラベル
- ポリシーのバージョンとポリシーの決定理由
- 要求された機能フラグと許可される機能フラグ
機密トラフィックについては、デフォルトで生のプロンプトとモデル出力を保存しないようにします。デバッグにコンテンツが必要な場合は、制御されたワークフローを使用します:
- 顧客またはテナントの承認
- 狭い時間枠
- サンプリング制限
- 秘匿化パス
- 個別のアクセス制御
- 有効期限が短い
- 誰が有効にしたのか、なぜ有効にしたのかを示す監査ログ
これはトレードオフです。生のプロンプト ログをブロックすると、デバッグ、サポート、品質レビュー、不正行為の調査が困難になります。ただし、デフォルトですべてを保存すると、プライバシー、侵害、コンプライアンスの面がさらに大きくなります。
ステップ 6: 実用的な拒否理由を返す
一般的な 403 forbidden は開発者をイライラさせ、回避策を奨励します。機械が読める安定した理由と人間が読める説明を返します。
応答例:
{
"error": {
"type": "policy_denied",
"code": "grounding_requires_30_day_storage",
"message": "Search grounding is not allowed for workloads marked requires_zdr because this provider feature stores prompt, context, and output content.",
"request_id": "req_123",
"policy_version": "retention-policy-2026-08-01",
"allowed_actions": [
"disable_search_grounding",
"choose_profile:zdr_plain_chat",
"request_exception"
]
}
}有用な拒否コードは次のとおりです:
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 オプション、環境変数、プロバイダー コンソール、チーム固有の規則に分散されていた決定を一元化します。また、セキュリティ チームとプラットフォーム チームに、どのリクエストが許可されたか、どのポリシー バージョンが適用されたか、どのモデル プロファイルが選択されたか、およびその理由などの実用的な監査証跡を提供します。