Cómo enmascarar datos sensibles durante el co-browse

El co-browse permite que un agente vea y guíe la pantalla del cliente en tiempo real, pero esa misma potencia crea un riesgo evidente: durante la sesión pueden quedar expuestos números de tarjeta, contraseñas o datos de salud. Aprender a enmascarar datos sensibles durante el co-browse no es un extra opcional, es el requisito que separa una función útil de un problema de cumplimiento. En esta guía verás qué campos ocultar, cómo se configura el enmascarado y qué buenas prácticas evitan filtraciones accidentales.

Qué significa enmascarar en co-browse

Enmascarar significa que el contenido de ciertos elementos de la página nunca sale del navegador del cliente hacia el del agente. El agente ve la estructura de la página (el formulario, los botones, el layout) pero el valor real del campo aparece reemplazado por asteriscos, un bloque gris o simplemente vacío. El cliente sigue escribiendo con normalidad; el agente lo asiste sin llegar a leer el dato.

Esto es distinto de "tapar" algo con una capa visual. Un buen enmascarado ocurre en el origen: el dato se filtra antes de transmitirse, de modo que ni siquiera viaja por la red ni queda en registros o grabaciones de la sesión.

Qué campos deberías enmascarar siempre

No todo es igual de sensible. Como punto de partida, oculta por defecto:

• Datos de pago: número de tarjeta, fecha de expiración y CVV. El CVV nunca debe verse, ni siquiera parcialmente.
• Credenciales: contraseñas, PIN, tokens de un solo uso y respuestas de seguridad.
• Identificadores oficiales: número de documento, seguridad social, pasaporte.
• Datos de salud: diagnósticos, medicación, resultados de laboratorio.
• Datos financieros: saldos, números de cuenta completos, movimientos.

Una regla útil: si un campo no es necesario para que el agente te ayude, enmascáralo. El agente no necesita ver tu contraseña para guiarte a la pantalla correcta.

Cómo se configura el enmascarado

Hay dos enfoques que conviene combinar.

1. Enmascarado por selector

Defines reglas basadas en el HTML: por clase CSS, por atributo name, por tipo de input o por un atributo dedicado como data-cobrowse-mask. Es preciso y predecible. Por ejemplo, marcas todo input[type=password] y todo elemento con la clase .sensitive para que se oculte siempre.

2. Enmascarado por patrón

Como red de seguridad, aplicas reglas que detectan formatos: secuencias que parecen tarjetas (16 dígitos), correos o números largos. Es menos exacto pero atrapa campos que olvidaste etiquetar. No lo uses como única defensa, porque los falsos negativos son caros.

Lo ideal es enmascarar por defecto lo crítico y auditar cada pantalla nueva antes de habilitarla para co-browse.

Buenas prácticas que evitan filtraciones

• Enmascara desde el primer despliegue, no "después". La deuda de privacidad se paga con incidentes.
• Prueba con datos reales de estructura falsa: llena el formulario y confirma desde el lado del agente que no se lee nada.
• Registra y audita: guarda quién inició la sesión, cuándo y sobre qué páginas, pero nunca el contenido enmascarado.
• Da control al cliente: que pueda pausar el compartido o terminar la sesión con un clic siempre visible.
• Limita el alcance: co-browse restringido a tu dominio evita que el agente vea otras pestañas o el correo del cliente.

El equilibrio entre utilidad y privacidad

El error habitual es pensar que más visibilidad es siempre mejor. En realidad, un co-browse bien enmascarado suele resolver igual de rápido: el agente ve dónde está atascado el cliente sin necesitar el dato secreto. La confianza que genera saber que "el CVV no se ve" reduce el abandono en pasos críticos como el pago.

En plataformas omnicanal como Omnifox, el co-browse está pensado para nacer desde una conversación existente y con enmascarado configurable de campos sensibles, de modo que el agente asiste dentro de tu propio dominio sin exponer datos de pago ni credenciales. Así la función se integra con la bandeja, el CRM y el historial del cliente sin abrir un hueco de privacidad.

Lista de verificación rápida

1. Identifica cada campo sensible por pantalla.
2. Enmascara por selector lo crítico y añade patrones como respaldo.
3. Verifica desde el lado del agente que el valor no se transmite.
4. Restringe el co-browse a tu dominio.
5. Da al cliente un botón visible para pausar o terminar.
6. Audita accesos sin registrar contenido.

Enmascarado y grabacion de sesiones

Muchas empresas graban las sesiones de soporte para formacion o auditoria. Aqui el enmascarado es doblemente importante: si el dato se filtra en el origen, tampoco aparecera en la grabacion. Confirma que tu herramienta enmascara ANTES de capturar, no despues. Una grabacion con un CVV visible es una fuga que queda archivada.

Algunas recomendaciones:

• Graba solo si tienes una base legal clara y lo informas al cliente.
• Aplica retencion limitada: borra las grabaciones cuando ya no las necesites.
• Restringe quien puede reproducirlas.

Mitos frecuentes

"Si el agente promete no mirar, alcanza." No. La proteccion debe ser tecnica, no una promesa. "Enmascarar rompe la experiencia." Al contrario: el cliente escribe normal y el agente ve el contexto. "Solo el pago necesita proteccion." Falso: credenciales, salud e identificadores oficiales son igual de criticos. La regla es simple: enmascara por defecto y expon solo lo necesario.

Conclusión

Enmascarar datos sensibles durante el co-browse es lo que convierte una función de soporte visual en una herramienta segura y confiable. Con reglas por selector, patrones de respaldo y control del cliente, ofreces asistencia en tiempo real sin comprometer la privacidad. Si quieres implementar co-browse con enmascarado desde el día uno, dentro de una bandeja omnicanal, prueba Omnifox y configura la protección antes de tu primera sesión.