Qué campos enmascarar antes de enviar un ticket o un chat

Soporte pega el mensaje de un cliente en Zendesk o Freshdesk. Operaciones exporta la hoja de inscripciones a Slack, Teams o WhatsApp. Un desarrollador suelta un registro de error en el hilo. Esos tres gestos ocurren cada día. El artículo anterior cubría qué parámetros de URL quitar: utm_source y fbclid pueden irse; id= tiene que quedarse. Tras esa pasada, mucha gente se detiene. Un móvil como 612 34 56 78, un DNI, un PAN y un correo no desaparecen porque el enlace sea más corto.

La pregunta no es «¿hay que enmascarar?». Es cómo separar dos familias de cadenas. Todo lo que permite localizar a una persona o mover dinero debe pasar detrás de asteriscos. Un número de pedido, una clave de ticket y un SKU localizan el trabajo, no a la persona: si los tapan, el siguiente turno no abre el mismo expediente. La tabla, las excepciones y las comprobaciones de abajo se quedan en esa única decisión. La página Limpiar URL de MyPassGen aplica el mismo corte al texto. Este artículo no es un recorrido por la herramienta. Responde qué campos enmascarar antes de reenviar un ticket o un chat, y cómo verificar el resultado.

Una URL limpia no limpia el cuerpo

El artículo 4 del RGPD define dato personal como cualquier información sobre una persona física identificada o identificable. Un teléfono, un DNI o un correo en un ticket caen del lado «identificable». Reenviar el original entero al canal siguiente, a la hoja siguiente o al «enmascarador en línea» siguiente es reenviar también esa capacidad de identificar. En España, la Ley Orgánica 3/2018 (LOPDGDD) concreta ese marco; la autoridad de control es la AEPD.

El artículo 9 trata la salud, la biometría y categorías similares como datos especiales. El artículo 5 fija la minimización: envía solo lo que la persona siguiente necesita para terminar el trabajo, no el expediente completo. Pegar un PAN entero en Slack, o dejar el contacto de un menor en un ticket público, no supera esa prueba. Un DNI o un NIE en claro en un hilo de equipo o en un export «para el proveedor» suele ser más de lo necesario.

Las normas no colocan cada asterisco por ti. Fijan un valor por defecto: la copia que envías debe permitir seguir trabajando sin ver un número completo. Si basta una máscara o un identificador de ticket, envía eso. Si una persona concreta debe recibir una clave todavía usable, no la escribas en el cuerpo del ticket. Usa un canal de un solo uso.

Campos que hay que enmascarar

La tabla agrupa campos que de verdad aparecen en tickets, listas de inscripción, presentaciones y registros pegados. No es un catálogo de cumplimiento exhaustivo —los proveedores inventan prefijos nuevos—, pero cubre los valores que más se escapan. Tras la máscara, el lector debería reconocer «esto es un teléfono / un documento / un correo» y ya no poder usarlo tal cual.

Teléfono: si aún se puede marcar, no has terminado

La recomendación UIT-T E.164 limita un número público internacional a 15 dígitos, sin contar el prefijo internacional. El signo más es notación, no un dígito. En España el plan es cerrado: nueve cifras. Los móviles empiezan por 6 o 7; a nivel internacional, +34 precede esas nueve cifras. Una máscara de ticket como 612 *** ** 78 dice al agente siguiente «esto es un teléfono» sin entregarle un número que pueda marcar.

Antes de decidir, extrae las cifras de espacios, paréntesis y +34. No busques solo un bloque compacto de nueve dígitos. Al revés: un bloque de 8 a 15 cifras puede ser un número de pedido. Sin +, sin separador y sin forma móvil reconocible (6, 7, +34, o un +52 / +57 en un ticket latinoamericano), no trates toda secuencia larga como teléfono. Enmascarar el número de pedido es el fallo más habitual: el siguiente turno no cruza la factura.

Documentos de identidad: lo que identifica está en el medio

Un DNI español tiene ocho cifras y una letra. El Ministerio del Interior calcula esa letra con módulo 23: se divide el número entre 23 y el resto (0–22) se sustituye por una letra de una tabla fija. El ejemplo oficial 12345678 da resto 14 y letra Z. Ocho cifras seguidas de una letra no son automáticamente un DNI: si la letra no cuadra, es más probable un identificador de negocio o un error de copia. Un NIE lleva X, Y o Z, siete cifras y la misma letra de control (esas letras iniciales se tratan como 0, 1 y 2).

