Try-on virtual self-hosted: qué controla la marca cuando el SDK corre en su dominio

Cuando un equipo de e-commerce evalúa una prueba virtual de maquillaje, la primera pregunta suele ser visual: ¿qué tan bien se ve el labial en la cara del cliente? La segunda pregunta, que aparece más tarde pero pesa más en el contrato, es de infraestructura: ¿dónde corre ese código y quién lo controla? El try-on virtual self-hosted responde esa segunda pregunta: el SDK se entrega a la marca y se sirve desde su propio dominio, dentro de su stack, con su proceso de despliegue.

Este artículo explica qué significa eso en la práctica, qué decisiones cambia y cuándo conviene más la vía de la API por foto.

Dos formas de entregar una prueba virtual

MaIA Try-On existe en dos formatos, y la diferencia no es cosmética.

La API por foto. El cliente envía una imagen, el producto —labial o base— se renderiza sobre ella y la imagen vuelve lista para mostrar. Es una llamada HTTP: sirve para WhatsApp, email, landing pages, kioscos y cualquier canal donde no haya un front-end moderno al que agregarle un paquete. Las paletas se calibran contra los productos reales de la marca dentro de un proyecto.

El SDK de navegador, en early access desde septiembre de 2026. Cubre trece productos —labial, base, rubor, polvo facial, corrector de ojeras, sombra, máscara de pestañas, maquillaje de cejas, delineador, bronceador, contorno, iluminador y delineador de labios— más un Full Look combinado. Funciona en modo ao vivo por cámara, con el render ejecutándose localmente en el navegador y sin subir nada, o en modo foto. Acepta cualquier color en formato #RRGGBB. Y es self-hosted: la marca lo aloja.

Si todavía estás comparando enfoques de render, el artículo sobre prueba virtual por foto y otros enfoques ordena ese debate antes de llegar a la parte de infraestructura.

Qué controla la marca con un try-on virtual self-hosted

Los datos del cliente

En modo ao vivo, el video de la cámara se procesa en el dispositivo del usuario. No hay carga de la imagen a un servidor para que el maquillaje aparezca. Para el equipo legal y de privacidad, esto cambia la conversación: en lugar de negociar el tratamiento de imágenes faciales con un tercero, se documenta un procesamiento local. Sigue siendo necesario informar al usuario y pedir permiso de cámara, pero el inventario de datos personales de la marca no crece con cada prueba.

En el modo por API, en cambio, sí hay una imagen que viaja. Eso es perfectamente manejable —es el mismo tipo de flujo que ya existe en cualquier upload— pero es una decisión consciente, no un detalle.

El dominio y el rendimiento

Servir el SDK desde el dominio propio elimina una dependencia de terceros en el camino crítico de la página de producto. El equipo decide desde qué CDN se entrega, qué política de caché aplica, cómo entra en la Content Security Policy y en qué momento se carga —por ejemplo, solo cuando el usuario toca el botón de probar, para no castigar el Largest Contentful Paint de todas las visitas.

También decide cuándo actualiza. Una versión nueva entra por el mismo pipeline que el resto del front-end, con QA y rollback propios. Nada cambia en producción porque un proveedor publicó algo un martes.

El color

El SDK acepta cualquier #RRGGBB, lo que suena trivial y no lo es: significa que la fuente de verdad del color puede vivir donde la marca quiera. Muchos equipos la ponen en el PIM, junto al nombre del tono y al código de barras, y la exponen al front-end por el mismo feed que alimenta la ficha de producto. Así, lanzar un tono nuevo no requiere pedirle nada a un proveedor externo.

El contrapeso es responsabilidad: si el hex que publica el equipo de producto no corresponde al tono real del labial, el render será fiel al hex y no al producto. Conviene una rutina de validación con muestras físicas antes de publicar, y un dueño claro de esa tabla.

El contexto de uso

Self-hosted también quiere decir que la experiencia se integra donde tenga sentido: una ficha de producto, un comparador de tonos, una landing de campaña, una página de "arma tu look" con el Full Look. No hay un iframe que obligue a un layout ajeno ni una ventana que rompa la navegación móvil.

Lo que el self-hosting no resuelve

Seamos concretos sobre los límites.

• No es una app ni una descarga pública. El SDK está en early access y el acceso se concede por cuenta. No hay certificación de dispositivos ni promesa de comportamiento idéntico en todo el parque de celulares: hay que probar en los dispositivos que realmente usan tus clientes, con tu analítica de navegadores en la mano.
• El Full Look y los once productos más allá de labial y base son exclusivos del SDK. La API por foto renderiza labial y base. Si tu caso de uso vive en WhatsApp o en email, planifica con eso.
• Alojar implica mantener. Alguien del equipo tiene que ser dueño del bundle, del permiso de cámara, de los mensajes de error y de la medición.
• No hay afirmaciones clínicas. La prueba virtual muestra cómo se ve un color sobre una foto o sobre la cámara; no diagnostica nada.

Cómo decidir entre SDK y API

Una regla simple que funciona en la mayoría de los casos:

• Catálogo amplio de maquillaje, tráfico mobile alto, equipo de front-end propio, exigencia fuerte de privacidad → SDK self-hosted.
• Canales conversacionales, CRM, campañas, retail sin desarrollo front-end, pruebas rápidas de hipótesis → la API por foto de MaIA Try-On, que se integra con una llamada.
• Ambos, que es lo más común: el SDK en la ficha de producto y la API en WhatsApp y email, con la misma tabla de colores alimentando los dos.

Una última recomendación de secuencia: empieza por dos o tres categorías con color bien calibrado antes de activar el Full Look. Es más fácil ganar confianza interna con un labial impecable que con trece productos aproximados.

¿Quieres evaluarlo? Crea tu cuenta y tu clave en la documentación de la API para empezar hoy con la prueba por foto, o habla con el equipo de B4A para solicitar acceso al SDK en early access.