OpenAI prépare un nouveau système de surveillance de sécurité pour les clients API éligibles utilisant Zero Data Retention (ZDR), afin de répondre à une tension croissante dans l’IA d’entreprise : les modèles avancés ont besoin de plus de contexte pour détecter les abus, tandis que les clients exigent de plus en plus que les prompts et réponses sensibles restent privés.

L’entreprise a indiqué dans un billet OpenAI News que Private Safety Processing est testé avec ses premiers clients. Le système proposé analyserait des schémas à travers des interactions liées sans donner au personnel d’OpenAI accès au contenu sous-jacent. OpenAI prévoit de commencer le déploiement et de publier un livre blanc technique en septembre, mais n’a pas fourni de date de lancement précise ni de calendrier de déploiement détaillé.

Ce qu’OpenAI modifie

Dans le cadre de Zero Data Retention, OpenAI indique qu’elle ne conserve pas les prompts ni les réponses du modèle des clients éligibles après le traitement d’une requête. Le contenu client n’est pas accessible au personnel d’OpenAI pour examen, et les données d’entreprise ne sont pas utilisées pour entraîner les modèles, sauf si un client y consent explicitement.

Ce modèle de contrôle a historiquement rendu plus difficile la réalisation d’analyses de sécurité sur plusieurs échanges. OpenAI affirme que les systèmes compatibles ZDR existants évaluent les interactions individuellement. Private Safety Processing vise à étendre ces vérifications à des interactions liées, afin de permettre aux systèmes automatisés de rechercher des schémas qui ne seraient pas visibles dans une seule requête.

L’entreprise a décrit plusieurs exemples de risques susceptibles d’apparaître au fil du temps : tentatives répétées de contourner les protections, activités coordonnées entre comptes, menaces déguisées en recherche ordinaire, ou encore un agent IA poursuivant ses actions après qu’un utilisateur lui a demandé d’arrêter. L’annonce relie directement la proposition à la complexité croissante des modèles de frontière et des agents IA fonctionnant sur de longues durées.

OpenAI a présenté deux configurations de stockage possibles. Dans l’une, le contenu reste sur une infrastructure contrôlée par le client. Dans l’autre, le contenu pourrait être stocké sur l’infrastructure d’OpenAI mais chiffré avec des clés contrôlées par le client. OpenAI affirme que son personnel ne disposerait pas de copies de ces clés et ne pourrait donc pas accéder aux prompts ou réponses sous-jacents.

Comment fonctionnerait la couche de sécurité proposée

Si des systèmes automatisés identifient un risque potentiel, OpenAI indique qu’ils enverraient à l’entreprise un signal précisément défini décrivant le type d’activité concerné plutôt que le contenu du client. OpenAI pourrait utiliser ce signal pour décider si une mesure coercitive est nécessaire, tandis que le client conserverait les informations sous-jacentes dans ses propres systèmes.

Les clients pourraient enquêter sur les alertes et les décisions de mise en application à l’aide des informations disponibles dans leur environnement. Ils pourraient aussi choisir de partager des éléments pertinents avec OpenAI s’ils souhaitent contester une décision, expliquer une activité légitime ou aider à une enquête sur des abus avérés.

Cette conception tente de séparer l’application des règles de sécurité de l’accès humain de routine aux données client. Cela ne signifie pas qu’aucune donnée ne pourra jamais être conservée. OpenAI a explicitement indiqué que les images signalées comme pouvant constituer du matériel d’exploitation sexuelle d’enfants continueront d’être conservées pour examen manuel et signalement, y compris dans les déploiements ZDR, en raison d’exigences légales.

L’annonce laisse également ouvertes d’importantes questions techniques. OpenAI n’a pas encore publié l’architecture, les mécanismes de conservation des signaux de risque, les taux d’échec ni les contrôles exacts qui seront fournis aux clients. Ces détails seront essentiels pour déterminer si le système satisfait les organisations soumises à des exigences strictes en matière de confidentialité, d’audit et de réglementation.

Preuves et limites de l’annonce

La principale preuve du plan produit est l’annonce d’OpenAI elle-même. Une deuxième source porte le même titre via une requête Google News, mais le texte complet de l’article n’était pas disponible, ce qui ne permet pas de corroborer indépendamment les affirmations techniques ni d’apporter des informations supplémentaires sur le marché.

Les déclarations d’OpenAI concernant Zero Data Retention, le chiffrement, l’accès des employés et Private Safety Processing doivent donc être considérées comme des engagements et des plans produits rapportés par le fournisseur. L’entreprise indique que le nouveau système est actuellement testé auprès des premiers clients, mais elle n’a pas nommé ces clients ni fourni de chiffres d’adoption.

