Pourquoi la suppression des téléversements doit être vérifiable

“Supprimer mes téléversements” fait partie de ces formulations qui semblent simples jusqu’à ce qu’elles rencontrent un système réel.

Supprimer d’où ? De la galerie ? Du stockage d’objets ? Du CDN ? Du cache ? De la file d’attente ? Du traqueur d’erreurs ? Du ticket de support ? De la table des miniatures ? Des sauvegardes ? Du fournisseur de modèle ? Du pipeline d’analytique ? Du dossier créé par quelqu’un pendant le débogage, appelé final-final-private-test, ce qui vous indique que le logiciel a commencé à se manger lui-même ?

Pour les produits d’images par IA, la suppression doit être définie en termes d’objets. Image source. Invite. Masque. Image de référence. Sortie générée. Miniature. Fichier temporaire. URL de livraison. Métadonnées opérationnelles. Enregistrement de facturation. Chaque objet peut avoir un cycle de vie différent. Un bon produit connaît ces cycles de vie. Un produit faible dit simplement « supprimé » et espère que personne ne posera la question suivante.

Une suppression vérifiable ne signifie pas toujours qu’un utilisateur peut prouver cryptographiquement que chaque octet a disparu de chaque support instantanément. Dans beaucoup de systèmes, les sauvegardes, les journaux, les enregistrements de fraude, les registres fiscaux et les obligations légales compliquent la suppression. Les produits honnêtes expliquent ces limites. La distinction importante est de savoir si les enregistrements conservés portent du contenu ou s’ils sont aveugles au contenu.

Si un produit supprime l’image mais conserve un enregistrement de facturation indiquant qu’une génération d’image a eu lieu, cela peut être raisonnable. S’il supprime l’élément de galerie mais conserve la miniature, l’invite et l’image source dans un « bucket qualité », c’est une comédie, éclairée comme dans un film réglementaire.

Une bonne suppression commence avant la suppression. Elle commence par ne pas copier du contenu privé dans des endroits inutiles. Plus le contenu va dans peu d’endroits, moins la suppression doit le poursuivre ensuite, avec un petit balai et un visage triste. Des chemins de données courts sont plus faciles à vérifier que des parcours étendus.

L’interface utilisateur doit aussi être précise. « Retirer de la galerie » n’est pas « supprimer le téléversement source ». « Supprimer la sortie » n’est pas « supprimer le compte ». « Masquer » n’est pas « supprimer ». « Archiver » n’est définitivement pas « supprimer », même si la police coûte cher.

Pour une infrastructure d’images par IA axée sur la confidentialité, le meilleur réglage par défaut consiste à éviter le stockage durable des téléversements dès le départ. Traitez l’image source pendant une session de courte durée, renvoyez la sortie, et conservez uniquement des enregistrements opérationnels aveugles au contenu. Ainsi, la promesse de suppression devient moins héroïque, car il y a moins de contenu privé en attente d’être supprimé.

Les utilisateurs n’ont pas besoin d’un mémoire. Ils ont besoin d’une réponse claire : quel contenu reste après que j’ai appuyé sur supprimer, et pourquoi ?

Si un produit ne peut pas répondre à cela, « supprimer » n’est que de la décoration.

Pour aller plus loin : Stockage des données Unexposed, Comment penser la suppression zéro pour les images IA, et la documentation de conservation des données d’OpenAI sur la conservation des données via l’API.