Activer le mode de rétention zéro pour le contenu de l’IA

Pour activer le mode de rétention zéro pour les contenus d’IA de manière responsable, commencez par définir ce que couvre réellement la « rétention zéro ». OpenAI décrit la rétention zéro des données (Zero Data Retention, ZDR) comme l’engagement selon lequel les requêtes et les réponses des modèles des clients API éligibles ne sont pas conservées après le traitement d’une demande. OpenAI indique également que les contenus des clients soumis à la ZDR ne sont pas accessibles à son personnel à des fins d’examen, tandis que les données des entreprises clientes ne sont pas utilisées pour entraîner les modèles, sauf si le client choisit explicitement d’y participer.

Cette définition est importante, mais l’activation de la ZDR ne constitue pas une stratégie de confidentialité reposant sur un simple interrupteur. L’éligibilité, la configuration de l’organisation et des projets, la compatibilité des points de terminaison, le comportement de l’état de l’application, l’observabilité, la journalisation interne et les éléments de preuve de conformité influencent tous le résultat. Une mise en œuvre digne de confiance associe donc les contrôles documentés d’OpenAI à une architecture applicative rigoureuse, à la minimisation des données, aux tests et à une gouvernance continue.

Comprendre ce que signifie, et ne signifie pas, la rétention zéro des données

La politique standard de conservation des données de l’API d’OpenAI et la rétention zéro des données sont deux politiques différentes. Selon la politique par défaut de l’API décrite par OpenAI, les entrées et les sorties de l’API sont supprimées après 30 jours, sauf si l’entreprise est légalement tenue de les conserver. La ZDR est une option supplémentaire proposée aux clients éligibles et pour les points de terminaison pris en charge ; il ne s’agit pas simplement d’un autre nom pour désigner la politique par défaut de 30 jours.

Pour les cas d’utilisation approuvés, la ZDR modifie la manière dont les contenus des clients sont traités après leur traitement. OpenAI indique que les requêtes et les réponses des modèles ne sont pas conservées une fois la demande terminée et que ces contenus ne sont pas accessibles à son personnel à des fins d’examen. Cela peut réduire considérablement la quantité de contenus clients détenus par le fournisseur du modèle.

Règle opérationnelle : considérez la ZDR comme un contrôle de conservation précisément délimité du côté du fournisseur, et non comme la preuve que l’ensemble du flux de travail d’IA ne conserve aucune donnée où que ce soit.

Votre application peut toujours créer des copies avant ou après une requête API. Les serveurs web, les passerelles API, les systèmes de traçage, le stockage des navigateurs, les systèmes de gestion de contenu, les plateformes d’analyse, les outils d’assistance, les systèmes de suivi des erreurs, les sauvegardes et les appareils des employés peuvent tous conserver des contenus d’IA indépendamment du fournisseur du modèle.

Par exemple, une application éditoriale peut envoyer un brouillon confidentiel à un point de terminaison compatible avec la ZDR, tout en écrivant également l’intégralité de la requête dans un journal interne de débogage. La requête du côté du fournisseur pourrait respecter la ZDR, alors même que le système dans son ensemble continuerait à conserver le brouillon. Il s’agirait d’une défaillance de l’architecture et de la gouvernance, même si le paramètre de l’API était lui-même correct.

Distinguer quatre concepts souvent confondus

• Traitement des requêtes : le modèle doit traiter la requête et générer une réponse. La rétention zéro ne signifie pas l’absence de traitement.
• Conservation par le fournisseur : la ZDR détermine si OpenAI conserve les requêtes et les réponses après leur traitement pour les configurations éligibles et les fonctionnalités compatibles.
• Entraînement des modèles : OpenAI indique que les données des entreprises clientes ne sont pas utilisées pour entraîner les modèles, sauf si le client choisit explicitement d’y participer. Cet aspect concerne la confidentialité, mais il est distinct de la durée de conservation des requêtes.
• Conservation par l’application : vos propres systèmes et fournisseurs peuvent stocker des documents sources, des requêtes, des réponses, des métadonnées ou des contenus dérivés conformément à des politiques distinctes.

