マルチプロバイダー LLM API 用のデータ保持ポリシー ルーターを構築する方法

マルチプロバイダー LLM ルーターは、最初にモデルを選択し、後で保持に関する質問をするべきではありません。サポート ワークフローが保持なしとしてタグ付けされている場合、ゲートウェイは、リクエストが境界を離れる前に、選択されたプロバイダー、エンドポイント、リージョン、アカウント設定、および機能の組み合わせがその約束を遵守できるかどうかを認識する必要があります。

障害モードは見落とされやすいものです。チームはステートレス チャットの完了から始まります。ルートは許容範囲内です。その後、誰かがファイルのアップロード、保存された会話履歴、Web グラウンディング、バッチ処理、またはベクター ストアを追加します。モデル名は同じままですが、データの動作は変わります。単純なレイテンシまたはコストのルーターは、ワークロードが許容するよりも長くコンテンツを保存するパスに、規制されたプロンプトまたは顧客契約に基づくプロンプトをサイレントに送信できます。

実際的な解決策は、LLM データ保持制御をモデル ルーティングの前に置くことです。ルーターはリクエストを分類し、正規の保持ポリシーと照合し、プロバイダーの機能をフィルタリングし、許可されていない機能をブロックし、決定の監査可能な証拠を発行する必要があります。

設計上の制約として扱うべき事実

プロバイダー データの処理は均一ではなく、プロバイダー名だけで取得されることはほとんどありません。保持を認識するルーターを設計する場合は、次の事実が重要です:

• OpenAI には、顧客がオプトインしない限り、API データはモデルのトレーニングや改善に使用されないことが記載されています。対象となる顧客は、承認後に組織またはプロジェクト レベルで修正された不正行為のモニタリングまたはゼロ データ保持を構成できます。
• OpenAI のゼロ データ保持は、応答とチャット完了の store パラメータを false として扱うなど、エンドポイントの動作を変更しますが、一部のエンドポイントと機能は引き続きアプリケーションの状態を保存でき、ゼロ データ保持の対象にはなりません。
• Anthropic は、Claude API のゼロ データ保持について、API 応答が返された後に顧客のプロンプトや応答を保存しないこととして文書化していますが、適用範囲はエンドポイントと機能の適格性によって異なります。
• Anthropic には、Claude の一部の機能または対象モデルには保持が必要な場合があり、特別に許可されていない限りゼロ データ保持では利用できない場合があると記載されています。
• Google Cloud 文書では、Gemini Enterprise Agent Platform のデータは事前の許可や指示なしに AI/ML モデルのトレーニングや微調整に使用されないことを示していますが、データ保持をゼロにするには特定のアクションが必要であり、一部の高度な機能では不可能な場合があります。
• Google Google Search を使用した Grounding のクラウド ドキュメントは、派生クエリとコンテキスト ログを最大 3 日間保存しますが、その機能に対してそのストレージを無効にすることはできません。データ保持ゼロが必要な場合は、Web Grounding for Enterprise を推奨します。
• Microsoft は、Azure によって販売される Azure ホスト型モデルは、OpenAI または他のモデル プロバイダーがプロンプトと入力を利用できるようにしておらず、許可や指示なしに基盤モデルのトレーニングに使用しないことを文書に記載しています。
• Microsoft は、Azure デプロイメント タイプが処理場所に影響を与えることを文書化しています。グローバル デプロイでは、モデルがデプロイされている任意の地域でプロンプトと応答を処理できますが、DataZone デプロイでは、選択したゾーンに処理が制限されます。保存されたデータは、顧客が指定した地域に残ります。
• Microsoft は、一部のステートフル Azure 機能が、ファイル、ベクター ストア、応答メッセージ履歴、アシスタント スレッド、バッチ処理入力、保存された補完などのデータを保存することを文書化しています。
• 承認された顧客が不正行為の監視を変更できること、および不正行為の監視データ ストレージがオフのときに Azure portal または CLI に ContentLogging=false を表示できることを記載した Microsoft ドキュメント。

これらはエッジの詳細ではありません。これらは、ルーターがエンドポイント、機能、アカウントの承認、およびリージョンを一緒に評価する必要があることを意味します。 「ZDR 有効」などのプロバイダ全体のラベルは、運用ポリシーとしては粗すぎます。

リファレンス アーキテクチャ

保持を意識した マルチモデル AI API ゲートウェイ には、リクエスト パスに 5 つのコンポーネントが必要です:

