Private Safety Processing : comment OpenAI surveille les usages à risque sans lire les conversations

OpenAI teste Private Safety Processing, une architecture de sécurité conçue pour certains clients API éligibles au dispositif Zero Data Retention (ZDR), ou conservation zéro donnée. Sa promesse est de détecter des schémas d’utilisation abusive qui n’apparaissent qu’en reliant plusieurs interactions, sans donner par défaut à ses employés accès au contenu des clients.

L’enjeu devient plus important à mesure que les modèles sont utilisés dans des workflows plus longs et plus autonomes. Un objectif malveillant peut être réparti entre plusieurs comptes, sessions ou requêtes, de sorte qu’aucune interaction isolée ne révèle clairement l’ensemble du projet. Private Safety Processing cherche à apporter ce contexte élargi tout en conservant les protections associées au ZDR.

Comment fonctionne Private Safety Processing ?

Les protections ZDR existantes évaluent déjà les requêtes et les réponses individuellement. La nouvelle préversion étend cette logique : des systèmes automatisés analysent les relations entre plusieurs interactions afin d’identifier des schémas pouvant correspondre à un abus coordonné, comme une tentative de contourner les garde-fous ou de répartir des tâches liées au développement de logiciels malveillants entre différentes requêtes.

La distinction essentielle se situe entre analyse et conservation. OpenAI affirme que Private Safety Processing peut analyser une activité liée à des fins de sécurité, sans que le système expose le contenu sous-jacent à son personnel.

OpenAI décrit deux configurations possibles pour les déploiements ZDR :

• le contenu peut rester sur une infrastructure contrôlée par le client ;
• dans une configuration avec stockage hébergé par OpenAI, il peut être chiffré avec des clés contrôlées par le client, et non par le personnel d’OpenAI.

Dans les deux cas, des systèmes automatisés peuvent détecter un usage potentiellement abusif et renvoyer un signal de sécurité limité, sans exposer les prompts ou les réponses du modèle.

Que reçoit OpenAI lorsqu’une menace est détectée ?

D’après la description de la préversion, OpenAI reçoit une alerte dont le périmètre est volontairement restreint : elle indique le type d’activité concerné. Le schéma présenté par l’entreprise décrit notamment une catégorie d’alerte et un niveau de gravité, plutôt que la conversation elle-même.

Ce signal peut servir à prendre des décisions de sécurité ou d’application des règles, mais il ne revient pas à transmettre à OpenAI l’historique complet d’une session. Le fonctionnement peut être résumé ainsi :

1. Des systèmes automatisés examinent plusieurs interactions liées afin de repérer un schéma potentiellement dangereux.
2. Si ce schéma dépasse un certain seuil de risque, le système génère une classification de sécurité limitée.
3. OpenAI reçoit cette classification, et non les prompts, les réponses ou la transcription de la conversation.
4. Le client conserve la possibilité d’enquêter sur l’activité sous-jacente dans son propre environnement.

Il s’agit encore d’une préversion. Pour les entreprises, les détails de l’implémentation, les seuils de détection et la gestion des erreurs seront donc déterminants. OpenAI a indiqué prévoir un déploiement plus large ainsi qu’un livre blanc technique en septembre 2026.

Pourquoi les employés d’OpenAI ne voient-ils normalement pas une conversation signalée ?

Un signalement de sécurité ne donne pas automatiquement au personnel d’OpenAI accès à la conversation. Dans les configurations ZDR décrites par l’entreprise, OpenAI affirme ne pas conserver le contenu du client et, dans le scénario de stockage hébergé par OpenAI, ne pas détenir les clés de déchiffrement contrôlées par le client.

Un client peut toutefois choisir de transmettre des éléments pertinents s’il souhaite contester une mesure d’application des règles, expliquer un usage légitime ou contribuer à l’enquête sur un abus confirmé. Sans cette transmission volontaire, le signalement se limite aux informations de sécurité générées par la machine et envoyées à OpenAI.

Le dispositif sépare ainsi les éléments de preuve contrôlés par le client des signaux de risque reçus par le fournisseur. Cette séparation pourrait réduire la quantité de données sensibles qu’un fournisseur doit manipuler, tout en lui permettant de repérer des schémas qu’un filtre analysant chaque requête séparément ne détecterait pas.

Quels clients testent la préversion ?

OpenAI cite Glean, Databricks, Abridge et Microsoft parmi les clients qui contribuent à façonner ou à tester la préversion. D’autres articles citent également Microsoft et Databricks comme clients pilotes.

