Beauty Profile and LGPD: How to Collect and Use the Data Without Stalling the Product

Every time a beauty brand decides to personalise its recommendations, the same meeting comes up: marketing wants the data, product wants to integrate fast and legal wants to know exactly what is being stored. The conversation about beauty profile and LGPD usually stalls not for lack of rules, but for lack of precision about what is collected, for how long and for what. When those three answers are clear, the integration moves forward.

This text is a practical product-design guide, not legal advice. The final decision always belongs to your legal team or data protection officer.

What exactly a beauty profile is

A beauty profile is a set of visible attributes described from a photo: skin tone and undertone, skin type and condition, hair characteristics, each field with a confidence level. That is what MaIA Scan's selfie skin and hair analysis returns in JSON.

Two observations matter for the conversation with legal.

The first: the profile describes visible appearance, not health. MaIA is not a clinical assessment, does not treat anything and does not replace a health professional or a dermatologist. If your internal brief talks about "detecting skin problems", rewrite it before taking it for review — the declared purpose needs to match what the system actually does.

The second: photo and profile are two different assets, with different risks. The image is identifiable; the profile is a set of attributes. Treating the two as the same thing is the most common architectural mistake and the one that delays internal approval the most.

Beauty profile and LGPD: the questions legal will ask

Specific purpose

"Personalising the experience" is too vague to support a policy. A useful purpose is concrete: recommending foundation shades compatible with the identified tone and undertone; assembling a subscription kit; segmenting an email sequence by skin type. Write the purpose in one sentence a customer would understand and use exactly that sentence in the collection notice.

Legal basis and consent

The facial image demands special attention: depending on the use, it may be classified as sensitive data — and that analysis belongs to your legal team, not the vendor. What product design can do is make the decision easier: make it clear that the photo serves to describe visible attributes and not to identify or authenticate people, ask for specific, granular consent in plain language, and make refusing as easy as accepting. Consent buried in the terms of use does not survive an audit.

Minimisation and retention

Minimisation is the question: do you really need to keep the photo? In most use cases, no. What feeds the recommendation is the profile, not the image. Deciding that the photo is discarded after processing and that only the JSON is persisted drastically reduces the risk surface — and it is usually the decision that gets the project approved.

Retention is the next question: how long does that profile remain valid? Skin and hair change with season, routine and treatment. A two-year-old profile is not just a compliance liability; it is a bad recommendation. Set a period, communicate it and offer the customer the option to redo the analysis.

Data subject rights

Access, correction and deletion need to exist in practice. Before integrating, answer: if a customer asks to see their own profile, where does it come from? If they ask for deletion, how many systems need to be touched — CRM, email tool, data lake? Mapping this before scaling is cheaper than doing it afterwards.

Three integration designs, three levels of exposure

Ephemeral profile

The customer sends the selfie, the API returns the JSON, the recommendation is shown on the spot and nothing is persisted. No profile database, no data subject to locate later. It is the simplest design to approve and the one recommended for campaigns and first proofs of concept.

Profile persisted in the CRM

The JSON becomes a customer field and starts feeding email, WhatsApp and the product page. Here the value is greater and so is the responsibility: specific consent, retention period, deletion flow and internal access control. When the recommendation is operated by a beauty advisor integrated with the catalog, the persisted profile is what allows the conversation to resume without asking for everything again.

Local rendering in the browser

For virtual makeup try-on, there is a design in which the data does not even leave the device: in the live camera mode of the MaIA Try-On SDK, rendering happens locally in the browser and no image is sent. It is the option with the lowest exposure — and it is worth remembering that the SDK is in early access, enabled per account. The photo version of the API, on the other hand, does send the image for processing and follows the same logic as the previous designs.

Checklist before integrating

• Is the purpose written in one concrete sentence, and does it appear in the collection notice?
• Is the photo discarded after processing, or is there a documented reason to keep it?
• Is consent specific, granular and refusable without friction?
• Is there a retention period for the profile and an update routine?
• Does the deletion flow reach every system the profile was copied to?
• Does the communication to the customer avoid any promise of a clinical assessment?

A well-designed beauty profile is first-party data, collected with consent, with a declared purpose and a defined period. That is not an obstacle to personalisation — it is what makes it defensible.

Want to test the JSON format before taking the discussion to legal? Create your account, generate an API key and run the first analyses — or talk to the team to design the integration with your catalog.