Can You Prove an AI Service Deleted an Image?

Can you prove an AI service deleted an image? Sometimes partially. Rarely perfectly. Anyone promising perfect proof with a straight face should be offered water and a quieter room.

Deletion in a modern service is distributed. The image may touch upload storage, processing queues, temporary disks, generated-output storage, thumbnails, CDN caches, moderation systems, logs, backups, support tools, and third-party provider systems. Deleting the database row is not the same as deleting the image.

There are stronger and weaker kinds of evidence. Stronger evidence includes short-lived storage by design, expiring signed URLs, object lifecycle rules, deletion job logs, cache invalidation records, access logs, provider retention commitments, and audits showing that derivatives are covered. Weaker evidence is a dashboard message saying “deleted” while the direct URL still works. That one is not evidence; it is theatre with a button.

NIST’s Guidelines for Media Sanitization are useful because they separate sanitization outcomes and methods rather than pretending deletion is one magic act. Cloud services are not always doing physical media sanitization per user request, but the mindset helps: define what state you are trying to reach, choose controls, and verify them.

For AI image services, proof often means proving process rather than proving metaphysical absence. You can show that source files are stored only in a short-lived bucket. You can show that lifecycle rules remove them after a window. You can show that outputs are not hosted unless saved. You can show that prompts are not logged. You can show that providers contractually exclude training and define retention.

Backups complicate the promise. Many systems retain encrypted backups for a limited period and do not surgically remove individual records from every backup snapshot. That can be acceptable if it is disclosed accurately and restored data re-enters deletion workflows. It is not acceptable to say “deleted immediately” if backups keep accessible copies for weeks.

The customer-facing answer should avoid overclaiming. “Deleted from active systems within X” is different from “deleted from backups within Y.” “Direct links expire after Z” is different from “outputs are never public.” Specific claims let users decide whether the behaviour is good enough.

Perfect deletion proof is hard. Useful deletion evidence is very possible. The product has to be built for it before the angry support ticket arrives.

Further reading: NIST SP 800-88 Rev. 1, When “Deleted” still means publicly accessible, and Why “Delete My Uploads” needs to be verifiable.