OpenAI promet une rétention zéro des données, la détection de sécurité ne lit pas le contenu original

Le 19 août, OpenAI a publié sur son site un communiqué destiné aux clients de son API : pour les clients éligibles, l'entreprise continue de proposer la rétention zéro des données (Zero Data Retention, ZDR) — une fois la requête traitée, ni les prompts ni les réponses du modèle ne sont conservés. Dans ce même communiqué, elle a présenté un mécanisme baptisé « traitement de sécurité privé » (private safety processing), capable de repérer des signes d'abus à travers plusieurs interactions liées, sans exposer le contenu original aux employés d'OpenAI.

La rétention zéro des données n'est pas un concept nouveau. Pour les clients des secteurs financier, médical ou juridique, la capacité à garantir contractuellement que « rien n'est conservé de votre côté » a toujours été une condition sur laquelle les négociations pouvaient buter. Selon des informations publiques, la raison de ce communiqué distinct tient au fait que les modèles prennent désormais en charge des tâches plus longues et plus automatisées : une requête isolée ne révèle aucun problème, mais le risque se disperse le long de toute une chaîne de sessions. Pour repérer ce type de schéma, la détection d'abus a besoin d'un élément de comparaison — ce qui entre directement en conflit avec la rétention zéro.

Déplacer la détection dans une boîte chiffrée

La solution d'OpenAI consiste à confier la partie comparable au client lui-même. Le contenu du client peut rester sur une infrastructure qu'il contrôle, ou être stocké par OpenAI, mais la clé de chiffrement reste entre ses mains. Un système automatisé effectue une évaluation entre sessions sur cette couche de contenu chiffré, en examinant les entrées et sorties de plusieurs conversations plutôt qu'une requête isolée. En cas de détection, ce qui est renvoyé à OpenAI se limite à un signal :

a narrowly defined safety signal, without exposing the underlying prompts or responses

un signal de sécurité défini de façon très restreinte, sans exposer les prompts ni les réponses sous-jacentes.

Une fois ce signal reçu, c'est au client de décider s'il pousse l'investigation plus loin et s'il transmet les données. Selon l'entreprise, ce mécanisme vise à la fois les personnes qui abusent de la plateforme et les agents d'IA qui déraillent.

Une exception est énoncée sans détour : les images signalées comme du matériel présumé d'abus sexuel sur mineurs continuent d'être conservées même dans un déploiement à rétention zéro, pour permettre un examen manuel et un signalement, comme c'est déjà le cas actuellement.

Une voie différente de celle d'Anthropic

Face à la même problématique, une autre entreprise apporte une réponse quasiment opposée. Selon plusieurs médias, Anthropic conserve pendant 30 jours les données de session pour une partie des modèles concernés, l'examen manuel passant par un accès contrôlé, chaque consultation étant consignée dans des journaux infalsifiables (tamper-evident logs). Son pari est celui de la traçabilité : en cas d'incident, une chaîne de preuves complète existe, et l'on peut vérifier qui a consulté les données.

Le pari d'OpenAI est de ne produire aucune chaîne de preuves. La différence entre ces deux approches ne tient pas à la capacité de sécurité, mais à ce que redoutent les clients entreprises. Les entreprises qui craignent les abus internes et les rejets de responsabilité après coup privilégieront des journaux infalsifiables ; celles qui redoutent les citations à comparaître externes et la conformité transfrontalière préféreront que les données ne se retrouvent jamais entre les mains du fournisseur — une fenêtre de rétention de 30 jours signifie, en gros, que chaque conversation reste un mois durant accessible à des procédures externes. Pour une entreprise opérant dans plusieurs juridictions, ce mois n'est pas simple à justifier auprès de son service juridique.

Pour les équipes qui achètent des modèles dans une logique internationale, ce point peut être ajouté directement à la liste de questions : où les données sont-elles stockées, à qui appartient la clé, quel processus s'enclenche une fois qu'une politique de sécurité est déclenchée. Auparavant, ce type de question ne recevait souvent qu'un « nous prenons la sécurité très au sérieux » en guise de réponse.

Avant le livre blanc, tout n'est qu'annonce

Le traitement de sécurité privé n'est pour l'instant testé qu'auprès de quelques clients pilotes, avec un déploiement progressif prévu en septembre, accompagné à la même date de la publication du livre blanc technique. Le communiqué laisse encore beaucoup de zones d'ombre : quels modèles seront couverts, quelle est réellement la granularité des signaux, quelle procédure de recours suivra un client en cas de faux positif. La façon dont l'analyse entre sessions est techniquement mise en œuvre sur des données chiffrées n'a pas non plus été dévoilée — en attendant le livre blanc, ces descriptions restent une promesse, pas un dispositif vérifiable.

Pour les acheteurs en entreprise, ce qu'il est possible de faire dès maintenant, c'est de noter l'échéance de septembre. Une fois le livre blanc publié, le confronter point par point à sa propre liste de conformité sera bien plus utile que de simplement lire le communiqué actuel.

Sources : communiqué officiel d'OpenAI, CocoLoop, TechCrunch ; vérifié à partir du communiqué d'OpenAI sur le périmètre des clients éligibles à la rétention zéro des données, la détention des clés de chiffrement et le calendrier de déploiement du traitement de sécurité privé.