Entraînement du modèle vs images téléversées

Les développeurs disent souvent « nous ne l’entraînons pas » comme si cela répondait à toute la question de confidentialité.

Cela répond à une question importante. Cela ne répond pas à toutes.

Une image téléversée peut être utilisée pour l’inférence sans être utilisée pour l’entraînement. L’inférence signifie que le modèle traite l’image pour renvoyer une sortie. L’entraînement signifie que l’image modifie les poids du modèle. Le fine-tuning signifie un processus d’entraînement plus ciblé qui adapte un modèle à l’aide d’un jeu de données. La journalisation signifie que le service enregistre du contenu ou des métadonnées. L’état de l’application signifie que le service stocke des données pour qu’une fonctionnalité puisse fonctionner. Ce sont des choses différentes. Elles méritent des phrases différentes.

La confusion compte parce qu’un produit peut faire une affirmation vraie tout en exposant quand même les utilisateurs. « Nous n’entraînons pas sur les téléversements » peut être vrai pendant que des invites figurent dans des journaux pendant 30 jours, que des sorties vivent dans une galerie hébergée, que des fichiers restent dans des outils avec état jusqu’à leur suppression, ou que des images sources sont accessibles au personnel d’assistance.

La documentation des fournisseurs reflète souvent ces distinctions. Les contrôles des données de l’API d’OpenAI séparent l’usage pour l’entraînement, la surveillance des abus, l’état de l’application, l’éligibilité des endpoints et la gestion des entrées image/fichier. La documentation sur la confidentialité des données de Foundry de Microsoft sépare l’inférence, les fonctionnalités stockées, les données de fine-tuning, la surveillance des abus et la géographie. Les tableaux sont ennuyeux parce que les distinctions comptent.

Les développeurs devraient cartographier le chemin complet. L’utilisateur téléverse une image. Le produit la transmet au fournisseur. Le fournisseur la traite. La sortie revient. Le produit stocke ou ne stocke pas la sortie. Les journaux capturent ou ne capturent pas l’invite et le contenu. Les systèmes de sécurité inspectent ou n’inspectent pas. Les fichiers expirent ou n’expirent pas. L’utilisateur supprime ou ne supprime pas. Chaque verbe est une décision de confidentialité.

C’est particulièrement important pour les fonctionnalités d’image, car les utilisateurs peuvent supposer que « pas d’entraînement » signifie « pas conservé ». Ce ne sont pas des équivalents. Un chemin de conservation sans entraînement peut quand même créer une exposition via une violation, l’accès au support, la découverte juridique, des liens publics ou un usage interne inapproprié.

La bonne habitude côté développeur est d’éviter les mots « parapluie ». Dites « non utilisé pour l’entraînement du modèle ». Dites « non stocké comme état de l’application ». Dites « les journaux de surveillance des abus conservent le contenu client pendant X sauf si ZDR est activé ». Dites « les images téléversées sont supprimées après la génération ». Dites « les sorties ne sont hébergées que lorsque l’utilisateur les enregistre ».

La confidentialité devient beaucoup moins mystérieuse quand le pipeline a des noms. L’utilisateur n’a pas besoin de tous les détails d’implémentation, mais l’équipe, oui. Sinon, « nous n’entraînons pas sur cela » devient une petite île de vérité, dans une mer beaucoup plus vaste de questions sans réponse.

Pour aller plus loin : contrôles des données de l’API d’OpenAI, confidentialité des données de Microsoft Foundry, et Pourquoi « Nous ne nous entraînons pas sur vos données » ne suffit pas.