Cette distinction permet d’apporter une réponse plus précise lorsque les équipes juridiques, de sécurité ou chargées des achats demandent si les contenus d’IA sont conservés. Au lieu d’affirmer que « rien n’est stocké », documentez quelle partie traite chaque catégorie de données, où des copies peuvent être créées, quelle règle de conservation s’applique et quel contrôle technique la fait respecter.

Confirmer l’éligibilité de l’organisation et du cas d’utilisation

OpenAI ne présente pas la ZDR comme une option universelle disponible pour tous les comptes. Ses informations relatives à la confidentialité des entreprises indiquent que les organisations admissibles peuvent configurer des politiques de conservation, notamment une politique de rétention zéro des données, par l’intermédiaire de la plateforme API. Cette option est réservée aux clients API éligibles et aux cas d’utilisation admissibles.

La première tâche de mise en œuvre consiste donc à examiner l’éligibilité, et non à modifier la configuration de production. Contactez le canal approprié de gestion de compte ou d’assistance d’OpenAI et décrivez précisément le flux de travail envisagé. Évitez de décrire uniquement l’exemple présentant le moins de risques si le trafic de production doit contenir des informations plus sensibles ou utiliser des fonctionnalités supplémentaires.

Préparer une description claire du cas d’utilisation

Un dossier d’examen utile doit expliquer le service sans transmettre inutilement de contenus clients. Il peut inclure :

• La finalité de la fonctionnalité d’IA et les utilisateurs prévus.
• Les catégories de contenus susceptibles d’apparaître dans les requêtes, les pièces jointes et les réponses.
• La présence éventuelle d’informations réglementées, confidentielles, personnelles, médicales ou propriétaires.
• Les modèles, points de terminaison API, outils et modes de réponse que l’application prévoit d’utiliser.
• Le caractère synchrone, multitour, agentique ou dépendant d’un traitement en arrière-plan du flux de travail.
• Les projets, environnements et unités organisationnelles qui nécessitent la ZDR.
• Les règles internes de conservation et de suppression qui s’appliquent en dehors d’OpenAI.

L’avenant d’OpenAI relatif aux soins de santé fournit une définition particulièrement explicite d’une « API à rétention zéro » : les contenus des clients sont traités sans être enregistrés, conservés ou journalisés en vue d’un examen humain. Cette formulation peut aider une organisation de santé à comprendre le comportement attendu du fournisseur, mais elle ne doit pas être généralisée au point d’affirmer que chaque point de terminaison, compte ou flux de travail médical est automatiquement couvert. Les conditions contractuelles, le statut d’approbation et la documentation actuelle des points de terminaison restent déterminants.

Ne pas supposer que l’approbation du compte rend toutes les fonctionnalités compatibles

OpenAI avertit que tous les points de terminaison ou toutes les fonctionnalités ne sont pas compatibles avec la ZDR. Certaines fonctionnalités peuvent stocker l’état de l’application, même lorsqu’une organisation a activé une politique de rétention zéro. Le mode en arrière-plan en est un exemple documenté : il est incompatible avec la ZDR, car les données de réponse sont stockées brièvement afin que l’application puisse interroger le système pour obtenir le résultat.

Cela signifie que l’éligibilité doit être évaluée à plusieurs niveaux. Une organisation peut être approuvée pour la ZDR tandis qu’un flux de travail particulier reste inadapté parce qu’il utilise un point de terminaison incompatible ou une fonctionnalité avec état. L’approche la plus sûre consiste à maintenir une liste d’autorisation explicite des modèles, points de terminaison, modes et outils approuvés, plutôt que de supposer que le paramètre de l’organisation couvre toutes les opérations de l’API.

Configurer la ZDR aux niveaux de l’organisation et des projets

La documentation de la plateforme OpenAI indique que les organisations approuvées peuvent choisir la rétention zéro des données ou la surveillance modifiée des abus au niveau de l’organisation, puis configurer le comportement pour chaque projet. Cette hiérarchie est importante, car les applications de production sont souvent réparties entre plusieurs projets, environnements, unités opérationnelles ou classifications de données.

Les libellés exacts de l’interface et les options disponibles peuvent changer à mesure que la plateforme évolue. La documentation actuelle de la plateforme OpenAI doit donc constituer la source de référence lors de la mise en œuvre. Le processus suivant se concentre sur des objectifs de contrôle durables, sans supposer une disposition précise de l’interface.

