> They said they don't have a copy of the image, but that's extremely hard to believe just assuming how systems like this would be designed; the image has to be

> They said they don't have a copy of the image, but that's extremely hard to believe just assuming how systems like this would be designed; the image has to be served from somewhere, are they seriously purging the images from e.g. their storage buckets that quickly? Possible, but hard to believe; of course, they'd say "oh we don't have a copy" if they investigated, found it doing this, and just wanted the story to die. I don't find it very hard to believe. 1. If the image can be generated in a few seconds, the easiest way to implement this is to accept the file upload in a request, do the AI stuff, and return a new image in the response. In this case, it would be extra (and unnecessary) work to save it in a storage bucket. Both the uploaded and generated images only exist in memory for the lifecycle of the http request, and then get deallocated. 2. If the image _is_ being saved in a storage bucket (or Redis, or whatever), the bucket might have a lifecycle policy on it that automatically expires images after a set time. This is a pretty common cost-saving measure, so it's not too unlikely.