Try-on virtual sin subir fotos: cómo funciona el modo en vivo en el navegador

La pregunta llega siempre en la misma reunión: el equipo de e-commerce presenta la prueba virtual de maquillaje, y alguien de legal o de seguridad levanta la mano para preguntar dónde quedan las imágenes de la cara del cliente. Un try-on virtual sin subir fotos resuelve esa conversación antes de que se vuelva un bloqueo de proyecto: la imagen nunca sale del navegador, el render ocurre en el dispositivo y no hay un archivo con el rostro del cliente viajando a un servidor. Esta nota explica cómo funciona ese modelo, en qué se diferencia del flujo por foto vía API y cómo decidir cuál usar en cada canal.

Qué significa exactamente "sin subir fotos"

Hay una diferencia técnica importante entre no guardar una imagen y no enviarla. Muchas integraciones envían la foto a un servidor, procesan y después borran. Eso es una política de retención: depende de una promesa operativa y de un contrato.

El modo en vivo del SDK de navegador de MaIA Try-On opera de otra forma. El cuadro de video viene de la cámara del propio cliente, el maquillaje se renderiza localmente en el navegador y ese cuadro no se transmite. No hay carga, no hay copia en tránsito, no hay archivo que retener ni que borrar. Para el equipo de privacidad, la diferencia entre "lo borramos después" y "nunca salió del dispositivo" es enorme a la hora de documentar un tratamiento de datos.

Es importante no confundir esto con una etiqueta de marketing. No hablamos de realidad aumentada: hablamos de un modo en vivo por cámara, ejecutado en el navegador, que la marca aloja en su propio dominio.

Try-on virtual sin subir fotos: los caminos disponibles

Modo en vivo en el navegador (SDK)

El SDK de navegador está en acceso anticipado desde septiembre de 2026 y se habilita por cuenta. Cubre trece productos —labial, base, rubor, polvo facial, corrector de ojeras, sombra, máscara de pestañas, maquillaje de cejas, delineador, bronzer, contorno, iluminador y delineador de labios— además de un Full Look combinado, con cualquier color en formato #RRGGBB. La marca lo aloja (self-hosted), lo que significa que el control sobre el dominio, el CSP y el ciclo de vida de la sesión queda del lado de la marca.

Este es el camino natural cuando el requisito es que la imagen del cliente no circule: página de producto, landing de campaña, quiz de color o un punto de prueba en tienda con tablet.

Modo foto dentro del mismo SDK

El SDK también ofrece modo foto, útil cuando el cliente prefiere no abrir la cámara o cuando la luz del ambiente no ayuda. Vale la pena explicitar en la interfaz qué hace cada modo, porque el usuario no distingue solo por el ícono.

La API por foto, cuando no hay navegador

Hay canales donde el navegador simplemente no existe: WhatsApp, un chat interno, un CRM que arma una pieza de email, un flujo de atención. Ahí entra la prueba virtual de maquillaje por foto vía API: el cliente envía una foto, el producto —labial o base— se renderiza sobre ella con la paleta calibrada a los productos reales de la marca en un proyecto, y la imagen vuelve lista para mostrar.

Este flujo sí implica el envío de una imagen, y conviene tratarlo como tal: consentimiento explícito, aviso claro y una política de retención escrita. No es un camino peor; es un camino distinto, para canales distintos. Los once productos restantes y el Full Look son exclusivos del SDK, como vista previa local, y no deben prometerse en el flujo por API. Si querés profundizar en la comparación conceptual, escribimos sobre prueba virtual por foto frente a los enfoques de AR.

Lo que cambia para el equipo de legal y de seguridad

Cuando el render es local, el documento de evaluación de impacto se vuelve mucho más corto. No hay un nuevo repositorio de imágenes faciales, no hay un subprocesador recibiendo rostros, no hay una decisión sobre cuántos días retener. Eso acelera la aprobación interna, que en muchas marcas es el verdadero cuello de botella del proyecto, no la integración técnica.

Tres puntos que conviene dejar por escrito desde el inicio:

• Qué se envía y qué no. En modo en vivo, el cuadro de cámara no se transmite. Documentalo con esa precisión.
• Qué sí se registra. Eventos de uso, SKU probado, duración de sesión: métricas de producto, no imágenes. Definí la lista antes de desarrollar.
• Dónde vive el código. Al ser self-hosted, la marca controla el dominio y el versionado. Eso también es un argumento de seguridad.

Cómo comunicarlo en la interfaz

Un try-on virtual sin subir fotos solo genera confianza si el cliente lo entiende. Una línea corta junto al botón —"la imagen se procesa en tu dispositivo y no se envía"— vale más que un párrafo en la política de privacidad. En tienda física, el mismo mensaje impreso al lado de la tablet reduce la fricción del vendedor, que deja de tener que explicarlo cada vez.

Evitá prometer de más. No hay certificación de dispositivos ni descarga pública del SDK: el acceso se concede por cuenta, en acceso anticipado. Decir lo que el producto hace, con exactitud, sostiene mejor la relación que una promesa amplia.

Cómo decidir según el canal

Una regla simple de trabajo: si el cliente está en un navegador que la marca controla, el modo en vivo del SDK es la opción por defecto. Si el cliente está en una conversación —WhatsApp, chat, email—, el flujo por foto vía API es el que encaja, con el consentimiento correspondiente.

Y si lo que buscás no es solo el color sobre la cara sino la recomendación de qué SKU probar, el try-on funciona mejor acompañado de un perfil de belleza y del catálogo de la marca, el territorio de MaIA Beauty Advisor, que se entrega como proyecto junto al equipo de B4A.

Creá tu cuenta y tu clave de API en la documentación para empezar a probar el flujo por foto, o hablá con nuestro equipo si querés evaluar el acceso anticipado al SDK de navegador para tu marca.