1. Obtenir et consigner l’approbation. Confirmez que la bonne organisation API est éligible à la ZDR et que le cas d’utilisation prévu entre dans le périmètre approuvé. Conservez la preuve d’approbation ou les éléments contractuels dans le référentiel de conformité de l’organisation.
2. Inventorier les organisations et les projets. Identifiez chaque organisation et chaque projet OpenAI utilisés par les équipes de développement, de test, de préproduction, de production, de science des données et d’assistance. Il ne faut pas supposer qu’un paramètre appliqué à un projet couvre les autres.
3. Choisir la politique au niveau de l’organisation. Pour une organisation approuvée, sélectionnez la politique documentée de rétention zéro des données lorsqu’elle est appropriée. Comprenez la distinction entre la ZDR et la surveillance modifiée des abus avant d’effectuer ce choix.
4. Examiner chaque projet. Définissez ou vérifiez le comportement de chaque projet en fonction des données qu’il traite. Les charges de travail hautement sensibles ne doivent pas partager un projet configuré de manière ambiguë avec des expérimentations soumises à des exigences de conservation différentes.
5. Cartographier toutes les opérations de l’API. Répertoriez le point de terminaison, le modèle, les outils, les modes, la gestion des fichiers, le comportement de l’état et toutes les fonctionnalités agentiques utilisés par chaque parcours applicatif. Vérifiez chaque élément par rapport à la documentation actuelle sur la compatibilité avec la ZDR.
6. Supprimer les comportements incompatibles. Repensez les appels qui dépendent de fonctionnalités avec état non prises en charge. En particulier, n’utilisez pas le mode en arrière-plan dans un flux de travail présenté comme compatible avec la ZDR lorsque la documentation indique que ce mode est incompatible.
7. Restreindre les identifiants et les accès. N’accordez aux services que l’accès aux projets et aux fonctionnalités dont ils ont besoin. Cela réduit le risque qu’une charge de travail soumise à la ZDR soit redirigée silencieusement vers un projet non approuvé.
8. Tester la configuration dans un environnement contrôlé. Vérifiez les identifiants des projets, les chemins des requêtes, la gestion des erreurs, les nouvelles tentatives et les mécanismes de repli sans placer de contenus de production sensibles dans les journaux de test.
9. Approuver la mise en production. Exigez que les équipes chargées de la confidentialité, de la sécurité et de l’ingénierie, ainsi que le propriétaire des données concernées, confirment que la configuration documentée correspond à l’architecture déployée.
10. Surveiller les dérives. Vérifiez à nouveau la politique lors de l’ajout d’un modèle, d’un point de terminaison, d’un outil, d’un projet, d’une intégration ou d’une nouvelle catégorie de contenus.

La conception au niveau des projets est particulièrement utile pour faire respecter les limites. Une entreprise peut isoler un service sensible de traitement de documents dans un projet approuvé, tout en maintenant le prototypage à faible risque dans un autre. Cette séparation facilite l’examen des accès, l’attribution des coûts, le contrôle des déploiements et la constitution de preuves de conformité, même si elle ne remplace pas les vérifications de compatibilité au niveau des points de terminaison.

Définir une politique de défaillance sûre

Les erreurs de configuration doivent provoquer une fermeture sécurisée lorsque les contenus nécessitent la ZDR. Si le projet approuvé est indisponible, l’application ne doit pas automatiquement acheminer les requêtes sensibles vers un projet soumis à la conservation standard dans le seul but de préserver la disponibilité. Tout mécanisme de repli modifiant la politique de conservation doit être considéré comme un changement substantiel et faire l’objet d’une approbation explicite.

Le même principe s’applique aux mécanismes de repli fonctionnels. Si une requête synchrone échoue, le passage silencieux au mode en arrière-plan serait contraire à une exigence de ZDR, car OpenAI indique que ce mode est incompatible. Les objectifs de disponibilité doivent être mis en balance avec l’engagement de confidentialité annoncé, et non le remplacer de manière invisible.

Concevoir l’ensemble du parcours des contenus d’IA pour une conservation minimale

