AIゲートウェイDPAチェックリスト: モデルルーティング購入者向けデータ処理の確認事項

AIゲートウェイDPAチェックリストは、ベンダーに法的ページがあることを確認するだけで終わるべきではありません。モデルルーティングの購入者にとって本当に重要なのは、署名済みのデータ処理契約が、アプリケーションが実際に使うルートと一致しているかどうかです。つまり、ゲートウェイログ、上流のモデルプロバイダー、サポートアクセス、地域ルーティング、保持制御、削除権、インシデント通知です。

統合モデルアクセス層、LLMゲートウェイDPA、またはAI APIデータ処理契約を承認する前に、このAIゲートウェイDPAチェックリストを使用してください。これは法的助言ではありません。DPAが技術的なルーティング動作と整合している必要があるプラットフォーム、セキュリティ、調達、法務チーム向けの実務的な証拠リストです。

Flatkeyは、このレビューに適しています。現在の公開サイトでは、flatkey.aiは1つのAPIキー、https://router.flatkey.ai/v1 にあるOpenAI互換のベースURL、使用量とコストの可視化、リクエストログ、モデルルーティング、および1つのダッシュボードを通じたプロバイダーアクセスを軸に位置づけられています。これらの製品ページは、時点の古いスクリーニング証拠として扱ってください。承認のためには、署名済みの注文書、DPA、アカウント設定、そして実際のワークロードを制御するサポート確認を添付してください。

より広い統制セットを構築している場合は、このレビューを GDPR AI APIゲートウェイチェックリスト、エンタープライズAI APIゲートウェイチェックリスト、AI APIデータ保持チェックリスト、および最新の Flatkeyの料金 と組み合わせてください。

AI Gateway DPA Checklist: ルートから始める

最初の間違いは、ベンダーを一般論としてレビューしてしまうことです。DPAは特定のルートに一致していなければなりません。サポート用チャットボット、バッチ文書分類器、コーディングアシスタント、マルチモーダルなメディアワークフローでは、データクラス、エンドポイント、プロバイダー規約、保存動作、サポートアクセスが異なる場合があります。

法務レビューの前に、次のルート情報を固定してください。

AIゲートウェイDPAチェックリストは、「AIは承認済み」という広範な文言ではなく、ルート固有の承認記録で締めくくるべきです。

購入者が尋ねるべき10のデータ処理質問

モデルルーティングの購入における中核となるAIベンダーDPAチェックリストとして、これらの質問を使用してください。

エンドポイント、機能、プロバイダー、またはアカウント階層によって回答が変わる場合は、ぼかしてまとめるのではなく、その例外をAIゲートウェイDPAチェックリストに記録する。

DPAの文言を技術的処理に対応させる

Article 28型の処理者契約は、対象、期間、性質、目的、データカテゴリ、管理者の権利、処理者への指示、機密保持、セキュリティ、再委託処理者、削除または返却、データ主体の権利への支援に焦点を当てる。これらは法的用語である。ゲートウェイの購入者は、それをエンジニアリング上の事実に翻訳しなければならない。

次のように対応づける:

ここで、多くのAI APIデータ処理契約レビューは行き詰まる。DPAでは処理者が指示に従って行動するとしていても、製品ルートではこっそり複数プロバイダーへのフォールバックが許可されている場合がある。承認記録には、どのプロバイダーが許可され、どれがブロックされ、誰がそのポリシーを変更できるかを記載すべきである。

エンドポイントと機能ごとに保持を確認する

プロバイダーのデータ管理は、しばしば機能ごとに異なる。OpenAIのプラットフォームデータ管理では、APIの学習制限、標準の不正利用監視保持、承認されたZero Data RetentionまたはModified Abuse Monitoringの設定、エンドポイント固有のアプリケーション状態の挙動が示されている。AnthropicのAPIデータ保持ドキュメントは、Claude API処理とクラウドマーケットプレイス処理を分けており、機能ごとのZDR適格性を説明している。GoogleのGemini Developer APIのZDRドキュメントでは、従量課金サービスの学習制限と、機能レベルでプロンプト、応答、ファイル、グラウンディング、状態、キャッシュの挙動がなお重要になり得ることを説明している。

つまり、「ZDRがあります」だけではLLMゲートウェイのDPAとして不十分である。次を確認する:

• 正確なエンドポイントは保持制御の対象になりますか？
• 正確なプロジェクト、組織、またはアカウントは承認されていますか？
• フォールバック先は、対象外のプロバイダーまたは機能にルーティングされますか？
• ファイル、画像、音声、動画、ツール、ウェブ検索、コード実行、コンテキストキャッシュ、バッチジョブ、またはステートフルな会話によって保持は変わりますか？
• 不正利用監視ログ、アプリケーション状態、ゲートウェイログ、サポート記録、請求記録、バックアップは個別に扱われていますか？

本番ルートでは、1行の保持マトリクスを保存します。

AIゲートウェイDPAチェックリストは、保持される各コピーに所有者、理由、そして削除または有効期限の経路がある場合にのみ完成します。

ゲートウェイログをプロバイダー条項とは別に確認する

ゲートウェイログは、信頼性、コスト管理、デバッグ、監査レビューに役立ちます。また、データ処理の対象面としても独立しています。インフラ提供者による公開ゲートウェイ文書は、購入者がこれを明示的に確認すべき理由を示しています。リクエストログには、ユーザープロンプト、モデル応答、プロバイダー、タイムスタンプ、ステータス、トークン使用量、コスト、所要時間、クライアントメタデータが含まれる場合があり、永続ログの制限はプランによって異なることがあります。

署名前に、次のログ関連の質問をしてください。

• ゲートウェイは、完全なプロンプトや出力を保存できますか、それともメタデータのみですか？
• プロンプトと応答のログは、ルート、環境、ワークスペース、または顧客ごとに無効化できますか？
• 機密フィールドは、ログ記録前に除外、マスク、ハッシュ化、またはマスキングできますか？
• ログは分析、データウェアハウス、アラート、サポートチケット、またはエクスポートにコピーされますか？
• 誰がログを閲覧でき、すべてのアクセスは記録されますか？
• ログは早期削除、監査用エクスポート、またはサポートワークフローからの除外ができますか？
• DPAはログを顧客データ、システムデータ、またはその両方として扱いますか？

これが、法的なDPAレビューと運用上のAIゲートウェイDPAチェックリストの違いです。セキュリティポリシーでプロンプトを保存してはならないと定めているなら、ゲートウェイ、プロバイダー、サポート経路も同じルールに従っていることをルートで証明すべきです。

サブプロセッサーとプロバイダー切り替えを確認する

直接のプロバイダーアカウントには、通常1つの主要な処理チェーンがあります。モデルルーターでは、1つのアプリケーションルートがゲートウェイ、上流プロバイダー、可観測性ツール、決済インフラ、サポートツール、クラウドホスティングに触れるため、チェーンがより長くなることがあります。フォールバックが有効な場合、最初のプロバイダーが失敗すると要求は2番目のプロバイダーに送られることがあります。

DPAパッケージは次の点に答えるべきです。

Flatkeyの購入者は、公開ルートと価格の証拠をアカウント固有の制御と組み合わせてください。1つのキーを複数モデルで使用する場合でも、DPAの証拠には、どの上流プロバイダーが承認済みデータクラスごとに処理できるかを明記する必要があります。

サポート、インシデント、監査の証拠を求める

サポートアクセスは、通常、何かが壊れた後に発生するため、見落としやすいものです。ゲートウェイのDPAレビューでは、サポートも処理の一部です。

以下を求めてください。

• セキュリティまたはプライバシーインシデントに関するサポート連絡先とエスカレーション経路。
• サポート担当者がプロンプト、出力、ログ、アップロードされたファイル、スクリーンショット、または顧客メタデータを閲覧できるかどうか。
• サポートアクセスが時間制限付き、承認済み、かつ記録されているかどうか。
• 対象アカウントについてアクセス透明性記録が利用可能かどうか。
• プロンプトまたは出力の例を含むサポートチケットがどのようにマスキングされるか。
• DPA、条件、SLA、またはセキュリティ補遺の下でどのインシデント通知期限が適用されるか。
• ベンダーがデータ主体の要求、削除、エクスポート、規制当局からの照会を支援するかどうか。

