OpenAI teste une sécurité multi-interactions sans conserver les données clients

OpenAI teste une nouvelle architecture de sécurité destinée à détecter les usages abusifs à travers plusieurs interactions liées, sans obliger l’entreprise à conserver les prompts des clients ni les réponses des modèles. Le système, appelé Private Safety Processing, a été présenté en avant-première le 19 août pour les clients API éligibles utilisant Zero Data Retention, ou ZDR. OpenAI affirme que cette approche doit préserver un engagement de confidentialité important pour les organisations réglementées ou très sensibles à la sécurité, tout en donnant aux mécanismes de sûreté davantage de contexte qu’une requête isolée.

Le calendrier est important parce que les modèles de pointe sont de plus en plus utilisés pour des tâches longues, en plusieurs étapes et de nature agentique. OpenAI explique que les protections compatibles avec ZDR évaluent aujourd’hui chaque interaction séparément, ce qui peut laisser passer des comportements nuisibles qui n’apparaissent qu’au fil d’une séquence d’actions. Dans son annonce, l’entreprise cite notamment les tentatives répétées de contourner les protections, la coordination entre plusieurs comptes, des menaces déguisées en recherches ordinaires et des agents qui continuent d’agir après avoir reçu l’ordre de s’arrêter.

Avec ZDR, les clients API éligibles reçoivent la promesse qu’OpenAI ne conserve pas leurs prompts ni les réponses du modèle une fois la requête traitée, et que le contenu client n’est pas accessible au personnel d’OpenAI pour examen. Cette conception est attractive pour les organisations qui manipulent des données financières, des informations de santé, de la recherche propriétaire ou d’autres données sensibles. Elle crée toutefois un compromis difficile en matière de sécurité. Un fournisseur qui ne conserve pas le contenu dispose de moins d’éléments pour mener des enquêtes a posteriori ou identifier un schéma réparti sur de nombreuses requêtes.

Private Safety Processing constitue la tentative d’OpenAI de séparer le signal nécessaire à l’application des règles de sécurité du contenu sous-jacent du client. Pour les déploiements ZDR, OpenAI indique que le contenu reste sur une infrastructure contrôlée par le client. L’entreprise développe également une seconde option dans laquelle le contenu serait stocké sur l’infrastructure d’OpenAI, mais chiffré avec des clés contrôlées par le client. Dans les deux cas, des systèmes automatisés doivent identifier les abus potentiels et renvoyer à OpenAI un signal de sécurité étroitement défini, sans donner au personnel de l’entreprise accès aux prompts ou aux réponses.

OpenAI précise que ces signaux peuvent indiquer le type d’activité concerné et servir à déterminer si une mesure d’application est nécessaire. Si un client doit enquêter sur une alerte, il peut utiliser les informations disponibles dans ses propres systèmes. Il peut aussi choisir de partager des éléments pertinents avec OpenAI pour contester une décision, expliquer une activité légitime ou contribuer à l’enquête sur un abus confirmé. Une partie de la charge probatoire se déplace donc vers le client, ce qui peut être avantageux pour les organisations soucieuses de confidentialité mais crée aussi une exigence opérationnelle de journalisation interne suffisante.

Les reportages indépendants se sont concentrés sur ce compromis. Bloomberg a rapporté qu’OpenAI renforce les processus de sécurité pour les utilisateurs payants de ses systèmes les plus avancés tout en maintenant ses engagements de zéro rétention pour les clients éligibles. Computerworld a décrit l’architecture comme un moyen de corréler les risques entre interactions tout en préservant la confidentialité, mais a souligné un problème fondamental de vérification : détecter un comportement dans le temps suppose encore de conserver une forme de représentation persistante, même s’il s’agit d’un signal dérivé plutôt que d’un contenu lisible.

Cette distinction est importante pour les architectes d’entreprise. Private Safety Processing ne supprime pas l’état. Il modifie la nature de l’état conservé, son emplacement et les personnes autorisées à le lire. Une organisation qui évalue cette conception devrait demander quels signaux sont générés, combien de temps ils persistent, quels événements peuvent déclencher une mesure, comment ces signaux sont reliés aux preuves détenues par le client et quelle piste d’audit reste disponible lorsqu’une décision est contestée. Sans ces détails, il serait prématuré de considérer cette avant-première comme une solution complète à la tension entre confidentialité, sécurité et responsabilité.

