OpenAI maintient la ZDR pour son API de pointe

OpenAI a publié le 19 août une mise à jour utile sur la confidentialité de l'IA en entreprise : elle indique que les clients API éligibles peuvent continuer à utiliser la rétention nulle des données (Zero Data Retention, ZDR) avec ses modèles de pointe, tout en présentant en avant-première une nouvelle couche de sécurité appelée Private Safety Processing. L'essentiel n'est pas la dénomination marketing. L'essentiel est qu'OpenAI cherche à séparer deux éléments qui sont en tension pour les déploiements sérieux : ne pas conserver les invites et réponses des clients, tout en continuant à détecter les comportements dangereux sur plusieurs tours d'échange.

Pour les équipes qui intègrent l'IA dans des outils internes, des flux réglementés, des agents de code, des systèmes de support ou des automatisations orientées client, ce point mérite d'être lu comme un signal d'architecture. La politique de rétention n'est plus une simple case à cocher noyée dans les achats. Elle devient une contrainte de routage, d'observabilité, de réponse aux incidents et de sélection des fournisseurs.

Ce qu'OpenAI a confirmé

L'annonce d'OpenAI indique que la rétention nulle des données garantit aux clients API éligibles que les invites et les réponses du modèle ne sont pas conservées après le traitement de la requête. Elle précise également que le contenu des clients n'est pas accessible au personnel d'OpenAI pour examen, et que les données des clients entreprise ne sont pas utilisées pour entraîner les modèles d'OpenAI, sauf si le client y consent explicitement.

La nouveauté, c'est Private Safety Processing. OpenAI le décrit comme un système conçu pour identifier des schémas à travers des interactions liées, sans donner au personnel d'OpenAI accès au contenu sous-jacent. Cette formulation compte. Le défi est que certains schémas d'usage abusif ne se manifestent pas dans une seule invite. Les agents de longue durée, les systèmes de génération de code, les opérateurs de navigateur et les flux de recherche en plusieurs étapes peuvent sembler inoffensifs à un tour donné, mais risqués sur l'ensemble d'une session.

La documentation de la plateforme OpenAI rend déjà la limite opérationnelle plus concrète. Les clients approuvés peuvent configurer le Modified Abuse Monitoring ou la rétention nulle des données au niveau de l'organisation et du projet. La documentation précise également que, sous ZDR, le paramètre store pour /v1/responses et /v1/chat/completions est toujours traité comme false, même si une requête tente de le définir sur true.

Ce dernier point est facile à manquer. Si votre application dépend d'un état stocké côté fournisseur, de traces ou de conversations rejouables, la ZDR peut changer le comportement. Vous devez concevoir votre propre couche d'état, votre propre piste d'audit, votre stratégie de rédaction des données sensibles et vos contrôles de suppression, plutôt que de supposer que le fournisseur conservera pour vous un contexte de débogage utile.

Le point de vue indépendant

Axios a présenté l'annonce comme OpenAI dévoilant en avant-première un système de sécurité à rétention nulle, alors qu'Anthropic exige des journaux pour certains usages de modèles avancés. Axios a également rapporté que le nouveau système de sécurité d'OpenAI est actuellement conçu pour les clients entreprise et API éligibles, et non pour les formules d'abonnement grand public de ChatGPT.

Computerworld a couvert la même semaine d'annonces d'OpenAI dans le cadre d'un effort plus large en matière de sécurité et de confidentialité, y compris la déclaration d'OpenAI selon laquelle elle avait temporairement ralenti certains travaux de mise à l'échelle de ses modèles de pointe et suspendu l'apprentissage par renforcement sur ses derniers modèles destinés au déploiement, le temps de renforcer ses environnements de recherche et ses systèmes de surveillance.

