Le guide du développeur pour générer des images privées

Développeurs

La génération d’images privées repose sur un ensemble de choix d’ingénierie autour de requêtes scellées, de calcul à durée de vie courte, d’enregistrements sans contenu et d’un comportement de suppression clair.

Date
3 juillet 2026
Author
Unexposed

Un poste de travail de développeur avec des diagrammes d’architecture vierges, des capsules d’images scellées et une baie de serveurs

La génération d’images privées n’est pas une fonctionnalité unique. C’est une chaîne de choix.

Commencez par la requête. Traitez les prompts, les images sources, les masques, les images de référence, les sorties générées et les clés comme du contenu utilisateur. Cela signifie qu’ils doivent emprunter un chemin plus restreint que la télémétrie ordinaire. Ils ne doivent pas apparaître, par inadvertance, dans les journaux, l’analytique, les tableaux de bord ou les écrans de support client.

Ensuite, séparez l’autorisation du contenu. Le système doit savoir si le compte peut exécuter la tâche et la payer. Cela ne veut pas dire que la couche de facturation a besoin du prompt. Une facturation sans contenu est ennuyeuse, mais c’est exactement ce qu’il faut : elle enregistre que l’utilisation a eu lieu sans enregistrer ce qui a été produit.

Puis, rendez le traitement éphémère. Une session de génération doit exister pour traiter une tâche et renvoyer le résultat, pas pour devenir un espace de travail durable. Des fichiers temporaires peuvent être nécessaires pendant l’exécution du job. Ils ne doivent pas devenir un état produit une fois le job terminé.

Conservez l’observabilité sans contenu. Vous avez toujours besoin de métriques : temps d’attente en file, performance du modèle, type d’échec, capacité, coût et santé. Vous n’avez pas besoin du contenu brut de l’utilisateur dans la plupart des événements opérationnels. Si vous pensez en avoir besoin, demandez-vous si vous êtes en train de déboguer le système ou si vous stockez du contexte client parce que c’est plus simple.

Faites attention aux reprises (retries). Les jobs échoués ne doivent pas divulguer les prompts dans les journaux ni laisser les images sources derrière eux. Les systèmes de reprise sont utiles, mais ils doivent respecter la même frontière de contenu que les jobs réussis.

Décidez si vous proposez de l’historique. Si vous fournissez une galerie, dites-le. Si vous ne le faites pas, faites-en une fonctionnalité. Une architecture sans galerie est plus facile à aligner avec des promesses de zéro conservation, car les sorties sont renvoyées plutôt que conservées.

Rédigez la documentation pour des non-spécialistes. « Requête scellée » n’est utile que si l’utilisateur peut comprendre ce que cela protège et ce que cela ne protège pas. Dites où va le contenu, ce qui reste, et ce que les opérateurs peuvent voir.

Le guide du développeur, c’est vraiment ceci : réduire le nombre d’endroits où le contenu d’images privées peut vivre, puis rendre le chemin restant facile à expliquer.

Pour aller plus loin : Démarrer, Comment fonctionne Unexposed, et Stockage des données Unexposed.

Your prompt. Your model. Only your content.

Create private images with Credits, Access Tokens, and sealed requests. Encrypted in transit, run on ephemeral compute, deleted after delivery.