La configuration du fournisseur ne constitue qu’une couche d’une architecture à rétention zéro. Pour activer le mode de rétention zéro pour les contenus d’IA de manière significative, suivez les contenus depuis leur collecte jusqu’à leur prétraitement, leur transmission, le traitement de la réponse, leur affichage et leur élimination. Chaque composant de ce parcours doit avoir une finalité et une règle de conservation définies.

Réduire au minimum les contenus avant l’appel à l’API

N’envoyez que les informations nécessaires à l’exécution de la tâche. Si un modèle doit classer un paragraphe, il n’a peut-être pas besoin du nom de l’auteur, de l’historique complet du document, du numéro de compte ou de pièces jointes sans rapport avec la tâche. La suppression des champs inutiles réduit l’exposition, quel que soit le paramètre de conservation du fournisseur.

Lorsque cela est approprié, les applications peuvent remplacer les identifiants directs par des références internes avant la transmission. La correspondance doit rester dans un système distinct soumis à des contrôles spécifiques et ne doit pas être incluse dans la requête. L’occultation doit être testée avec le format réel des contenus, car des informations sensibles peuvent apparaître dans du texte libre, des noms de fichiers, des expéditeurs, des images, des métadonnées ou l’historique cité d’une conversation.

Contrôler les journaux et les traces

De nombreux cadres de développement d’IA enregistrent les requêtes et les réponses afin d’aider les développeurs à résoudre les problèmes de qualité. Ce comportement est utile dans un environnement de laboratoire, mais peut compromettre un objectif de rétention zéro en production. Vérifiez si la journalisation HTTP, le traçage distribué, la surveillance des performances applicatives, le signalement des erreurs, les analyses et les pipelines d’évaluation capturent l’intégralité des requêtes ou des réponses.

• Ne journalisez les identifiants de requête, les durées, les noms de modèles, les codes d’état et les métadonnées opérationnelles liées aux jetons que lorsque cela est nécessaire.
• Désactivez la capture pour les routes sensibles.
• Nettoyez les messages d’exception et les champs contextuels des piles d’appels.
• Évitez de placer des extraits de requêtes dans les titres d’alertes ou les outils de collaboration.
• Appliquez des contrôles d’accès et des règles de suppression aux métadonnées restantes.
• Vérifiez si les appels ayant échoué, les nouvelles tentatives et les expirations génèrent des journaux plus détaillés que les appels réussis.

N’affirmez pas que toute journalisation disparaît. OpenAI indique que des journaux de sécurité et de conformité peuvent exister en dehors de la conservation des contenus clients. Ses API de conformité conservent les journaux pendant 30 jours, et les demandes de suppression sont conservées en interne pendant une durée maximale de 30 jours à des fins d’audit et de sécurité. Ces éléments renforcent la nécessité de préciser si une déclaration concerne les requêtes et les réponses des clients, les métadonnées opérationnelles, les dossiers de conformité ou les traces d’audit relatives aux suppressions.

Gérer délibérément les contenus générés

La ZDR n’empêche pas votre application d’enregistrer la réponse du modèle. Une plateforme de gestion de contenu peut stocker intentionnellement un brouillon généré, tandis qu’un outil de synthèse temporaire peut afficher un résultat puis le supprimer. Les deux conceptions peuvent utiliser la ZDR du côté du fournisseur, mais leurs conséquences sur la conservation au niveau de l’application sont différentes.

Indiquez si les contenus générés sont temporaires, sous le contrôle de l’utilisateur ou constituent des documents officiels de l’entreprise. S’ils sont enregistrés, définissez leur emplacement de stockage, leur propriétaire, leur politique d’accès, leur durée de conservation, leur processus de suppression et leur traitement dans les sauvegardes. Présenter une application comme étant « à rétention zéro » serait trompeur si elle stocke intentionnellement toutes les réponses de manière indéfinie.

Tenir compte de l’état des points de terminaison et des flux de travail agentiques

Les applications d’IA modernes peuvent aller au-delà d’une simple requête suivie d’une simple réponse. Les interactions multitours, les appels d’outils, la continuité du raisonnement et les processus agentiques peuvent dépendre d’un état. Cet état doit être évalué séparément plutôt que supposé relever d’une simple interprétation de type requête-réponse.

