Try-on virtual sem upload de foto: como funciona o modo ao vivo no navegador

Em quase todo projeto de prova virtual existe uma reunião em que alguém de jurídico ou de segurança faz a mesma pergunta: para onde vai a foto do cliente? A resposta define prazo, contrato e, muitas vezes, se o projeto sai do papel. Por isso o tema try-on virtual sem upload de foto deixou de ser detalhe técnico e virou critério de decisão — especialmente para marcas que atendem consumidor final no Brasil e precisam explicar, em linguagem simples, o que acontece com a imagem.

Este artigo separa dois caminhos que costumam ser confundidos: a renderização local no navegador e o processamento por foto via API. Os dois são legítimos, resolvem problemas diferentes e podem conviver no mesmo e-commerce.

O que "sem upload" realmente significa

"Sem upload" não quer dizer que nenhum dado existe. Quer dizer que o quadro da câmera não sai do dispositivo do cliente para ser processado em um servidor. O cálculo de onde ficam os lábios, as pálpebras e as maçãs do rosto, e a aplicação da cor escolhida, acontecem no próprio navegador.

Isso muda três conversas internas de uma vez:

• Jurídico: não há transferência de imagem de rosto para um terceiro para gerar o preview.
• Segurança: não existe repositório novo de fotos para proteger, versionar e expurgar.
• Produto: o cliente não precisa aceitar um termo longo antes de experimentar um batom, o que reduz o atrito na primeira interação.

Vale a honestidade: a experiência ainda acontece dentro do seu site, então sua política de privacidade e seu banner de consentimento continuam valendo. O que some é a etapa de enviar e armazenar a imagem em outro lugar.

Try-on virtual sem upload de foto: como funciona o SDK no navegador

O MaIA Try-On existe em duas formas, e só uma delas dispensa o envio da imagem.

Modo ao vivo pela câmera

O SDK de navegador, em early access desde setembro de 2026, é hospedado pela própria marca e roda no navegador do cliente. No modo ao vivo, a câmera abre, a renderização acontece localmente e nada é enviado. São treze produtos disponíveis — batom, base, blush, pó facial, corretivo de olheiras, sombra, máscara de cílios, maquiagem de sobrancelha, delineador, bronzer, contorno, iluminador e lápis labial — além de um Full Look que combina os itens em um único visual. Qualquer cor em formato #RRGGBB pode ser aplicada, o que permite espelhar o seu catálogo real, incluindo lançamentos e edições limitadas.

Há também um modo Foto, para o cliente que prefere usar uma imagem já existente em vez de abrir a câmera.

Como o SDK é self-hosted, o arquivo roda na sua infraestrutura e dentro do seu domínio. Não existe download público: o acesso é concedido por conta, caso a caso, porque ainda estamos em early access.

O caminho por foto, via API

A API do MaIA Try-On funciona de outra forma: a marca envia uma foto, o produto é renderizado sobre ela e a imagem volta pronta. Aqui, por definição, existe envio de imagem — e é exatamente isso que torna a API útil em canais onde não há navegador com câmera, como WhatsApp, e-mail, campanhas e fluxos de CRM. A API cobre batom e base, com paletas calibradas para os produtos reais da marca dentro de um projeto. Os outros onze produtos e o Full Look são exclusivos do SDK, como preview local.

Se a dúvida é qual dos dois formatos encaixa no seu canal, o comparativo entre try-on por foto e try-on em tempo real detalha as diferenças de experiência e de integração.

Quando o modo ao vivo é a escolha certa

Página de produto com tráfego mobile alto. O cliente está decidindo cor no celular, com a câmera à mão. Abrir, testar e fechar em segundos, sem tela de consentimento de upload, reduz abandono no momento mais sensível da jornada.

Categorias de cor com muitas variações. Sombra, blush, contorno e iluminador ganham pouco em uma imagem estática e muito em movimento, com o cliente virando o rosto e vendo o resultado sob a própria luz.

Marcas com política de dados restritiva. Grupos com área de compliance forte, ou que atendem também o público corporativo, costumam aprovar um preview local com muito menos fricção do que um pipeline que envia rostos para fora.

Quando o caminho por foto ainda vence

Canais sem navegador. Em uma conversa de WhatsApp, não existe SDK rodando. A API resolve: a cliente manda a selfie, recebe a imagem com o batom aplicado.

Conteúdo gerado em lote. Campanhas, e-mails segmentados e páginas de lançamento podem usar a API para produzir previews server-side, sem depender da sessão do cliente.

Quando o preview é só o começo. Se a intenção é ir além do "ficou bonito" e chegar a "esta é a sua base", o preview precisa de contexto. É aí que entra a análise de pele e cabelo por selfie: tom e subtom de pele, tipo e condição de pele, atributos de cabelo e uma confiança por campo, devolvidos em JSON. Esse perfil pode alimentar recomendação, CRM e a consultora de beleza integrada ao seu catálogo.

Um lembrete importante: a análise descreve atributos visíveis de uma foto. Não é diagnóstico, não substitui profissional e não deve ser comunicada como tal.

Checklist antes de decidir

1. Mapeie o canal. Site próprio com câmera? SDK. WhatsApp, e-mail, app de terceiros? API.
2. Converse com jurídico antes do design. Saber se o preview é local muda o texto do consentimento e o escopo do contrato.
3. Prepare o catálogo em hex. O SDK aceita qualquer #RRGGBB; a qualidade do resultado depende de cores fiéis aos produtos reais.
4. Decida o que você quer guardar. Preview local não gera dado próprio por si só. Se quiser dado, é o perfil de beleza — com consentimento explícito — que entra na jogada.
5. Planeje o fallback. Nem todo cliente autoriza a câmera. Ter modo Foto, ou um fluxo por API, evita beco sem saída.

Quer testar os dois caminhos no seu catálogo? Crie uma conta, compre créditos e gere sua chave de API na documentação — ou fale com nosso time para avaliar o early access do SDK de navegador para a sua marca.