Dejar solo la letra y mostrar las ocho cifras sigue entregando el identificador. Una forma más prudente para reenviar deja bastante para decir «esto es un DNI» y tapa el bloque central. La misma lógica vale para una CURP mexicana, un RFC, un RUT o una cédula: el medio es lo que apunta a una persona. Un ticket transfronterizo a veces trae un documento chino de 18 cifras; las ocho del centro son una fecha de nacimiento. Tapar solo los cuatro últimos y dejar la fecha sigue reenviando edad y zona.

Tarjetas e IBAN: el techo de visualización no es un objetivo

El número de cuenta principal (PAN) lleva un dígito de control calculado con el algoritmo de Luhn, documentado en el anexo B de ISO/IEC 7812-1. Luhn pilla errores de tecleo. No prueba que la tarjeta esté viva. La longitud suele ser de 13 a 19 dígitos. El techo de PCI DSS para mostrar el PAN es, como máximo, los seis primeros y los cuatro últimos. Si no tienes una necesidad concreta del BIN, no uses el techo entero.

Casi ningún ticket de salida necesita el BIN. Los cuatro últimos bastan para «¿es la que termina en 4242?». Poner el PAN completo y el nombre del titular en el mismo mensaje de Slack apila una cuenta financiera con identidad: peor que dejar solo los cuatro últimos. Trata una secuencia larga como tarjeta solo si pasa Luhn. Si falla, prioriza «identificador de negocio» y deja el número de seguimiento en paz.

Un IBAN español tiene 24 caracteres: ES, dos dígitos de control y el CCC de 20. Para reenviar, suele bastar el código de país y los cuatro últimos. El medio —oficina, dígitos de control de cuenta y número de cuenta— no tiene por qué viajar en un chat de equipo.

Correo, claves y direcciones

La mayor parte de la capacidad identificadora de un correo está antes de @. Deja el primer carácter, tapa el resto, conserva el dominio. Eso suele bastar para distinguir un buzón de empresa de uno personal, y no basta para escribirle. Reenviar local@dominio intacto entrega un canal de contacto a quien abra el hilo.

Las claves API suelen llevar un prefijo de familia: sk- / sk_live_, AKIA / ASIA, AIza, ghp_ / github_pat_, glpat-, npm_, xoxb-, y el token detrás de Bearer. El prefijo nombra la familia. No está para que alguien siga llamando a la API. Si la cadena enmascarada aún autentica, tapaste poco —o nunca debiste poner una clave viva en el ticket. Una clave completa corresponde a un enlace de un solo uso, con la clave detrás de # en la URL. La página de lectura no pide cuenta.

En IPv4, conservar los dos primeros octetos (el rango de documentación 203.0.113.0/24 escrito como 203.0.*.*) suele bastar para ver el operador o el bloque de oficina, y no basta para señalar un equipo. Aplica la misma regla a direcciones privadas, salidas VPN y fibra doméstica que aparecen en un volcado pegado: tapa los dos últimos octetos.

Cifras que no debes tocar

El cuerpo tiene el mismo corte que una cadena de consulta. Algunas cifras parecen aleatorias y están para que la persona siguiente abra el mismo registro. Si las tapas, el relevo se rompe.

• Pedidos y envíos: números de pedido, de seguimiento del transportista, de autorización de devolución. La longitud a menudo se solapa con un teléfono o un PAN, pero la cadena no tiene forma de teléfono ni pasa Luhn.
• Tickets e IDs de objeto: claves de Zendesk / Jira, IDs internos de usuario, SKU, IDs autoincrementales. A menudo reenvías la nota precisamente para que otra persona abra esa fila.
• Compilaciones y relojes: números de build, prefijos cortos de commit, marcas de tiempo. Si los tapas, mueren los pasos de reproducción.

Una comprobación que puedes hacer en el bloc de notas: copia el texto de salida, trata un tipo cada vez (teléfono, luego documento, luego tarjeta) y relee tras cada pasada. ¿Siguen los identificadores de negocio? ¿La frase sigue teniendo sentido? No sustituyas todas las cifras largas por asteriscos y luego adivines cuál rompiste.

