Peut-on prouver qu’un service d’IA a supprimé une image ?

Peut-on prouver qu’un service d’IA a supprimé une image ? Parfois partiellement. Rarement parfaitement. Toute personne qui promet une preuve parfaite avec un visage impassible devrait se voir offrir de l’eau et une pièce plus calme.

La suppression, dans un service moderne, est distribuée. L’image peut toucher le stockage de téléchargement, les files de traitement, les disques temporaires, le stockage des sorties générées, les miniatures, les caches CDN, les systèmes de modération, les journaux, les sauvegardes, les outils de support et les systèmes de fournisseurs tiers. Supprimer la ligne de la base de données n’est pas la même chose que supprimer l’image.

Il existe des preuves plus fortes et des preuves plus faibles. Les preuves plus fortes incluent un stockage à durée de vie courte conçu ainsi, des URL signées expirant, des règles de cycle de vie, des journaux de tâches de suppression, des enregistrements d’invalidation de cache, des journaux d’accès, des engagements de conservation du fournisseur et des audits montrant que les dérivés sont couverts. Les preuves plus faibles sont un message de tableau de bord disant « supprimé » alors que l’URL directe fonctionne encore. Celle-ci n’est pas une preuve ; c’est du théâtre avec un bouton.

Les Guidelines for Media Sanitization du NIST sont utiles car elles distinguent les résultats et les méthodes de désanitation plutôt que de prétendre que la suppression est un seul acte magique. Les services cloud ne font pas toujours une désanitation physique des supports par demande utilisateur, mais l’approche aide : définir l’état que l’on cherche à atteindre, choisir des contrôles et les vérifier.

Pour les services d’images par IA, la preuve signifie souvent prouver le processus plutôt que prouver l’absence métaphysique. Vous pouvez montrer que les fichiers sources ne sont stockés que dans un compartiment à durée de vie courte. Vous pouvez montrer que les règles de cycle de vie les suppriment après une fenêtre. Vous pouvez montrer que les sorties ne sont pas hébergées à moins d’être enregistrées. Vous pouvez montrer que les prompts ne sont pas journalisés. Vous pouvez montrer que les fournisseurs excluent la formation de manière contractuelle et définissent la conservation.

Les sauvegardes compliquent la promesse. De nombreux systèmes conservent des sauvegardes chiffrées pour une période limitée et ne retirent pas chirurgicalement des enregistrements individuels de chaque instantané de sauvegarde. Cela peut être acceptable si c’est divulgué avec précision et si les données restaurées réintègrent les workflows de suppression. Ce n’est pas acceptable de dire « supprimé immédiatement » si des copies restent accessibles pendant des semaines.

La réponse destinée au client doit éviter les surpromesses. « Supprimé des systèmes actifs dans un délai de X » est différent de « supprimé des sauvegardes dans un délai de Y ». « Les liens directs expirent après Z » est différent de « les sorties ne sont jamais publiques ». Des affirmations spécifiques permettent aux utilisateurs de décider si le comportement est suffisamment bon.

Une preuve parfaite de suppression est difficile. Une preuve de suppression utile est tout à fait possible. Le produit doit être conçu pour cela avant que le ticket de support en colère n’arrive.

Pour aller plus loin : NIST SP 800-88 Rev. 1, Quand « supprimé » signifie encore accessible publiquement, et Pourquoi « Supprimer mes téléchargements » doit être vérifiable.