L’architecture peut également modifier le fonctionnement de la réponse aux incidents. Si le personnel d’OpenAI ne peut pas consulter le contenu signalé, le client peut devenir le principal détenteur du dossier forensique. Les organisations utilisant ZDR doivent donc déterminer si leurs journaux applicatifs, leur télémétrie de sécurité et les traces de leurs agents permettent de reconstituer un incident sans compromettre la raison pour laquelle elles ont choisi ZDR. La réponse dépendra du secteur. Un déploiement dans la santé, par exemple, pourra nécessiter des politiques de conservation et de contrôle d’accès différentes de celles d’un agent de développement travaillant sur du code propriétaire.

Pour les équipes de gouvernance, la leçon la plus utile est que les contrôles de confidentialité et de sécurité doivent être conçus ensemble plutôt que traités comme deux cases indépendantes dans un processus d’achat. Une promesse ZDR peut réduire l’exposition des données sensibles chez le fournisseur, mais elle ne supprime pas le besoin de contrôles côté client sur l’autorisation, la conservation, l’enquête et les recours. De même, un détecteur capable de relier plusieurs interactions peut améliorer la détection des abus par le fournisseur sans garantir au client suffisamment de transparence pour expliquer une alerte ou démontrer qu’un workflow légitime a été mal classé.

L’annonce a aussi une implication plus large pour la sécurité des agents. Les contrôles fondés sur un prompt unique correspondent de moins en moins à des systèmes qui planifient et agissent sur de nombreuses étapes. Les agents de longue durée peuvent accumuler de l’autorité, interagir avec des outils externes et s’écarter de l’intention initiale de l’utilisateur. OpenAI cite explicitement le cas d’un agent qui continue d’agir après avoir reçu l’ordre de s’arrêter comme un risque que le nouveau système vise à détecter. Cela renforce une évolution plus générale, de la modération au niveau du prompt vers un suivi au niveau de la session et des actions.

L’annonce doit néanmoins être considérée comme une avant-première, et non comme un contrôle mature doté de garanties vérifiées indépendamment. OpenAI indique que Private Safety Processing est actuellement testé avec des clients pilotes et prévoit de commencer son déploiement en septembre, accompagné d’un livre blanc technique. L’entreprise n’a pas encore publié suffisamment de détails pour permettre à des tiers de vérifier le fonctionnement de la corrélation entre interactions, les taux de faux positifs, la mise en œuvre de la gestion de clés contrôlées par le client ou la possibilité d’auditer indépendamment les signaux utilisés pour l’application des règles.

OpenAI mentionne aussi une limite importante à la promesse ZDR. Les contenus pouvant constituer des images d’abus sexuels sur mineurs restent soumis aux obligations légales de signalement, et les images signalées comme CSAM potentielles peuvent être conservées pour examen manuel et signalement, y compris dans un déploiement ZDR. Pour les acheteurs d’entreprise, cette exception rappelle que zéro rétention est un engagement produit et juridique délimité, et non une affirmation universelle selon laquelle aucune information ne peut jamais être conservée.

L’importance pratique de cette annonce n’est donc pas qu’OpenAI aurait résolu la surveillance confidentielle de la sécurité. Le changement matériel est qu’un fournisseur de modèles de pointe s’oriente vers une architecture où la détection de risques à travers plusieurs interactions est séparée de l’accès direct du fournisseur au contenu du client. Si le livre blanc de septembre étaye ces affirmations et si le contrôle se comporte de manière prévisible en production, Private Safety Processing pourrait devenir un modèle d’architecture pertinent pour les déploiements d’IA réglementés. D’ici là, les architectes et équipes de gouvernance devraient le considérer comme un mécanisme prometteur de sécurité respectueux de la confidentialité, dont l’auditabilité, les modes de défaillance et les responsabilités opérationnelles restent à tester.