AI Before & After Photo Privacy: A Practice Checklist

Photo privacy is not one checkbox and not one paragraph in a policy. A practice should be able to trace a facial image from permission through processing, storage, staff access, analytics, retention, deletion, and incident handling before offering an AI simulation to the public.

This article is a product and vendor-review framework, not legal advice. Privacy, biometric, consumer-health, medical-record, advertising, and professional requirements vary by jurisdiction and workflow. Have qualified counsel review the facts that apply to your practice.

1. Map the complete photo lifecycle

Ask the team to draw the path of both the source and generated image. Include the browser, application server, image-generation provider, validation or moderation service, storage system, content-delivery layer, staff interface, support tools, backups, logs, and deletion job. If the answer is only “encrypted in the cloud,” the map is incomplete.

For each stop, record the purpose, data sent, vendor role, region, access method, retention behavior, and deletion mechanism. Repeat the exercise for treatment selection, free-form goals, email, phone number, consultation request, and outcome state. Those fields may reveal sensitive intent even when the photograph is absent.

2. Put meaningful permission before capture

The person should see the material photo-processing terms before the camera or upload is accepted. Use plain language that explains why the photo is processed, whether source and generated files are stored, how they support the requested preview and consultation, and where to find retention and deletion details.

• Do not rely on a prechecked marketing box as photo permission.
• Keep promotional email or SMS separate, optional, and unchecked.
• State whether model training is authorized. Do not silently bundle broad training rights into a required product permission.
• Version the permission text and record which version the person accepted.
• Make the deletion route understandable before the person commits.

3. Minimize what is collected and transmitted

A public preview generally does not need every piece of information a practice could collect. Keep the first interaction focused on the supported photo, selected treatment area, consent record, and bounded product events. Collect contact details when the person chooses the consultation or save flow, not merely because the camera opened.

Validate files before generation. Reject unsupported formats, oversized files, malformed content, and sources that do not meet the product's photo criteria. Sanitize decoded source images and validate generated bytes before storage or display. Do not log raw image bodies.

4. Make access private and location-scoped

Test access as different roles, not only as an administrator. A staff member at one practice location should not be able to retrieve another location's lead or image by changing an identifier. Public image links should not be permanent, enumerable, or guessable.

• Require authenticated staff access for private lead and case views.
• Apply tenant or location scope on every database and storage lookup.
• Use bounded, expiring access mechanisms where images must be retrieved.
• Review support and operator access, not just ordinary staff roles.
• Record meaningful access and deletion actions without copying sensitive payloads into logs.

5. Keep images and identifiers out of ordinary analytics

Page analytics is designed for aggregate behavior, not facial photos. Never send raw image data, unrestricted image URLs, names, phone numbers, email addresses, or free-form consultation notes as event parameters.

A safer attribution event uses a closed page key such as “botox simulator” and a closed source class such as “organic search” or “AI assistant.” Track distinct steps—visit, session start, source accepted, preview generated, consultation requested—without embedding the person's content. Eva applies this first-party pattern on the private preview surface instead of loading the normal marketing analytics stack.

6. Define retention and test deletion

“We delete data when it is no longer needed” is not an operational test. Define the events that start, extend, or end retention and state a maximum period. Decide what happens when a person abandons the flow, creates multiple previews, asks for a consultation, or asks for deletion.

Run a deletion exercise before launch. Verify what happens to source files, generated files, thumbnails, database references, cached copies, temporary work files, and vendor-held artifacts. Confirm what can be deleted immediately, what remains in bounded backups, and how the requester is informed.

7. Review every vendor and contract boundary

Ask which organizations receive the data and which terms control them. Review processing purpose, confidentiality, security controls, breach notice, subprocessors, training rights, data location, return or deletion, assistance with requests, and the allocation of practice and vendor responsibilities.

Do not assume the same answer applies to every surface. A consumer website preview and an authenticated provider planner may use different permissions, storage paths, access controls, and retention automation. Document each workflow as it exists rather than generalizing the strongest control across the whole product.

8. Carry disclosure with the image

Privacy and truthfulness meet at the result. Label the generated output as an illustrative AI simulation, not an actual treatment result or clinical prediction. Keep the label in result views, comparison tools, emails, saved presentations, and staff handoffs. Do not publish a visitor's source or result as marketing creative without a separate, purpose-specific publication permission.

Assign an owner and re-run the checklist

Name the person responsible for permission text, vendor inventory, deletion requests, access review, incidents, and release changes. Re-run the lifecycle audit when the model, image provider, prompt, storage system, consent text, analytics event, staff role, retention rule, or sharing feature changes.

For the current Eva public-flow terms, read the Photo & AI Notice. For the image-quality and workflow side of due diligence, use the complete evaluation framework. Practices can review the two flagship jobs on Eva AI Before & After.