Que signifie vraiment la rétention de données « zéro » ?

« Zéro rétention de données » sonne comme une promesse parfaitement définitive. Mais cela signifie aussi des choses différentes selon le fournisseur, l’endpoint, le statut du compte, la fonctionnalité et la liste d’exceptions. Naturellement, c’est là que le fun commence à mourir.

Au minimum, les équipes devraient distinguer quatre questions. Le contenu client est-il utilisé pour l’entraînement du modèle ? Le contenu est-il stocké pour la surveillance des abus ? L’état de l’application est-il stocké pour que la fonctionnalité fonctionne ? Les entrées image et fichier sont-elles traitées différemment des textes ?

La documentation actuelle des contrôles de données de l’API d’OpenAI indique que les données d’API ne sont pas utilisées pour entraîner ou améliorer les modèles d’OpenAI, sauf si le client choisit d’y consentir. Elle décrit aussi des journaux de surveillance des abus par défaut, des contrôles de rétention tels que Modified Abuse Monitoring et Zero Data Retention pour les clients approuvés éligibles, un état d’application spécifique à l’endpoint, ainsi que des exceptions pour les entrées image/fichier dans le cadre de certaines revues de sécurité.

La documentation de confidentialité des données de Microsoft pour les Foundry Models vendus par Azure utilise sa propre structure. Elle indique que les prompts et les complétions ne sont pas disponibles pour d’autres clients, ne sont pas disponibles pour OpenAI ou d’autres fournisseurs de modèles, et ne sont pas utilisés pour entraîner des modèles de base sans autorisation ou instruction. Elle décrit également les fonctionnalités stockées, la surveillance des abus, la géographie, et les moyens par lesquels les clients approuvés peuvent vérifier quand le stockage lié à la surveillance des abus est désactivé.

La leçon n’est pas « fournisseur A bien, fournisseur B mal ». La leçon, c’est que la ZDR est une histoire de configuration et d’éligibilité, pas un slogan. Un endpoint peut être éligible. Un autre peut stocker l’état de l’application. Une fonctionnalité peut conserver jusqu’à suppression. Une autre peut conserver un état temporaire pour le polling, le cache, la sécurité ou des fenêtres de téléchargement.

Les workflows d’images rendent cela encore plus important. La génération d’images, les éditions, les entrées de fichiers, les vidéos, les jobs batch et les workflows d’étatful de type assistants peuvent avoir des comportements de stockage différents. Une réponse de procurement copiée depuis un endpoint de complétion de texte peut ne pas répondre à la question relative au téléversement d’images.

Lors de l’évaluation d’un fournisseur, demandez le tableau ennuyeux. Endpoint. Utilisation pour l’entraînement. Surveillance des abus. État de l’application. Rétention des fichiers. Rétention des images. Revue humaine. Exceptions de sécurité. API de suppression. Région. Sous-traitants. Exigences d’éligibilité pour la surveillance modifiée ou la ZDR. Les tableaux ennuyeux évitent des incidents passionnants.

Pour les produits de type Unexposed, la promesse client la plus claire n’est pas seulement « notre fournisseur a la ZDR ». C’est « notre produit est conçu pour ne pas conserver les prompts ou les images des clients, et notre fournisseur achemine cela conformément à cette promesse pour les endpoints que nous utilisons ». La promesse au niveau du produit compte, car les contrôles du fournisseur ne sont qu’une couche.

La rétention de données « zéro » est précieuse. Mais ce n’est pas non plus un tampon magique. Lisez le comportement de l’endpoint, sinon la phrase fera ce que les phrases adorent faire : sonner mieux que le système sous-jacent.

Pour aller plus loin : Contrôles de données de l’API OpenAI, Confidentialité des données Microsoft Foundry, et Le cas en faveur de zéro historique de prompts.