8月20日、Runtime Wireが「OpenAI previews cross-session safety checks designed to preserve zero data retention」と題した記事を公開した。エンタープライズ向けAI導入において長らく解決できなかった問題——安全監視のためにデータを保持したいAI側と、データを外部に渡せない規制産業側の根本的な矛盾——に対し、OpenAIが技術的な回答を示した。

ゼロデータ保持と安全監視の両立という矛盾を解く

医療・金融・法務などの規制産業では、会話ログをサードパーティに保持させること自体が禁じられているケースが多い。一方でAIプロバイダーがモデルの安全監視を行うには、会話ログを参照する必要がある。この二律背反が、エンタープライズへのAI導入を阻む壁になってきた。

OpenAIのCEO Sam Altmanは、このジレンマへの回答をX（旧Twitter）への投稿で「we support business privacy!（ビジネスのプライバシーを支持する）」の一言に圧縮した（Xにて公開）。

OpenAIが発表したPrivate Safety Processingは、ゼロデータ保持（ZDR）対応のAPIカスタマーに対し、会話内容を保持せずにセッションをまたいだ不正パターンを検知する仕組みだ。現在は初期顧客との試験段階にあり、9月に段階的な提供開始を予定している。同時期に技術白書も公開される。

既存のZDRと何が違うのか

OpenAIの既存のZero Data Retention（ZDR）プログラムは、承認済み組織のAPIリクエストにおいて、プロンプトと応答を不正監視ログから除外する仕組みだ。標準設定では、プロンプトと応答は最大30日間保持される。

しかし既存のZDR対応セーフガードは1インタラクションずつ個別に評価するにとどまる。エージェント型タスクが普及した現在、問題のある行為は複数のプロンプト・アカウント・セッションにまたがって分散されることがある。たとえば、セーフガードを繰り返し探る試み、複数アカウントにまたがる協調的な不正、ユーザーが停止を指示した後も動き続けるエージェントなどが典型例だ。

Private Safety Processingはこうしたセッション横断のパターンを検知する。

アーキテクチャの核心：顧客鍵によるエンドツーエンドの隔離

処理方式として、OpenAIは2つの構成を提示している。

• ZDRデプロイメント：プロンプトと応答は顧客が管理するインフラ上に留まる。
• OpenAIインフラ利用構成（開発中）：コンテンツはOpenAI側インフラに置くが、顧客が保持する鍵で暗号化される。OpenAI社員はその鍵のコピーを持たない。

いずれの場合も、自動化されたシステムが保護コンテンツを処理し、不審な活動のカテゴリを示す限定的なシグナルだけをOpenAIの担当者に返す。プロンプトや応答の原文にはアクセスしない設計だ。

利用停止などの執行措置に対して顧客が異議を申し立てる場合、または正当な活動の説明や不正調査への協力が必要な場合に限り、顧客が自らの判断で関連資料をOpenAIに提供する形をとる。

対抗軸は「フロンティアモデルへのアクセスとデータ管理の二択」

OpenAIはこの設計を、安全監視のためにコンテンツ保持を求めるフロンティアモデルデプロイメントへの対抗として明確に位置づけている。性能の高いモデルであっても、導入にあたって機密データの管理権を手放すことを求められれば、規制産業のセキュリティチームには受け入れられない。

発表に名前が挙がった顧客企業はGlean、Databricks、Abridge、Microsoft。Gleanのセキュリティ責任者Sunil Agrawal氏は、エンタープライズ導入の前提として「顧客が情報の管理を保持し、選択したサービス以外での利用を防止できること」を挙げている。

このラインナップが示す市場——検索、データインフラ、ヘルスケア、ワークプレイスソフトウェア——はいずれも、汎用の審査キューにデータを流せない企業群だ。

ZDRの範囲と例外

ZDRは全OpenAI製品に適用される包括的な約束ではなく、承認ベースのAPIコントロールだ。現行のドキュメントでは、バックグラウンド処理やCode Interpreterは標準ZDR構成と非互換とされている。

また、CSAM（児童性的虐待素材）に該当すると判定された画像については例外が設けられており、ZDRデプロイメントであってもヒューマンレビューおよび法的に義務付けられた報告のために保持される。

9月の白書が問われる

製品アーキテクチャと執行フローは示された。しかし技術的な証明はまだこれからだ。9月に公開される白書では、以下の点を明確にする必要がある。

• 処理の隔離方法：自動化システムがどの範囲のデータにアクセスし、何をシグナルとして抽出するのか
• 顧客管理鍵の実際の動作：鍵の生成・保管・失効フローがどう設計されているか
• 安全シグナルの情報範囲：「限定的なシグナル」がどこまで限定的なのか、原文復元の可能性を排除できるか
• 誤検知の処理フロー：原文コンテンツを露出させずに異議申し立てをどう処理するか

「データを見ずに不正を検知する」という主張の信憑性は、その白書の内容にかかっている。アーキテクチャの説明が説得力を持つかどうかは、これらの検証軸への回答次第だ。

詳細はOpenAI previews cross-session safety checks designed to preserve zero data retentionを参照していただきたい。