El estilo pasaporte —una o dos letras más seis a nueve cifras— se confunde fácil con un localizador de vuelo o una matrícula. Si un dígito de control falla, o las palabras de alrededor hablan de un vuelo y un asiento, déjalo y márcalo a mano. No entregues esa decisión a una sola expresión regular.

Enmascarar no es anonimizar

La AEPD distingue anonimización y seudonimización. El considerando 26 deja la información anónima fuera del Reglamento solo cuando la persona ya no es identificable. El artículo 4.5 define la seudonimización como un tratamiento que ya no puede atribuirse a una persona sin información adicional. Un ticket que dice 612 *** ** 78 más un nombre, una dirección y un número de pedido sigue siendo identificable dentro del helpdesk. Eso es, como mucho, seudonimización. No es anonimización, y no es permiso para publicar.

Escribe el objetivo con precisión: reducir la usabilidad directa en el siguiente reenvío, la siguiente captura, el siguiente canal. Enmascarar no te autoriza a colgar la hoja resultante en una página pública, y no sustituye «envía solo lo necesario». Nombres, calles, caras, datos de menores y claves vivas suelen estar donde una regla no mira: otra columna, píxeles de una captura, o un número partido por espacios.

Apilar nombre, teléfono, documento y domicilio en un solo mensaje es más sensible que un único móvil enmascarado. Si puedes separarlos, no pongas los cuatro en la misma línea de Slack o WhatsApp. Si un número de ticket basta para que la otra persona abra el registro ella misma, no copies el expediente fuera del sistema.

Compruébalo en el momento: texto en paralelo, asteriscos y Red

Los eslóganes no se pueden comprobar. Los caracteres sí. Estos pasos no dependen de una promesa de marca. Bastan un editor local y las herramientas de desarrollo.

1. Pega el original completo en un editor local y guarda una copia sin tocar, para no enmascarar de memoria.
2. Con la tabla de arriba, trata primero los teléfonos, luego documentos, tarjetas y correos. Un tipo por pasada. Deja los IDs de negocio quietos de momento.
3. Pon el original y el resultado uno al lado del otro. Los campos tratados deben mostrar asteriscos o un equivalente. Pedidos, SKU y fechas deben seguir leyéndose.
4. Busca en el resultado un teléfono completo del original, un DNI entero o la parte local antes de @. Si aún lo encuentras, no has terminado.
5. Si una herramienta lista en el navegador los tipos detectados, lee esa lista contra los asteriscos del resultado. Un tipo en la lista con máscara en la salida está hecho. Un tipo en la lista con el valor completo a la vista, no.
6. Abre las herramientas de desarrollo → Red, activa «Conservar registro» y vuelve a enmascarar. Las peticiones de documentos y API no deberían contener el original que acabas de pegar. La analítica no debería llevar un documento o un buzón completo.

La página Limpiar URL de MyPassGen trabaja en ese límite. En el enmascaramiento de datos eliges un tipo cada vez —teléfono, documento, tarjeta, correo, clave API o IP— y comparas original y resultado en paralelo. Los números NANP dejan los cuatro últimos; E.164 conserva una pista de país; un documento chino de 18 cifras se comprueba con ISO 7064 antes de enmascararse; las tarjetas pasan Luhn y se quedan solo con los cuatro últimos (más estricto que «seis primeros + cuatro últimos»); los correos dejan el primer carácter de la parte local. El proceso termina en la pestaña actual. El original no se sube ni se escribe en analítica. No creas una cuenta. La página dice que es una ayuda. En lo importante, sigue haciendo falta una pasada humana.

Capturas, hojas de cálculo y la ilusión de «ya está tapado»

Una hoja es más difícil que un párrafo. El teléfono está en la columna A, el nombre en la B, y el escaneo del DNI es una imagen en la página tres. Las reglas de texto no ven píxeles. Antes de enviar una presentación, busca fotos de documento sin recortar, grabaciones de pantalla que aún muestran un número completo, y un Excel con el original en una columna oculta o en una segunda hoja.

Responder en el chat cita el mensaje anterior. Enmascaraste la última línea; la cita sigue llevando el número completo. Los hilos de Slack, los reenvíos de correo y las notas de Intercom hacen lo mismo. Despliega la cita antes de enviar, o escribe un mensaje nuevo sin ella. Reenviar un hilo entero de correo también reenvía firmas y cuerpos de ticket que nadie tapó al principio.

