Pas d’utilisation pour l’entraînement
Ne signifie pas absence de conservation

OpenAI indique que les données de l’API ne servent pas à entraîner ou améliorer ses modèles, sauf partage expressément accepté par le client. Séparément, les journaux de surveillance des abus peuvent, par défaut, contenir requêtes, réponses et métadonnées dérivées et être conservés jusqu’à 30 jours, avec les exceptions décrites pour les obligations légales et la prévention des dommages. Modified Abuse Monitoring et Zero Data Retention nécessitent une autorisation préalable et des exigences supplémentaires. Les contrôles autorisés se règlent au niveau de l’organisation et du projet ; un projet peut hériter du réglage, choisir un contrôle ou le désactiver. Zero Data Retention impose store=false pour /v1/responses et /v1/chat/completions, sans rendre tous les points de terminaison ou toutes les fonctions dépourvus d’état persistant. La page décrit aussi des dispositifs propres à certains clients, Private Retention with Private Safety Processing et Safety Retention, qui peuvent modifier la protection apparente moyennant notification écrite préalable.

La page Google sélectionnée précise que l’entraînement ou l’ajustement des modèles gérés sur Gemini Enterprise Agent Platform exige une autorisation ou une instruction préalable. Les conditions de conservation de MaaS sont distinctes. La journalisation des requêtes pour surveiller les abus dépend des conditions régissant l’utilisation par le client ; une exception peut être demandée lorsqu’elle s’applique. La journalisation supplémentaire de certains modèles ou fonctions Advanced AI peut empêcher une conservation nulle. Ces indications n’établissent ni le contrat ni les exceptions de l’acheteur concerné. Ne transposez pas ces conditions Cloud à Gemini grand public et ne présumez pas qu’elles régissent un déploiement de Gemini Developer API.

Pour comparer des documents de police d’assurance, cartographiez séparément le fichier téléversé, les passages extraits, la réponse produite et la conversation enregistrée. Selon le comportement documenté par défaut ou avec store=true, /v1/responses d’OpenAI conserve normalement l’état applicatif pendant au moins 30 jours ; d’autres fonctions ont leur propre cycle de vie. Les fichiers exigent une suppression ou une expiration configurée. L’interrogation en arrière-plan, l’audio, les conteneurs et la mise en cache des requêtes appellent des vérifications distinctes. Les images et fichiers en entrée font aussi l’objet d’une exception de conservation en cas de suspicion de contenu d’abus sexuels sur mineurs, y compris avec des contrôles de conservation restreinte. Sur la plateforme Google étudiée, store vaut true par défaut dans Interactions API ; la page demande de définir explicitement false pour rechercher une conservation nulle. La journalisation des requêtes et réponses est désactivée par défaut, mais peut écrire dans une table BigQuery désignée si elle est activée par modèle et par projet. Grounding with Google Search conserve certaines requêtes dérivées et leur contexte jusqu’à trois jours, sans possibilité de désactiver ce stockage tout en utilisant la fonction ; l’ancrage avec Maps conserve les contenus indiqués pendant 30 jours. Le stockage des sessions Deep Research ne peut pas être désactivé lors de l’utilisation de cet agent. La reprise de session Live et le cache implicite ajoutent d’autres conditions. Les caches implicites pris en charge peuvent utiliser mémoire et stockage durable pendant jusqu’à 24 heures ; désactiver uniquement le cache durable laisse le cache mémoire actif. Ces durées correspondent à des parcours différents, pas à un classement des fournisseurs.

Un paramètre de point de terminaison ne décrit pas l’assistant entier. OpenAI précise que les serveurs MCP distants et les autres destinations réseau tierces appliquent leurs propres politiques de conservation. Demandez à l’équipe de mise en œuvre si le texte documentaire atteint ces destinations et inventoriez séparément journaux applicatifs, exports, index de recherche et sauvegardes. Ce sont des questions de revue, non l’affirmation que chaque déploiement crée toutes ces copies. Pour chaque destination réelle, consignez les données reçues, le responsable des accès, la règle de conservation et le mécanisme de suppression. Pour le cache Google, distinguez aussi le point de terminaison régional ou multirégional choisi du point de terminaison mondial : la page décrit des comportements de localisation différents. Recueillez les preuves de configuration sans joindre de contenu confidentiel au dossier. Une preuve manquante reste une condition ouverte ; elle ne prouve pas l’absence d’une copie.

Constituez une fiche d’acceptation pour la tâche documentaire proposée : service et point de terminaison exacts, conditions applicables, éligibilité confirmée aux contrôles de conservation, paramètres effectifs de l’organisation et du projet, fonctions activées, destinations externes et responsables de suppression. Utilisez des données de test non confidentielles pour examiner le parcours prévu et les possibilités de suppression ; une requête réussie ne démontre pas toutes les propriétés de conservation internes. Distinguez ce que les preuves du fournisseur établissent de ce qui nécessite une clarification écrite. Si une fonction indispensable contredit la politique de stockage de l’organisation, retirez-la, repensez la tâche ou laissez l’acceptation en attente. Une solution sur site exige la même revue des accès, journaux, sauvegardes et connexions ; la localisation ne crée aucune immunité. Réexaminez la fiche si les points de terminaison, les fonctions ou les conditions changent.