Virtual Makeup Try-On Privacy: Where the Customer's Photo Goes and Who Decides

Every virtual makeup try-on project eventually lands on the same desk: legal. And the question is never about shade accuracy — it is about the face. Where does the photo go, who stores it, for how long, and what happens if a customer asks you to delete it. Virtual makeup try-on privacy is not a legal footnote you handle after launch; it is an architectural decision you make on day one, because the answer depends on which rendering model you choose.

This guide is for the people who have to answer that question internally: e-commerce leads, product managers, developers and the DPO who signs off before the feature goes live.

Two rendering models, two very different privacy stories

MaIA Try-On exists in two forms, and they behave differently on exactly the point legal cares about.

The API: photo-based, server-side

With MaIA Try-On as an API, the flow is explicit: your application sends a photo and a product (lipstick or foundation), the makeup is rendered on the image, and the rendered image comes back. The palettes are calibrated to your brand's real products inside a project, so what the customer sees corresponds to a SKU you actually sell.

Because the image travels to a server to be processed, this form has a clear data-handling story to write down: the photo is sent by your system, processed, and the result returned. Your privacy notice should describe that transfer in plain language, and your front end should obtain consent before the upload happens — not after the shopper has already taken the selfie.

The browser SDK: live camera mode, rendered locally

The MaIA Try-On browser SDK, in early access since September 2026, works differently. In Live mode, the rendering happens locally in the browser, on the customer's own device, using their camera. Nothing is uploaded. The SDK covers thirteen products — lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner — plus a combined Full Look, with any #RRGGBB colour, and it is self-hosted by your brand.

For a privacy review, that distinction matters more than any feature list. A preview that never leaves the device changes the conversation from "how do we protect this image" to "there is no image to protect". The SDK also offers a Photo mode for shoppers who prefer to work from a still, which you should document separately in your notice.

If you are still deciding between the two, we compared the trade-offs in photo-based virtual try-on vs AR try-on — the privacy profile is one of the deciding factors, alongside your stack and your catalog.

What to document before you ship

A privacy review goes faster when you arrive with answers instead of questions. Prepare these five items.

1. The purpose, in one sentence

Why you are capturing a face: to preview a shade of your own catalog on the customer's image. Not to identify anyone, not to build a biometric identity record, not to profile a person beyond the beauty attributes you use for recommendation. Keep the stated purpose narrow and make sure the product actually stays inside it.

2. The consent moment

Consent should appear before the camera opens or before the file is selected, in the shopper's language, with a visible link to the notice. Burying it in site-wide terms is the most common finding in a review. A single, specific screen — "we will use this photo to show you how this shade looks" — is clearer and easier to defend.

3. Retention and deletion

Decide whether you keep anything at all. Many teams discover they do not need the image: they need the outcome — the shade chosen, the product viewed, the session result. Storing the derived data and discarding the picture is usually the cheapest path through a review, and it still feeds merchandising and CRM.

4. Who else touches the data

List the processors in the chain and the role each one plays. Under Brazil's LGPD and the GDPR, your organisation is typically the controller and the technology vendor is a processor acting on your instructions. Your contract should say so explicitly.

5. The exit path

How a shopper asks for deletion, how long you take, and which internal team owns it. If you store nothing, say so — that is the simplest answer a support agent can give.

Analysis is a separate decision from rendering

Try-on is often paired with skin and hair analysis: the customer sends a selfie and receives a beauty profile as JSON — skin tone and undertone, skin type and condition, hair attributes, with a confidence score per field. That is an API call, so the photo is processed server-side and should be treated as its own flow in the notice.

Two clarifications help in a legal conversation. First, the output is a structured description of visible attributes in a photograph. It is not a diagnosis, it does not treat anything, and it does not replace a dermatologist or any other professional — your copy should say that plainly wherever the result appears. Second, the useful artefact downstream is the JSON profile, not the image. Teams that persist the profile and discard the selfie keep personalization working while shrinking the surface area of what they hold.

Write the notice the way you would explain it out loud

The test is simple: could a support agent explain your try-on data flow to a customer in thirty seconds without reading a document? If not, the flow is probably too complicated or the notice is too vague. Name what is captured, where it is processed, what is kept, and for how long. Shoppers rarely abandon a feature because it uses a camera; they abandon it when nobody tells them what happens next.

Ready to map the data flow for your own stack? Create an account and an API key in the MaIA API documentation, or talk to the B4A team about browser SDK early access for your brand.