OpenAI a poursuivi en 2026 ses travaux sur des produits liés à la ZDR. Une publication récente d’OpenAI consacrée aux modèles de pointe indique que la ZDR peut prendre en charge de nouveaux flux de travail agentiques, notamment des réponses qui maintiennent des éléments de raisonnement d’un tour à l’autre grâce à un état chiffré. L’annonce d’OpenAI du 19 août 2026 présente également de nouveaux systèmes de sécurité comme un « traitement privé de la sécurité » et indique qu’ils sont proposés en avant-première tout en restant compatibles avec la ZDR.

Ces évolutions montrent que les flux de travail sophistiqués et la ZDR ne sont pas nécessairement incompatibles. Elles n’établissent toutefois pas une compatibilité universelle pour chaque agent, point de terminaison, outil ou mécanisme d’état. Les équipes doivent vérifier la combinaison précise qu’elles prévoient de déployer par rapport à la documentation actuelle et à la configuration approuvée de leur compte.

Poser des questions propres à l’état

• Quel état est créé pendant le flux de travail ?
• Est-il détenu par le fournisseur, l’application du client ou un autre prestataire ?
• L’état constitue-t-il un contenu client, un état chiffré du flux de travail, une métadonnée opérationnelle ou un enregistrement applicatif ?
• Pendant combien de temps chaque composant a-t-il besoin de cet état ?
• Le point de terminaison et le mode sont-ils explicitement documentés comme compatibles avec la ZDR ?
• L’interrogation du système nécessite-t-elle un stockage temporaire de la réponse ?
• Le flux de travail peut-il fonctionner sans stocker l’intégralité des requêtes et des réponses dans des journaux contrôlés par le client ?

Le mode en arrière-plan mérite un contrôle distinct, car sa méthode d’interrogation stocke brièvement les données de réponse et n’est donc pas compatible avec la ZDR, selon OpenAI. Une revue du code doit rechercher les paramètres explicites du mode en arrière-plan, ainsi que les enveloppes logicielles ou les kits de développement susceptibles d’activer indirectement ce comportement.

Pour les flux de travail agentiques utilisant un état chiffré, la déclaration doit rester précise : les travaux d’OpenAI cités indiquent que ce mécanisme peut préserver des éléments de raisonnement d’un tour à l’autre lors de la création de solutions avec la ZDR. Cela ne justifie pas de présenter chaque agent avec état comme étant à rétention zéro. Consignez le modèle pris en charge, le point de terminaison, le mécanisme d’état, la politique du projet et la version de la documentation examinée pour la mise en production.

Gérer les compromis en matière de gouvernance et de partage des données

Le centre d’aide d’OpenAI indique que les organisations ayant activé la rétention zéro des données ne peuvent pas choisir de participer au partage des données. Elles ne peuvent pas participer aux programmes de partage de données concernant les commentaires, les évaluations ou l’ajustement fin tant que la ZDR est activée. Il s’agit d’une conséquence importante en matière de gouvernance, et non d’une préférence mineure du compte.

Les équipes habituées à renvoyer des exemples de production à un fournisseur à des fins d’évaluation ou d’amélioration ont besoin d’un processus qualité différent. Elles peuvent toujours évaluer leur propre application, mais le jeu de données, les outils, les autorisations et les règles de conservation doivent être gérés dans leur environnement autorisé et respecter les contrats et politiques applicables.

Mettre en place un processus d’évaluation respectueux de la confidentialité

Un processus interne pratique peut utiliser des cas de test approuvés, synthétiques, désidentifiés ou spécifiquement autorisés. Les examinateurs humains ne doivent voir que les contenus nécessaires à leur rôle, et les résultats d’évaluation doivent être soumis à une durée de conservation documentée. Si de véritables exemples de clients sont nécessaires, obtenez la base juridique appropriée et l’approbation interne au lieu de considérer la ZDR comme une autorisation générale.

L’impossibilité de participer aux programmes d’OpenAI de partage de données pour les commentaires, les évaluations ou l’ajustement fin doit être prise en compte dans les plans techniques et produit. Une équipe ne doit pas activer la ZDR tout en concevant simultanément une exportation automatisée des requêtes vers un canal de partage de données du fournisseur. Cela serait contraire à la restriction documentée du compte ainsi qu’à l’objectif de confidentialité qui sous-tend cette configuration.

