ゼロデータ保持（Zero Data Retention）が本当に意味するもの

“ゼロデータ保持”は、実にきっぱりした響きです。ですが、それが意味することは提供者によって、またエンドポイント、アカウントの状態、機能、例外リストによって変わります。自然と、ここで面白さが死に始めます。

少なくとも、チームは次の4つの問いを分けて考えるべきです。顧客コンテンツはモデルの学習に使われるのか？ 不正利用の監視のためにコンテンツは保存されるのか？ 機能を動かすためにアプリケーションの状態は保存されるのか？ 画像やファイル入力はテキストと別扱いなのか？

OpenAIの現在のAPIデータ管理ドキュメントでは、顧客がオプトインしない限り、APIデータはOpenAIのモデルの学習や改善に使われないとしています。また、デフォルトの不正利用監視ログ、Modified Abuse Monitoringや、対象となる承認済み顧客向けのZero Data Retentionといった保持制御、エンドポイント固有のアプリケーション状態、特定の安全性レビューにおける画像/ファイル入力の例外についても説明しています。

MicrosoftのAzureデータプライバシーに関するドキュメントで販売されるFoundry Modelsは、独自の構造を使っています。そこでは、プロンプトや完了（completions）は他の顧客に利用可能ではなく、OpenAIや他のモデル提供者にも利用可能ではなく、許可や指示なしに基盤モデルの学習に使われないとしています。さらに、保存される機能（stored features）、不正利用監視、地理（geography）、そして不正利用監視の保存がオフになっていることを承認済み顧客が確認できる方法についても説明しています。

教訓は「A社は良い、B社は悪い」ではありません。教訓は、ZDRは設定と適格性（eligibility）の物語であって、スローガンではないということです。あるエンドポイントは適格かもしれません。別のエンドポイントはアプリケーション状態を保存するかもしれません。ある機能は削除されるまで保持するかもしれません。別の機能は、ポーリング、キャッシュ、安全性、ダウンロードのウィンドウのために一時的な状態を保持するかもしれません。

画像ワークフローでは、これがより重要になります。画像生成、編集、ファイル入力、動画、バッチジョブ、そしてアシスタントのような状態を持つワークフローは、保存の挙動が異なる可能性があります。テキスト完了（text-completion）エンドポイントからコピーした調達回答は、画像アップロードの質問には答えにならないかもしれません。

提供者を評価するときは、退屈な表を求めてください。エンドポイント。学習用途。不正利用監視。アプリケーション状態。ファイル保持。画像保持。人によるレビュー。安全性の例外。削除API。リージョン。再委託先（subprocessors）。Modified MonitoringまたはZDRの適格要件。退屈な表は、ワクワクするようなインシデントを救います。

Unexposed-styleの製品では、「当社の提供者はZDRを持っています」というだけではなく、最も明確な顧客への約束は「当社の製品は顧客のプロンプトや画像を保持しないように設計されており、当社が利用するエンドポイントに対して、その約束に一致するように提供者のルーティングが行われる」というものです。製品レベルの約束が重要なのは、提供者側の管理は単なる1つのレイヤーにすぎないからです。

ゼロデータ保持は価値があります。ですが、それは魔法のスタンプでもありません。エンドポイントの挙動を読み、さもないと、そのフレーズがやりがちなことをしてしまいます。つまり、システムの下にある実態よりも良く聞こえるようにしてしまうのです。

さらなる読み物：OpenAI APIデータ管理、Microsoft Foundryデータプライバシー、およびゼロ・プロンプト履歴のためのケース。