1. リクエスト分類子: データの機密性、テナント契約、リージョン要件、機能の使用状況、ファイル入力、ツールの使用、およびロギング権限を抽出します。
2. ポリシー リゾルバー: は、通常はテナント、プロジェクト、環境、API キー、およびワークロード メタデータからの正規の保持ポリシーにリクエストをマッピングします。
3. プロバイダー機能レジストリ: プロバイダー、エンドポイント、モデル、機能、リージョン、アカウント レベルの保持機能を日付の付いた証拠とともに記録します。
4. ポリシー エバリュエーター: 候補ルートをフィルタリングし、承認されたルートまたはポリシー拒否を理由コードとともに返します。
5. 監査エミッタ: は、選択されたルート、一致したポリシー、機能の仮定、リージョン、ストレージ フラグ、およびコンテンツ ログ モードを記録します。

このアーキテクチャでは、コスト、レイテンシ、フォールバックとは別に、保持と常駐の決定が行われます。コスト ルーティングは引き続き実行できますが、それは保持ポリシーを満たす一連のルート内でのみ発生します。

正規の保持ポリシーを定義する

プロバイダー中立のポリシー オブジェクトから始めます。あるプロバイダーの用語を社内契約にコピーしないでください。内部ポリシーでは、特定のプロバイダーがコントロールをどのように販売するかではなく、ワークロードで何が許可されるかを説明する必要があります。

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

制限の少ないワークロードの場合は、フィールドを欠落させるのではなく、明示的な緩和を使用します:

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

重要なフィールドは保存期間だけではありません。ステートフル機能、ファイル、グラウンディング、バッチ処理、ロギング モードはすべて、ルートが受け入れられるかどうかに影響します。

プロバイダー機能レジストリを構築する

機能レジストリはルーターの信頼できる情報源です。これは、プロバイダー アダプターを通じて分散されるのではなく、制御された構成として維持される必要があります。

役立つレコードには次のものが含まれます:

• provider: プロバイダーまたはクラウド プラットフォーム。
• account_scope: 設定が承認されている組織、プロジェクト、デプロイメント、サブスクリプション、またはテナント。
• endpoint: チャット、応答、メッセージ、バッチ、ファイル、アシスタント、埋め込み、グラウンディング、ベクター ストア、またはその他の API サーフェス。
• model_family およびオプションの model_id: モデルの適格性が異なる場合があるため。
• region_mode: グローバル、リージョン、データ ゾーン、顧客が指定した地域、またはプロバイダー固有の同等のもの。
• content_retention: 応答後のストレージなし、悪用監視の保持、アプリケーション状態の保持、固定期間の派生ログ、または不明。
• training_use: デフォルトで無効、オプトイン、または不明。
• human_review: 有効、変更、無効、または不明。
• stateful_storage: エンドポイントまたは機能が会話状態、ファイル、ベクター データ、補完、またはバッチ入力を保存するかどうか。
• feature_flags: グラウンディング、ファイル、ツール、キャッシュ、保存された出力、バッチ、アシスタント、または同等の機能。
• evidence: ソース文書名、URL、取得日、所有者レビュー日。

例:

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

機密性の高いワークロードについては、不明を拒否として扱うことをお勧めします。機能レコードに保持フィールド、リージョン モード、または機能の適格性が欠如している場合、厳格なポリシーを満たすべきではありません。

ルーティング前にリクエストを分類する

分類はモデルを選択する前に行う必要があります。優れた分類子は、静的メタデータとリクエスト検査を組み合わせます:

• API 主要なスコープ: テナント、チーム、環境、アプリケーション、ワークロード タイプ。
• 契約タグ: 保持なし、EU のみ、HIPAA のような管理、財務データ、顧客機密、または内部のみ。
• ペイロード タイプ: フリー テキスト、ドキュメント、画像、ファイル参照、埋め込み入力、ツール結果、または取得されたコンテキスト。
• 機能の使用: Web グラウンディング、ファイル アップロード、ベクター ストア、バッチ ジョブ、保存された会話履歴、ツール呼び出し、または応答ストレージ。
• ログ モード: 完全なコンテンツが許可される、編集されたコンテンツが許可される、メタデータのみ、またはアプリケーション ログ コンテンツが許可されない。
• リージョンのヒント: ユーザーの場所、テナントのデータの所在地、プロジェクト リージョン、またはデプロイメント リージョン。

機密データの自動検出だけに依存しないでください。 API キーまたはプロジェクトから宣言されたワークロード ポリシーをプライマリ ソースとして使用し、ペイロードにリスク シグナルが含まれる場合は分類子を使用してポリシーを強化します。

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

実際には、これは、カスタマー サポート キーをデフォルトで非保持に設定できる一方、内部実験キーではより広範なルーティングを許可できることを意味します。同じサポート キーがファイルのアップロードを試行する場合、承認されたファイル対応ルートが存在しない限り、有効なポリシーには file_storage_allowed=false を含める必要があります。

コストまたはレイテンシのルーティングの前にポリシーを評価する

エバリュエーターはフィルターとして機能する必要があります。ポリシー、要求機能、候補プロバイダー ルートを受け取ります。ポリシーを満たすルートのみを返します。

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