La comparaison avec Anthropic est pertinente car elle montre où va le marché. La documentation de confidentialité d'Anthropic indique que les invites et les sorties des « modèles couverts » sont conservées pendant 30 jours pour appuyer les travaux de sécurité, y compris pour les organisations qui disposaient d'accords ZDR sur les surfaces concernées. Anthropic précise que cela s'applique aux modèles de la classe Mythos et aux futurs modèles qu'elle désignera comme ayant des capacités similaires.

Reuters, via Investing.com, a rapporté le 20 août qu'Anthropic prévoit de donner aux clients entreprise davantage de contrôle en permettant aux données conservées pendant les 30 jours requis de résider dans l'infrastructure cloud du client lui-même, tout en maintenant l'obligation de rétention. Ce n'est pas la même chose que la ZDR, mais cela laisse entrevoir un compromis probable : des preuves de sécurité exigées par le fournisseur, un stockage contrôlé par le client.

Ce que cela change en pratique

Premièrement, ne traitez pas la « ZDR » comme un label générique de fournisseur. Considérez-la comme une propriété spécifique à chaque fournisseur, chaque produit, chaque point de terminaison, et parfois à chaque modèle. Un sélecteur de modèle dans votre application ne devrait pas se limiter à connaître model, price et latency. Il devrait connaître la classe de rétention, le statut de consentement à l'entraînement, le comportement de surveillance des abus, le comportement de stockage d'état, la région, la couverture contractuelle, et si un point de terminaison donné est éligible.

Deuxièmement, séparez l'état d'inférence de l'état d'audit. Si vous fonctionnez sous ZDR, le fournisseur ne doit pas être votre magasin de mémoire. Conservez le minimum d'état applicatif dont vous avez besoin, chiffrez-le, attachez-y des calendriers de rétention, et rendez la suppression effective. Pour le débogage, stockez des événements structurés plutôt que des invites brutes chaque fois que possible : identifiants de requête, décisions de politique, version du modèle, noms des outils, latence, nombre de tokens, et classes d'erreurs expurgées.

Troisièmement, partez du principe que les systèmes de sécurité deviendront de plus en plus conscients de la session dans son ensemble. C'est une bonne chose pour la prévention des abus, mais cela soulève des questions d'audit. Si un fournisseur affirme pouvoir détecter des schémas risqués entre interactions sans conserver le contenu, les acheteurs en entreprise devraient demander quel signal est émis, qui peut le voir, combien de temps il persiste, s'il est vérifiable par le client, et s'il peut être exporté vers le SIEM ou le flux GRC du client.

Quatrièmement, mettez à jour votre couche d'abstraction fournisseur. De nombreuses équipes cachent encore leurs fournisseurs de LLM derrière une simple fonction generate(). Ce n'est plus suffisant. L'abstraction doit porter des métadonnées de politique et refuser tout routage non sécurisé. Par exemple, une requête contenant du code source issu d'un dépôt privé, des données médicales protégées (PHI), des données financières non publiées, ou des transcriptions de support client devrait échouer par défaut (fail closed) si le modèle ciblé n'est pas approuvé pour cette catégorie de données.

Cinquièmement, testez le comportement sous store: false. Si votre application a été construite dans un environnement de développement où les conversations, les traces, les fichiers ou les sorties étaient stockés par défaut, exécutez un mode proche de la ZDR en pré-production (staging). Vous voulez découvrir les rejeux d'évaluation cassés, les diagnostics de support manquants, les rapports de bugs non reproductibles, et les dépendances accidentelles aux tableaux de bord du fournisseur, avant que les équipes juridiques ou sécurité n'imposent le changement.

Mon avis pour les équipes d'ingénierie

Ce n'est pas une solution miracle en matière de confidentialité. OpenAI n'a pas publié suffisamment de détails techniques pour permettre à des tiers de vérifier pleinement Private Safety Processing. L'annonce ne contient ni schéma de signal public, ni format d'attestation, ni rapport d'audit indépendant. Je ne présenterais donc pas cela en interne comme un problème « résolu ».

