How to think about zero retention for AI images

Zero retention sounds like a policy. In practice, it is a design constraint.

The important question is not whether a product says “we do not store prompts.” The important question is whether the system has been built so prompts and source images have very few places to go.

Separate content from operations

Operational metadata is useful. Teams need to know whether jobs are failing, which models are slow, how many images were generated, and whether a queue is overloaded.

User content is different. Prompts, masks, reference images, generated outputs, and uploaded assets should not be treated like ordinary logs.

A good zero-retention design keeps those two kinds of data separate from the start.

Make temporary mean temporary

Some data has to exist while a job is running. The prompt has to reach the model. Source images have to be read. Outputs have to be returned.

The key is to keep that data in short-lived paths and delete it when the job is done. Temporary storage should be boring, explicit, and easy to inspect.

Avoid accidental retention

The biggest privacy mistakes are often accidental:

• request bodies in error logs
• screenshots in support tools
• prompts in analytics events
• source files copied into debug folders
• generated outputs saved for “quality review”

Zero retention requires checking these ordinary paths, not just the database schema.

Explain the model plainly

Customers should not need a security background to understand what happens to their content. A simple explanation is usually a good sign that the system itself is simple.

If the story requires too many exceptions, the implementation probably does too.