L’article inclut un commentaire positif de Glean, qui a déclaré que l’engagement d’OpenAI à ne pas entraîner ses modèles et sa politique ZDR soutiennent sa décision de construire avec OpenAI. Il s’agit d’un soutien individuel d’un client ou partenaire, et non d’une preuve indépendante d’une adoption large en entreprise. OpenAI a également indiqué avoir reçu des retours d’organisations de divers secteurs, régions et tailles d’entreprise, mais sans fournir de détail sur ces organisations.

Les affirmations les plus fortes concernant une sécurité préservant la vie privée restent prospectives tant qu’OpenAI n’aura pas publié le document technique annoncé et que les clients n’auront pas pu évaluer les contrôles en production. En particulier, les acheteurs devront comprendre quelles métadonnées sont générées, combien de temps les signaux de sécurité sont conservés, qui peut y accéder et comment les décisions automatisées de mise en application peuvent être contestées.

Pourquoi cela compte pour les équipes produit et les entreprises

Pour les équipes produit qui construisent des applications autour des modèles de frontière, l’annonce traite un problème pratique de déploiement. De nombreux workflows impliquent des dossiers confidentiels, de la recherche propriétaire, des informations de santé, des données financières ou des plans d’affaires. Exiger d’un fournisseur qu’il conserve le contenu pour examen de sécurité peut bloquer ces applications même lorsque le modèle est techniquement capable de les prendre en charge.

Private Safety Processing pourrait rendre ZDR plus viable pour des applications qui fonctionnent sur plusieurs tours de conversation ou appellent des agents IA de manière répétée. Un assistant de codage, un flux de recherche ou un système de service client peut générer une série de requêtes individuellement anodines qui ne deviennent préoccupantes que lorsqu’on les examine ensemble. À l’inverse, une surveillance en plusieurs étapes peut créer de nouveaux risques si des activités légitimes sont mal classées ou si les clients ne peuvent pas reconstituer pourquoi une alerte a été émise.

La proposition transfère également une partie de la responsabilité opérationnelle vers les clients. Si OpenAI ne voit pas le contenu sous-jacent, les clients auront besoin d’une journalisation interne robuste, de contrôles d’accès, d’outils de réponse aux incidents et d’enquête. Cela peut séduire les organisations réglementées parce que les informations sensibles restent dans leur environnement, mais cela signifie aussi que la protection de la vie privée dépendra en partie de leur propre infrastructure et gouvernance.

Pour les bâtisseurs de solutions IA, la question commerciale clé est de savoir si des garanties de confidentialité plus fortes peuvent coexister avec une détection fiable des abus. Les fournisseurs qui conservent davantage de données peuvent offrir une surveillance centralisée plus simple, tandis que les déploiements de type ZDR offrent un contrôle plus étroit au client mais exigent des arrangements techniques plus complexes. OpenAI positionne son nouveau système comme un moyen de réduire cet écart sans abandonner ZDR.

Ce qu’il faudra surveiller ensuite

Le premier signal sera le déploiement prévu par OpenAI en septembre et son livre blanc technique. Les acheteurs devraient rechercher des définitions précises de « interactions liées », le périmètre de l’analyse automatisée, les durées de conservation des signaux de sécurité et les limites de l’accès des employés.

Les premiers déploiements chez les clients montreront aussi si le système peut identifier des abus coordonnés sans générer de faux positifs inacceptables. Les éléments concernant la latence, la cohérence de l’application, le traitement des recours et le support des infrastructures contrôlées par le client compteront davantage que l’annonce elle-même.

Une autre question est de savoir si Private Safety Processing couvrira tous les modèles de frontière et tous les usages de l’API, ou seulement certains produits et clients. OpenAI le présente comme compatible avec ZDR, mais n’a pas précisé les critères d’éligibilité, la tarification, la disponibilité régionale ni les engagements de niveau de service.

Perspective Creati.ai

L’aperçu d’OpenAI vise l’un des arbitrages les plus difficiles de l’IA d’entreprise : les systèmes de sécurité bénéficient souvent d’un large contexte comportemental, tandis que les clients souhaitent que les fournisseurs voient le moins possible leurs données. Une conception fondée sur du contenu chiffré, des clés détenues par le client et des signaux de risque limités est une direction crédible, mais sa valeur dépendra de la transparence technique et des performances opérationnelles.

Pour l’instant, il s’agit d’un engagement produit en cours de test, et non d’une capacité achevée. Les bâtisseurs et les acheteurs en entreprise devraient considérer ZDR comme une frontière de confidentialité significative, tout en attendant le document technique et les résultats en production pour vérifier comment Private Safety Processing gère la détection des abus, les audits, les recours et les cas juridiques exceptionnels.