この順序は重要です。フォールバック ルーティングは、停止中に不適格なプロバイダーにジャンプしないでください。バッチ ルーティングでは、非保持リクエストを非同期ジョブ ストアに移動しないでください。ポリシーで禁止されている場合、派生ログを導入する機能をグラウンディングで有効にしてはいけません。

プラットフォームが OpenAI 互換のマルチモデル API を公開している場合は、互換性レイヤーを正直に保ちます。同じリクエスト本文が異なるプロバイダー ネイティブ機能にコンパイルされる可能性があります。ポリシー評価者は、元の SDK 形状だけでなく、コンパイルされたリクエストを検査する必要があります。

危険な機能の組み合わせを明示的にブロックする

最も安全な実装は、既知の高リスクの組み合わせに対して明示的な拒否ルールを作成することです。例:

• NO_RETENTION + FILE_UPLOAD: 特定のファイル エンドポイントとアカウント設定がポリシーで承認されていない限り拒否します。
• NO_RETENTION + VECTOR_STORE: ベクター ストアが独自に制御されたストレージ内にあり、プロバイダーが永続的なファイル状態を受信しない場合を除き、拒否します。
• NO_RETENTION + STORED_RESPONSE: 応答ストレージ フラグを強制的にオフにするか、エンドポイントがストレージを無効にできない場合は拒否します。
• EU_ONLY + GLOBAL_DEPLOYMENT: 許可された領域またはデータ ゾーン外で処理が発生する可能性がある場合は拒否します。
• NO_RETENTION + WEB_GROUNDING: グラウンディング機能がポリシーを超えて派生クエリまたはコンテキスト ログを保存する場合は拒否します。
• METADATA_ONLY_LOGGING + DEBUG_TRACE: アプリケーション ログおよびトレースからのプロンプトおよび完了コンテンツを抑制します。
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: 機能がアカウントの承認済み管理の下で特に適格でない限り、拒否します。

特定のエラーを返します。有用な拒否は、何が失敗したか、どの承認された代替案が存在するかを開発者に伝えます。

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

運用テレメトリから推論ログを分離する

保持ポリシーでは、ゲートウェイが強制的にブラインドになるべきではありません。通常、プロンプトや完了のコンテンツを保存しなくても、運用テレメトリを保持できます。

厳密なワークロードの場合は、次を保持します:

• リクエスト ID とトレース ID;
• テナント、プロジェクト、API キー、およびワークロード識別子;
• ポリシー ID とポリシー バージョン;
• プロバイダー、エンドポイント、モデル、デプロイメント、および使用されるリージョン;
• 要求および許可された機能フラグ;
• 決定理由コード;
• トークン数、レイテンシ、ステータス コード、コスト メタデータ;
• ポリシーで承認されている場合、重複排除のためのハッシュまたは安定したフィンガープリント。

抑制または編集:

• 生のプロンプト;
• 生の補完;
• アップロードされたファイルのコンテンツ;
• 顧客データを含むツール出力;
• 機密システムからコンテキストを取得しました;
• プロバイダーは、コンテンツを複製するペイロードをデバッグします。

これは、保持ルーティングが プロバイダー中立の LLM 可観測性 に接続する場所です。可観測性は、機密コンテンツを保持するシステムのセットを拡張することなく、何が起こったかを証明する必要があります。

あらゆる決定について監査証拠を提出

監査レコードでは、ルートが許可または拒否された理由を説明する必要があります。役立つために完全なコンテンツは必要ありません。

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

拒否されたリクエストの場合は、decision=deny と REGION_NOT_ALLOWED、GROUNDING_RETENTION_EXCEEDS_POLICY、STATEFUL_STORAGE_NOT_ALLOWED などの理由コードを使用して同じ構造を維持します。

保持ルールに契約テストを使用する

保持ルーティングには自動テストが必要です。重要なテストは、個々のプロバイダーの単体テストだけではありません。これらは、プロバイダーの組み合わせ全体でのポリシー動作のコントラクト テストです。

価値の高いテスト ケースには次のようなものがあります:

• 特定の承認されたファイル対応ルートが存在しない限り、非保持ポリシーとファイルのアップロードは拒否されます。
• EU のみのポリシーとグローバル展開は、モデルが他の方法で利用可能な場合でも拒否する必要があります。
• ゼロ保持ポリシーと保存された会話履歴は、サポートされている場合はストレージを拒否するか強制的にオフにする必要があります。
• 派生ログを保持するグラウンディング機能は、保持なしポリシーの下では拒否される必要があります。
• メタデータのみのログ ポリシーでは、トレース、ログ、エラー レポートからのプロンプトおよび完了コンテンツを抑制する必要があります。
• 保持期間が不明なプロバイダー機能レコードは、規制されたワークロードを拒否する必要があります。
• プロバイダーの停止後のフォールバックは、対象となるルート セット内に残る必要があります。
• バッチ エンドポイントがポリシーで許可されているよりも長く入力ファイルを保存する場合、バッチ処理は拒否する必要があります。

