Data retention and privacy for image-processing APIs

Ask a user what worries them about an image feature and they will not mention model architecture. They will ask where the photo goes and how long it stays there. For intimate imagery that concern is not paranoia — it is the correct instinct, and it deserves a precise answer rather than a reassuring adjective.

Why retention is the whole conversation

An image sitting on a server is a liability that accrues interest. Every day it exists is another day it can be exposed by a breach, requested by a subpoena, or found by an employee who should never have seen it. Storage is cheap, which is exactly the problem: nothing forces anyone to delete, so systems accumulate intimate data by default rather than by decision.

The three answers that matter

When evaluating a vendor, three questions separate a serious operator from a marketing page. How long is the source image kept? How long is the result kept? Is any of it used for training? Vague answers to any of the three are themselves an answer.

• "We delete images 10 minutes after delivery" is a commitment you can test.
• "We retain data as long as necessary to provide the service" is a sentence that permits indefinite storage.
• "We may use content to improve our models" means your users' photographs become training data.
• Silence on the topic means nobody has decided, which is worse than an inconvenient policy.

Deletion has to be deletion

A retention promise is only as good as its enforcement, and there are more ways to get this wrong than right. The database row is removed but the file stays on disk. The primary copy goes and the CDN cache keeps serving. The application deletes but the nightly backup preserves it for ninety days. Intermediate files written by the processing pipeline are never in scope at all.

A credible answer names all the copies. Ask specifically about caches, backups and intermediate artefacts — the answer tells you whether the policy was designed or merely written.

Training use is a separate decision

Using customer content to improve models is a business choice, not a technical inevitability, and for intimate imagery it deserves an explicit no rather than a buried permission. Note the asymmetry: retention risk ends when the file is deleted, but training use is irreversible. Weights cannot forget a photograph.

What this means under data-protection law

Under the GDPR and comparable regimes, intimate imagery attracts the strictest treatment, and two principles bite immediately. Storage limitation means keeping personal data no longer than the purpose requires — and the purpose here is delivering one result, which expires the moment it is delivered. Data minimisation means not collecting what you do not need.

Short retention is not merely a nice property in this context. It is the mechanism by which several obligations become straightforward: a deletion request is trivial when the data is already gone, and a breach cannot expose what was never kept.

Questions worth asking before you integrate

1. What is the exact retention period for inputs and for outputs, in units of time?
2. Which copies does that cover — caches, backups, logs, intermediate files?
3. Is content ever used for training or evaluation, under any circumstances?
4. Who inside the vendor can access stored imagery, and is that access logged?
5. What is the deletion path if a user withdraws consent tomorrow?

A vendor who answers these crisply has thought about the problem. A vendor who answers with adjectives has not, and you will inherit that gap the first time one of your users asks the same question.

Frequently asked