Principe de gouvernance : l’amélioration de la qualité du modèle ne doit pas modifier silencieusement la destination, la finalité ou la durée de conservation approuvées des contenus sensibles.

Attribuez la responsabilité de ce compromis. L’équipe d’ingénierie peut gérer la configuration de l’API, mais l’équipe chargée de la confidentialité doit définir les usages acceptables des données, l’équipe de sécurité doit examiner les contrôles, l’équipe juridique ou de conformité doit interpréter les obligations et les responsables produit doivent déterminer si la fonctionnalité peut répondre aux exigences de qualité sans partage de données avec le fournisseur.

Utiliser un langage précis à destination des utilisateurs

Un avis de confidentialité, un document commercial ou un message d’interface doit éviter les affirmations absolues telles que « vos données ne sont jamais stockées nulle part ». Une description plus défendable précise la limite : les requêtes éligibles sont traitées au moyen d’une configuration de l’API OpenAI selon laquelle OpenAI ne conserve ni les requêtes ni les réponses des modèles après leur traitement, tandis que les pratiques de stockage propres à l’application sont décrites séparément.

Toute déclaration publique doit correspondre au parcours réel en production. Si certains projets utilisent la conservation standard de l’API, si certains points de terminaison sont incompatibles ou si les brouillons générés sont enregistrés dans le compte du client, expliquez ces différences. La confiance repose sur des limites précises, et non sur la fusion de plusieurs politiques en une vaste promesse marketing.

Valider le déploiement et conserver les preuves

Les contrôles de confidentialité nécessitent des preuves. Une simple capture d’écran de la configuration ne suffit pas, car elle ne démontre pas que le trafic de production utilise l’organisation, le projet et le point de terminaison compatible prévus. Inversement, les tests de l’application ne prouvent pas à eux seuls que le fournisseur a approuvé et configuré le compte pour la ZDR.

Constituez un dossier de preuves associant des documents administratifs, architecturaux et opérationnels. Évitez d’y inclure inutilement le contenu des requêtes.

1. Preuve d’approbation : conservez la confirmation applicable d’OpenAI, la documentation du compte, les éléments contractuels ou tout autre document faisant autorité qui atteste l’éligibilité à la ZDR.
2. Preuve de configuration : consignez la politique de l’organisation et le comportement pertinent de chaque projet. Indiquez la date de l’examen et le responsable.
3. Preuve de compatibilité : identifiez la documentation utilisée pour confirmer que chaque modèle, point de terminaison, mode et fonctionnalité prend en charge la ZDR.
4. Preuve architecturale : tenez à jour un diagramme des flux de données couvrant les entrées utilisateur, le prétraitement, la transmission à l’API, le traitement des réponses, le stockage interne, l’observabilité et la suppression.
5. Preuve relative au code : examinez la façon dont l’application sélectionne les identifiants des projets, les points de terminaison, les modes de requête, les outils, les nouvelles tentatives et les mécanismes de repli.
6. Preuve relative à la journalisation : démontrez que les corps sensibles des requêtes et des réponses ne sont pas copiés dans des journaux, des traces, des alertes ou des systèmes d’évaluation non approuvés.
7. Preuve par les tests : utilisez des marqueurs non sensibles pour vérifier les emplacements de stockage contrôlés par l’application et confirmer l’acheminement attendu, sans prétendre accéder aux systèmes du fournisseur que vous ne pouvez pas inspecter.
8. Preuve de mise en production : consignez l’approbation des responsables désignés de l’ingénierie, de la sécurité, de la confidentialité et des données.

Tester les parcours négatifs, et pas seulement les requêtes réussies

Les défaillances en matière de confidentialité apparaissent souvent lors des exceptions. Simulez des échecs d’autorisation, des limitations de débit, des erreurs de point de terminaison, des expirations réseau, des erreurs d’analyse et l’indisponibilité de dépendances avec des entrées non sensibles. Vérifiez si l’intergiciel de débogage capture les corps des messages ou si le système achemine les requêtes vers un mécanisme de repli non soumis à la ZDR.