NISTのAIリスク管理フレームワークは、ルートを一度承認したら忘れてしまうのではなく、AIリスクを統治し、把握し、測定し、管理するよう組織に促すため、ここでのガバナンス参照として有用です。モデルルーターにとっては、DPAレビューは更新可能であるべきだということを意味します。レビュー日を設定し、証跡の担当者を割り当て、大きなルート変更の前にプロバイダーの条件を再確認してください。

証跡パケットを作成する

実務上の成果物は、法務、セキュリティ、調達、プラットフォームの各チームが読める小さな証跡パケットです。

Flatkeyについては、ホームページ、プライバシーポリシー、価格ページ、利用規約、SLA、アカウントダッシュボードから最新の公開証跡を追加してください。公開ページは購入者によるサービスの事前選別に役立ちますが、最終判断はアカウント固有の証跡が左右すべきです。

承認を保留すべきレッドフラッグ

次のいずれかが未解決なら、ルートレビューを保留してください。

• DPAにゲートウェイベンダーは記載されているが、上流のモデルプロバイダー経路が記載されていない。
• フォールバックにより、機微データが未承認のプロバイダーへ送信される可能性がある。
• プロンプトまたは出力ログは有効だが、DPAまたはセキュリティレビューでそれらが対象になっていない。
• ベンダーは「学習なし」と述べているが、保持、サポートアクセス、削除、サブプロセッサについて回答できない。
• ZDRが広く約束されているが、選択されたエンドポイント、機能、またはアカウントが対象外である。
• サポートチケットに生のプロンプトが含まれる可能性があるのに、マスキングプロセスがない。
• サブプロセッサの変更に通知経路がない。
• 地域ルーティングが想定されているが、契約、アカウント設定、または利用証跡で証明されていない。
• 価格、ログ、利用エクスポートに、データマップに含めていなかった顧客識別子が含まれている。
• 承認に所有者またはレビュー日がない。

これらのレッドフラッグは、必ずしもベンダーが使えないことを意味するわけではありません。AIゲートウェイDPAチェックリストがまだ完了していないことを意味します。

良い承認の姿

強い承認記録は短く、検証可能であるべきです。

この形式により、DPAが実運用に落とし込まれます。開発者はどのルートに流してよいかを把握できます。調達は何が承認されたかを把握できます。セキュリティは何を監視すべきかを把握できます。法務は、断片的な約束ではなく証跡を持てます。

最終AIゲートウェイDPAチェックリスト

モデルルーターを購入または拡張する前に、次の項目を確認してください。

• AIゲートウェイDPAチェックリストに、正確なルート、エンドポイント、プロバイダー一覧、フォールバックポリシー、データ分類が記載されている。
• AI APIデータ処理契約が、該当する場合、プロンプト、出力、ファイル、ログ、メタデータ、サポートチケット、請求記録、サブプロセッサをカバーしている。
• ゲートウェイのログ保持とプロバイダーの保持が、別々のシステムとしてレビューされている。
• ZDR、学習なし、または変更された保持に関する主張が、正確なアカウント、プロジェクト、エンドポイント、機能に紐づいている。
• プロバイダー切り替えに、許可リスト、所有者、レビュートリガーがある。
• 削除、エクスポート、サポートアクセス、インシデント通知、サブプロセッサ変更通知が文書化されている。
• 公開ベンダーページは、署名済みDPAの代替ではなく、日付付きのスクリーニング証跡として扱われている。
• 承認に所有者、失効日、ルート変更のルールがある。

チームがマルチモデルアクセスのために1つのAPIキーと1つのダッシュボードを求めるなら、Flatkeyから始め、このAIゲートウェイDPAチェックリストを技術的なルートレビューの隣に置いてください。キーを取得し、現在のアカウント制御を確認し、他の本番データ処理者と同じ厳格さで各ルートを承認してください。

確認するソース

• Flatkeyのホームページ
• Flatkeyの料金
• Flatkeyのプライバシーポリシー
• Flatkeyの利用規約
• Flatkeyのサービスレベル契約
• ICOの契約ガイダンス
• OpenAIのデータ制御
• OpenAIデータ処理補遺
• Anthropic APIとデータ保持
• Gemini Developer APIのゼロデータ保持
• Cloudflare AI Gatewayのロギング
• Cloudflare AI Gatewayの料金と永続ログ
• NIST AI Risk Management Framework