ドリフトもテストします。機能レコードが変更されると、変更が実稼働環境に反映される前に、システムはどのポリシーとルートが影響を受けるかを表示する必要があります。

運用上の所有権

難しい部分は、最初の評価子を作成することではありません。レジストリを最新の状態に保ち、文書化されていない例外を防止します。

次の所有者を割り当てます:

• プロバイダーのドキュメントのレビュー頻度;
• 変更された不正行為の監視やデータ保持ゼロなどのアカウント レベルの制御の承認ステータス;
• 地域展開インベントリ;
• ファイル、ベクター ストア、グラウンディング、バッチ、および保存された応答に対する機能の適格性;
• ポリシー例外ワークフロー;
• 監査記録の保持とアクセス制御;
• 開発者向けのエラー メッセージと承認された代替案。

すべての機能レコードにはレビュー日が必要です。有効期限が切れた場合、厳格なポリシーによって信頼が停止されるか、手動による承認が必要になります。プロバイダーのドキュメントと機能の動作は、静的な構成としては頻繁に変更されます。

トレードオフ

厳格な保持ルーターにより、利用可能なモデルの選択肢が減ります。一部のプレビュー モデル、ステートフル API、グラウンディング ツール、およびファイル ワークフローは、機密性の高いワークロードでは使用できなくなります。それが管理のポイントですが、製品チームには明確な代替案が必要です。

最速のデプロイがグローバルであるものの、ワークロードに特定の地域またはデータ ゾーンが必要な場合、リージョン ルーティングによりレイテンシやコストが増加する可能性があります。これをテレメトリで可視化すると、リクエストがより高価またはより遅いルートを使用した理由をチームが理解できるようになります。

ステートフル機能をブロックすると、チームが独自のメモリ層を構築するようになる可能性があります。これは正しいアーキテクチャかもしれませんが、それでもストレージ ポリシー、削除ワークフロー、暗号化、アクセス制御、監査ログが必要です。状態をプロバイダーの外に移動しても、ガバナンスの作業は削除されません。

プロンプトと完了の編集により機密データは保護されますが、デバッグと品質レビューが弱体化します。再現可能なリクエストのメタデータ、決定論的なテスト フィクスチャ、許可されたワークロードの制御されたサンプリング、およびポリシーで許可されている場合の文書化された非常事態アクセスを使用します。

推奨事項

• 後処理チェックとしてではなく、モデルのルーティング前に保持と常駐を強制します。
• プロバイダー、エンドポイント、機能、リージョン、アカウント承認レベルでの機能をモデル化します。
• 規制されたワークロードまたは顧客契約に拘束されたワークロードには、デフォルトで拒否の動作を使用します。
• ファイルのアップロード、ベクター ストア、Web グラウンディング、バッチ処理、および保存された会話履歴を別個のポリシーの次元として扱います。
• プロンプトおよび完了コンテンツを抑制する必要がある場合でも、運用テレメトリを維持します。
• ポリシー、ルート、機能の証拠、リージョン、ストレージ フラグ、理由コードを含む監査レコードを出力します。
• 高リスクの機能の組み合わせとフォールバック動作に関するコントラクト テストを作成します。

予測: 保持ルーティングが標準のゲートウェイ層になる

おそらく、保持ルーティングが、レート制限、予算管理、可観測性と同様に、エンタープライズ LLM プラットフォームの標準レイヤーになるという方向性が考えられます。プロバイダーがステートフル ツール、グラウンディング オプション、キャッシュ、ファイル、エージェント、マネージド メモリ機能を追加すると、安全なルートはモデル名よりも完全な実行パスに依存するようになります。

これは予測であり、現在の普遍的な要件ではありません。現在の要件はより単純です。チームが保持なし、地域処理なし、トレーニング使用なし、または人間によるレビューなしを約束する場合、ゲートウェイには、各リクエストがそれらの制約に従っていることを証明するのに十分なポリシー ロジックと証拠が必要です。

実用的な結論

プロバイダー選択の前にポリシー ゲートとして保持ルーターを構築します。正規の保持ポリシーを定義し、ルーティング前に各リクエストを分類し、日付付きのプロバイダー機能レジストリを維持し、安全でない組み合わせをデフォルトで拒否し、機密コンテンツを保持せずに監査証拠を記録します。

設計の目標は、常に安全なプロバイダーを見つけることではありません。目標は、特定のアカウントとリージョンで、特定のエンドポイントと機能セットを使用する特定のリクエストが送信前にポリシーを満たしていることを証明することです。

関連資料

• プロバイダー中立の LLM オブザーバビリティ設計