Testez également la séparation des projets. Un service destiné à un projet soumis à la ZDR doit refuser les identifiants ou les configurations appartenant à un environnement non approuvé. Les modèles de déploiement peuvent valider les identifiants des projets, tandis que les contrôles de gestion des changements peuvent imposer un examen lorsque ces identifiants sont modifiés.

Être honnête sur ce qui peut être vérifié

Les clients ne peuvent généralement pas inspecter directement le stockage interne d’un fournisseur. L’assurance repose donc sur les engagements documentés du fournisseur, les accords applicables, la configuration du compte, la documentation de compatibilité et les propres contrôles techniques du client. Ne présentez pas un test côté client comme la preuve de tous les processus internes du fournisseur.

OpenAI associe la ZDR à des contrôles plus larges de confidentialité et de conformité destinés aux entreprises, notamment le chiffrement, les contrôles de conservation et les options de résidence des données pour les organisations admissibles. Ces contrôles peuvent contribuer à un programme de conformité, mais aucun ne doit être considéré comme une certification automatique indiquant qu’une application particulière respecte toutes les exigences légales.

Intégrer la ZDR à la conformité et aux opérations continues

La ZDR peut réduire la conservation des contenus du côté du fournisseur et favoriser les objectifs de minimisation des données. La conformité dépend néanmoins du contexte : le type de données, le droit applicable, les engagements contractuels, les attentes des utilisateurs, le rôle de l’organisation, l’emplacement, les mesures de sécurité et le comportement de chaque responsable du traitement ou sous-traitant impliqué dans le flux de travail.

Une déclaration de contrôle défendable doit être précise. Elle peut indiquer qu’une organisation API OpenAI approuvée utilise la ZDR pour les projets répertoriés et les points de terminaison compatibles, tandis que le stockage interne des contenus suit un calendrier distinct. Elle doit également mentionner les exclusions pertinentes, telles que le mode en arrière-plan, les enregistrements applicatifs ou les informations opérationnelles d’audit.

Maintenir un registre de contrôle évolutif

• Nommer les responsables métier et techniques.
• Répertorier les organisations, projets, modèles, points de terminaison et fonctionnalités approuvés.
• Consigner les modes interdits, notamment le mode en arrière-plan lorsque la ZDR est requise.
• Décrire les règles internes de journalisation et de stockage des réponses.
• Documenter la restriction relative au partage de données avec OpenAI pour les commentaires, les évaluations et l’ajustement fin.
• Référencer la documentation du fournisseur et les accords examinés.
• Définir des déclencheurs d’examen liés aux changements de produit, et pas uniquement un examen périodique.

Les déclencheurs d’examen utiles comprennent l’adoption d’un nouveau modèle de pointe, l’ajout d’outils, l’activation d’un état multitour, le changement de kit de développement, la création d’un projet, la modification de l’observabilité, l’introduction d’un mécanisme de repli ou l’extension à une nouvelle catégorie de données. Les travaux d’OpenAI réalisés en 2026 sur l’état chiffré et le traitement privé de la sécurité montrent pourquoi les contrôles doivent évoluer à mesure que les flux de travail pris en charge changent.

La réponse aux incidents doit également distinguer la conservation par le fournisseur des fuites du côté du client. Si des requêtes apparaissent dans une trace interne, la désactivation de cette trace et la suppression des copies non autorisées peuvent constituer la priorité immédiate, même lorsque la ZDR d’OpenAI reste correctement configurée. Si le trafic a été acheminé par un mode incompatible ou vers le mauvais projet, suspendez le parcours concerné, conservez si possible les preuves ne contenant pas de contenus, évaluez l’étendue de l’incident et suivez les procédures de l’organisation en matière d’incidents et de notification.

Employer un langage d’audit précis

Les auditeurs et les clients peuvent demander si des « journaux » existent. Les déclarations d’OpenAI exigent une réponse nuancée : la ZDR concerne les requêtes et les réponses des modèles après leur traitement, ainsi que leur accessibilité en vue d’un examen humain, tandis que certains dossiers de sécurité, de conformité, de suppression ou d’audit peuvent faire l’objet d’un traitement distinct. OpenAI indique que les journaux de son API de conformité sont conservés pendant 30 jours et que les demandes de suppression sont conservées en interne pendant une durée maximale de 30 jours à des fins de sécurité et d’audit.