La fonctionnalité n’est pas présentée comme un réglage destiné au grand public. Elle vise certains déploiements API d’organisations qui souhaitent utiliser des modèles avancés tout en gardant un contrôle strict sur leurs prompts et leurs réponses.

OpenAI et Anthropic : deux compromis de sécurité différents

L’approche d’OpenAI donne la priorité à la détection des abus tout en limitant l’accès du fournisseur au contenu des clients. La politique d’Anthropic pour ses modèles couverts fait un choix différent : les prompts et les réponses envoyés à ces modèles sont conservés pendant 30 jours afin de soutenir les opérations de sécurité, notamment un examen humain encadré.

La documentation d’Anthropic précise que cette obligation concerne les modèles couverts, notamment les modèles de la classe Mythos, et que ceux-ci ne sont pas disponibles avec le ZDR. Elle indique également que les données conservées ne sont pas utilisées pour entraîner les modèles sans l’autorisation explicite du client.

La différence opérationnelle est donc importante :

• Private Safety Processing d’OpenAI : analyse automatisée de plusieurs interactions liées ; selon la description de la préversion, OpenAI reçoit un signal de sécurité limité plutôt que le contenu sous-jacent.
• Politique d’Anthropic pour les modèles couverts : prompts et réponses conservés pendant 30 jours afin de soutenir le travail de sécurité et un examen humain encadré.

Aucune de ces approches ne dispense les clients de mettre en place leur propre gouvernance. Avant de traiter des données sensibles, les acheteurs doivent vérifier les règles d’éligibilité, l’architecture de déploiement, les contrôles d’accès, les conditions de conservation, les exigences régionales, la procédure de contestation et les engagements contractuels.

Pourquoi cette différence compte pour les secteurs réglementés

Les organisations des secteurs de la finance, de la santé et du droit traitent souvent des informations soumises à des obligations de confidentialité contractuelle, à des règles de protection de la vie privée, au secret professionnel ou à des exigences sectorielles. La capacité d’un fournisseur à conserver et potentiellement examiner des prompts peut donc influencer l’analyse de minimisation des données, les validations internes, la conception des audits et l’évaluation des risques liés aux fournisseurs.

Cela ne signifie pas qu’une conservation de 30 jours est automatiquement interdite, ni qu’un déploiement ZDR est à lui seul synonyme de conformité. Les deux modèles soulèvent simplement des questions différentes pour les équipes juridiques et de sécurité. Les conditions d’Anthropic obligent les organisations à intégrer la conservation et l’examen éventuel par le fournisseur, tandis qu’OpenAI présente le ZDR et Private Safety Processing comme un moyen de limiter l’accès du fournisseur au contenu lui-même.

Pour une entreprise, les questions les plus concrètes sont les suivantes :

• Le modèle et le déploiement sont-ils éligibles au ZDR ?
• Où le contenu est-il traité et, s’il est stocké, qui contrôle les clés de chiffrement ?
• Quels champs précis figurent dans une alerte de sécurité ?
• Le client peut-il auditer ou contester un signalement sans divulguer la conversation complète ?
• Que se passe-t-il lorsqu’un fournisseur soupçonne un abus grave ?
• Les règles de conservation et d’examen du fournisseur sont-elles compatibles avec les obligations contractuelles et réglementaires de l’organisation ?

La confidentialité devient une fonctionnalité de produit

Private Safety Processing fait de la confidentialité une composante du produit de sécurité de l’IA. La question n’est plus seulement de savoir si un modèle peut bloquer une requête dangereuse, mais aussi si son fournisseur peut détecter un usage abusif coordonné sur une longue séquence sans avoir accès à chaque conversation du client.

La préversion d’OpenAI propose une réponse : conserver le contenu sur une infrastructure contrôlée par le client, ou le protéger avec des clés détenues par celui-ci, analyser automatiquement les schémas entre interactions et transmettre au fournisseur une classification de risque restreinte.

La politique d’Anthropic propose une autre réponse : conserver pendant une durée limitée les prompts et les réponses concernés afin de permettre leur examen par les équipes de sécurité, avec un contrôle humain encadré et une limitation déclarée de leur utilisation pour l’entraînement des modèles.

Le choix dépendra de la tolérance au risque du client, de la sensibilité de ses traitements et du niveau de visibilité dont il estime qu’un fournisseur de modèles avancés a besoin. Le livre blanc technique et le déploiement plus large annoncés par OpenAI devraient permettre de vérifier plus précisément comment ces garanties de confidentialité fonctionnent en conditions réelles.