画像を生成することは、画像を保持することではない

画像を生成して、画像を保持するのは同じプロダクトではありません。

見た目はユーザーにとって似ているかもしれません。どちらもアップロードから始まり、出力で終わります。しかし、サービスがソース画像、生成された出力、プロンプト、サムネイル、または履歴を、直近のタスクが終わった後も保持するかどうかで、法的およびプライバシー上の姿勢は変わります。

一時的な処理でも、適法な根拠とセキュリティが必要です。一時的だからといって免除されるわけではありません。モデルはコンテンツを処理し、その処理には個人データが含まれる可能性があります。しかし、耐久的な保持には追加の問いが生じます。なぜ保持するのか、どれくらいの期間か、誰がアクセスできるのか、どうやって削除できるのか、ユーザーがエクスポートできるのか、そしてアカウントが閉じた場合にどうなるのか。

ホスト型のギャラリーは、わかりやすい例です。実際に役立つこともありますが、約束が変わります。サービスはもはや単なる実行経路ではありません。アーカイブになるのです。つまり、保持ポリシー、アクセス制御、削除の挙動、サポート上の可視性、そして侵害時の影響が、より重要になります。

プロンプトも別の例です。プロダクトによっては、出力を生成した後にプロンプトを破棄します。または、利便性のためにプロンプト履歴を保持する場合もあります。後者の設計は再生成を支えられますが、同時にユーザーの意図も保存します。プロンプトに個人データ、機密の戦略、またはソース画像の文脈が含まれている場合、その履歴はセンシティブなプロダクトデータになります。

アップロードについても同じ区別が当てはまります。短命の生成セッションの間だけ保持されるソース画像は、将来の編集のために保存される画像とはリスクプロファイルが異なります。どちらも正当であり得ます。ただし、「ソース画像を保持しない」と正直に主張できるのは一方だけです。

プロダクトのコピーは、この違いを尊重すべきです。「画像をプライベートに生成します」は「生成した画像ライブラリをホストします」と同じではありません。「一時的なアップロード」は「保存されたプロジェクト資産」と同じではありません。これらはユーザーに対する異なる契約です。

プライバシーへの露出を低くしたいなら、保持する量を減らしてください。これは抜け道ではありません。普通のシャツを着たデータ最小化です。

さらなる読み物：EDPB Opinion 28/2024、「アップロードを削除する」には検証可能である必要がある理由、および Unexposedのデータ保存。