La précision renforce le discours relatif aux contrôles au lieu de l’affaiblir. Elle montre que l’organisation a examiné les différentes catégories de données au lieu de se fier à une promesse non définie. La même rigueur doit être appliquée au chiffrement et à la résidence des données : décrivez les contrôles effectivement activés, leur périmètre et les éventuelles limitations d’éligibilité ou de produit.

Créer une liste de contrôle pratique pour la production

Avant de mettre en production un flux de travail de contenus d’IA assorti d’une déclaration de rétention zéro, effectuez un examen final reliant la politique au comportement effectivement déployé. La liste de contrôle doit avoir un responsable, être reproductible et être intégrée à la gestion des versions.

• OpenAI a confirmé que l’organisation et le cas d’utilisation sont éligibles à la ZDR.
• La bonne politique de conservation est configurée au niveau de l’organisation.
• Chaque projet de production a été examiné indépendamment.
• Chaque modèle, point de terminaison, outil, mode et mécanisme d’état est documenté comme étant compatible.
• Le mode en arrière-plan n’est pas utilisé lorsque la ZDR est requise.
• Les identifiants ne peuvent pas rediriger silencieusement le trafic vers un projet soumis à la conservation standard.
• Les mécanismes de repli provoquent une fermeture sécurisée au lieu d’affaiblir la politique de conservation.
• Les requêtes et les réponses sont exclues des journaux et des traces applicatives inutiles.
• Les contenus générés et stockés par l’application ont une finalité métier explicite et une règle de conservation.
• Les options de partage de données d’OpenAI pour les commentaires, les évaluations et l’ajustement fin ne sont pas considérées comme accessibles à l’organisation soumise à la ZDR.
• Les formulations destinées aux utilisateurs et les clauses contractuelles décrivent précisément les limites du fournisseur et de l’application.
• Les preuves sont conservées sans stocker de contenus sensibles dans le seul but de démontrer que la conservation a été réduite au minimum.
• Tout changement apporté aux modèles, aux points de terminaison, au comportement des kits de développement, aux outils, aux projets ou à l’état du flux de travail déclenche un nouvel examen.

Aucune liste de contrôle ne peut remplacer la documentation actuelle. Les fonctionnalités de la plateforme évoluent, comme le montrent les travaux d’OpenAI réalisés en 2026 sur les flux de travail agentiques, l’état chiffré et le traitement privé de la sécurité compatibles avec la ZDR. Validez à nouveau la compatibilité avant toute adoption, plutôt que de supposer qu’une nouvelle fonctionnalité hérite du comportement d’un ancien point de terminaison en matière de politique.

Il est tout aussi important de ne pas exagérer ce que cette liste de contrôle permet d’obtenir. Elle peut renforcer l’assurance relative à la mise en œuvre et aider à repérer les lacunes courantes, mais la conformité juridique et l’adéquation contractuelle nécessitent l’examen de professionnels qualifiés qui comprennent les données, la juridiction, le secteur d’activité et les obligations de l’organisation.

Pour activer efficacement le mode de rétention zéro pour les contenus d’IA, associez l’approbation d’OpenAI, la configuration de l’organisation et des projets, les vérifications de compatibilité des points de terminaison, la collecte minimale de données, la maîtrise de la journalisation, des mécanismes de repli sûrs et une vérification documentée. La ZDR peut offrir un solide contrôle de confidentialité du côté du fournisseur aux clients API éligibles, mais son périmètre doit rester clair : elle concerne la conservation des requêtes et des réponses des modèles dans les conditions prises en charge, et non toutes les copies créées dans l’ensemble de l’écosystème applicatif.

La mise en œuvre la plus digne de confiance est celle qui peut expliquer ses limites sans recourir à des affirmations absolues. Consultez la documentation actuelle d’OpenAI, isolez les charges de travail approuvées, évitez les fonctionnalités incompatibles telles que le mode en arrière-plan, tenez compte des dossiers distincts de sécurité et de conformité et réévaluez la conception chaque fois que le flux de travail change. Cette approche transforme un paramètre de conservation en une pratique de confidentialité vérifiable, plutôt qu’en une simple formule marketing.