Why "No Training" Is Not Enough

“We do not train on your data” is a good sentence. It is also not the whole meal. It is a single pea on a very large, slightly suspicious plate.

Training is one risk. If a provider uses customer prompts, uploaded images, or outputs to improve models without permission, that is obviously a problem. But customers usually care about a broader question: what happens to my content after I send it? Training is only one possible destination.

The content might be retained for abuse monitoring. It might be stored as application state. It might sit in a conversation thread until deleted. It might be cached for performance. It might be written into request logs. It might be copied into an error report. It might be visible to support staff. It might be stored in a user’s gallery. It might be routed to another provider whose policy is completely different. It might be “not used for training” and still be kept long enough to make a privacy-conscious buyer back slowly out of the room.

This is not theoretical hair-splitting. Major AI platforms publish detailed retention tables because endpoint behavior differs. OpenAI’s data controls documentation, for example, distinguishes training use, abuse-monitoring retention, application-state retention, and Zero Data Retention eligibility across endpoints. The image endpoints listed there are not all identical across every model and condition. That complexity is not evil, but it is complexity, and product teams should not flatten it into one soothing sentence.

Google’s Gemini Enterprise Agent Platform documentation makes a similar point from another angle: it separates training restrictions from retention scenarios such as abuse monitoring, grounding, request-response logging, session resumption, and caching. Again, the lesson is not “everyone is bad.” The lesson is “specifics matter.” Privacy is a table, not a vibe.

For AI image products, this distinction gets sharper because the source material can be so personal. A prompt is sensitive. A face is more sensitive. A face plus a prompt plus a generated output plus a billing record plus a support screenshot is no longer “just an API call.” It is a miniature dossier created by accident, which is the most software thing imaginable.

Better privacy copy should answer several plain questions. Do you train on customer content? Do you retain prompts? Do you retain source images? Do you retain generated outputs? Are there exceptions for safety or law? Can staff see content? Do you send content to outside image providers? How long do temporary files exist? What metadata remains after generation?

Unexposed’s position is intentionally narrower and more concrete: keep prompts, source images, generated outputs, and keys inside infrastructure controlled by Unexposed, run them through short-lived generation sessions, and keep durable records content-blind. That does not mean “nothing exists anywhere ever,” because billing and operations still exist. It means the durable system should not become a creative-content museum with better incident response.

If a vendor’s privacy page stops at “we do not train,” ask the next question. Then the next. Then the annoying one. The annoying one is usually where the product truth lives, looking tired and holding a log file.

Further reading: OpenAI’s data retention controls, Google’s zero data retention documentation, and Unexposed data storage.