Mais il s'agit d'une évolution significative, car elle reconnaît la réalité du travail d'IA en entreprise. L'ancien compromis était simple et douloureux : soit conserver une rétention nulle et accepter une surveillance des abus plus faible côté fournisseur, soit autoriser la rétention et créer un problème de gouvernance des données plus important. OpenAI affirme vouloir emprunter une troisième voie.

Cette voie ne sera crédible que si les clients peuvent l'examiner. En pratique, je demanderais quatre éléments avant de faire migrer des charges de travail hautement sensibles vers un modèle de pointe selon ce schéma : un langage contractuel qui correspond à la documentation technique, des preuves d'éligibilité au niveau du point de terminaison, un examen de sécurité indépendant ou des artefacts d'audit, et un processus d'incident clair pour les signaux de sécurité qui n'expose pas inutilement le contenu brut des clients.

Il faut aussi surveiller la pression concurrentielle ici. Si Anthropic évolue vers une rétention dans le cloud du client pour les modèles couverts, et qu'OpenAI pousse le traitement de sécurité privé avec la ZDR, l'architecture de l'IA en entreprise va ressembler davantage à de la journalisation réglementée et à de la gestion de clés qu'à une adoption SaaS classique. Le schéma gagnant pourrait être des preuves contrôlées par le client, combinées à des signaux de sécurité compatibles avec le fournisseur.

Liste de mise en œuvre

Commencez par dresser l'inventaire des destinations actuelles de vos appels d'IA. Incluez les appels API directs, les SDK intégrés aux produits, les agents de code, les agents de navigateur, les outils de support, les tâches d'enrichissement de données, et les automatisations des employés. Les appels d'IA fantômes (shadow AI) sont ceux qui risquent le plus de faire fuiter des données vers un mode de rétention que personne n'a approuvé.

Ensuite, classifiez les invites et les sorties. Une invite peut contenir des données clients, des secrets, du code source, des identifiants dans des traces de pile, du langage contractuel, des informations médicales, des informations financières, ou des détails d'incidents internes. La sortie peut elle aussi devenir sensible si le modèle résume ou transforme une entrée protégée.

Ajoutez ensuite une passerelle de politique avant le routage vers le fournisseur. Cette passerelle doit savoir quels fournisseurs et modèles sont approuvés pour chaque catégorie de données. Elle doit journaliser la décision sans journaliser le contenu sensible brut. Si aucune route approuvée n'existe, elle doit bloquer la requête ou exiger un flux explicite de type « bris de glace » (break-glass).

Enfin, veillez à ce que les achats et l'ingénierie plateforme partagent la même source de vérité. Le contrat, la documentation du fournisseur et la configuration d'exécution doivent concorder. Si le contrat prévoit la ZDR mais que le projet est configuré pour une rétention par défaut, le contrat ne protégera pas vos données.

En résumé

L'annonce d'OpenAI du 19 août n'est pas un simple message marketing sur la confidentialité. C'est un signe que l'accès aux modèles de pointe, la surveillance de sécurité et la rétention des données en entreprise deviennent des systèmes couplés. Pour les ingénieurs sur le terrain, la bonne réponse n'est ni l'enthousiasme excessif ni la panique. La bonne réponse consiste à rendre la politique de rétention exécutable dans votre architecture.

Si votre plateforme d'IA ne peut pas répondre à la question « où cette invite est-elle allée, sous quel mode de rétention, avec quel modèle, et avec quel état stocké », elle n'est pas prête pour une utilisation en production sur des données sensibles.

Sources

• OpenAI: Offering Zero Data Retention for frontier models
• OpenAI platform docs: Data controls in the OpenAI platform
• Axios: OpenAI previews zero-retention safety system as Anthropic requires data logs
• Computerworld: OpenAI temporarily slows scaling efforts and promises ZDR for select frontier model customers
• Anthropic Privacy Center: Data retention practices for Covered Models
• Reuters via Investing.com: Anthropic plans to change enterprise data retention policy