Un enlace corto o un código QR no arregla el cuerpo. El artículo anterior trataba los acortadores como una capa de redirección. Añade esto: hay quien escribe «pedido de 612 34 56 78» en el título de una página o en utm_content. Después de quitar los nombres de seguimiento, el título y el párrafo siguen ahí. Limpiar una URL y enmascarar texto son dos trabajos. Ninguno sustituye al otro.

Errores frecuentes

«Con los cuatro últimos del teléfono basta.» Dejar las cinco primeras cifras de un móvil español y tapar solo el final sigue dando mucho que cruzar con un volcado de datos. Los cuatro últimos son un compromiso habitual de visualización, no una prueba. En un DNI, dejar las ocho cifras y tapar solo la letra es el mismo trabajo a medias.

«HTTPS ya protege la privacidad.» HTTPS detiene a quien escucha en el camino. El destinatario, cada miembro del canal y cada administrador del helpdesk siguen viendo el texto plano que pegaste. Lo que reduces son números completos innecesarios en la copia que envías.

«Si está enmascarado, ya se puede publicar.» Tras la seudonimización, el helpdesk puede volver a identificar a la persona. Una página pública, un caso externo o un material de formación necesita información que no se pueda revertir sin datos extra. Eso es anonimización. Unos asteriscos no lo son.

«La regla ya corrió, nos saltamos la revisión.» Los números partidos (612 34 56 78), las cifras escritas en letras, los documentos dentro de imágenes y los prefijos de clave que la regla aún no conoce se escapan. La pasada humana pregunta: ¿puedes buscar en el resultado un original completo, y el contexto restante puede montar a la misma persona?

Por dónde empezar a enmascarar

Empieza por el párrafo que vas a enviar hoy. Cópialo en local, tapa primero los teléfonos, compara con el original y decide si documentos y correos necesitan la misma pasada. Los hilos viejos y las páginas de la base de conocimiento pueden esperar. No tienes que limpiar todo el historial de una sentada.

Si un pegado mezcla una URL y un cuerpo, quita primero UTM e IDs de clic con la tabla del artículo anterior; luego enmascara el cuerpo. Cuando un mensaje lleva a la vez un número de pedido y un teléfono, conserva el pedido, tapa el teléfono y relee la frase. Tras esa pasada ya puedes responder al título: enmascara los campos que localizan a una persona o mueven dinero; deja los IDs que abren el mismo registro de negocio.

Si una persona concreta debe recibir una contraseña viva, un código de recuperación o una clave API, no escribas el secreto completo en el ticket, y no trates una máscara como «no lo enviamos». Genera un enlace de un solo uso. Un archivo que deba poder descifrarse más de una vez corresponde a Cifrar, que construye un .lock / .enc en este dispositivo; envía la contraseña en otro mensaje. Enmascarar texto reduce números completos en una conversación. No es un canal para intercambiar claves.

Preguntas frecuentes

Después de enmascarar, ¿la otra persona sigue sabiendo de quién se trata?

A menudo sí. Un ID de ticket, un nombre y un móvil enmascarado juntos siguen resolviéndose dentro del helpdesk. Enmascarar reduce la posibilidad de que alguien fuera de ese sistema marque o se haga pasar por esa persona con un número completo. No convierte el texto en estadística anónima.

¿Por qué esta secuencia de nueve cifras no se trató como teléfono?

Una racha larga sin forma de móvil español, sin + y sin separador es más probable que sea un número de pedido. Tratar toda racha como teléfono tapa el localizador que el siguiente turno necesita. Si no estás seguro, déjala, trata solo las que parecen móvil (6 / 7), +34 u otra forma conocida, y marca el resto a mano.

¿Dejar solo los cuatro últimos de una tarjeta cumple la norma?

El techo de visualización de PCI DSS es seis primeros + cuatro últimos. Solo los cuatro últimos es más estricto y suele bastar para confirmar un final. Sigue sin ser permiso para publicar el número en un canal público. Un PAN completo más un nombre no deberían aparecer en Slack o WhatsApp.

¿Hace falta una cuenta para enmascarar? ¿Se sube el original?

No hace falta cuenta. El riesgo de registro empieza cuando entregas el ticket entero a un sitio que sube el original. El procesamiento local deja el original en la pestaña actual. Lo que compruebas es si Red envió un documento o un buzón completo a un tercero, y si aún puedes buscar en el resultado un número completo sin tapar.