Qué datos personales salen, hacia quién y con qué derecho

Cuando un SDK de analítica recibe «el SHA-256 del correo», parece que no recibe el correo. Pero un hash sin sal de un dato predecible se puede volver a calcular: quien tenga una lista de correos calcula sus hashes y los compara. El proveedor, además, usa ese hash precisamente para reconocer a la misma persona en otras aplicaciones y servicios, que es el contrario de anonimizar.

Un dato está anonimizado cuando no se puede relacionar con una persona por ningún medio razonable. Un identificador estable, hasheado o no, sigue siendo un dato personal: es seudonimización, que reduce el riesgo pero no lo elimina.

Hay un tipo de salida que preocupa más que las demás: la que describe a personas que nunca instalaron la aplicación ni aceptaron nada. Subir la agenda de contactos a un tercero entrega nombres y teléfonos de gente que no sabe que existe esta aplicación. Quien sube la agenda no puede consentir por ellos.

Lee SELECT * FROM campos_salientes y busca el campo cuya descripción habla de la agenda de la persona.

La política interna de Cuncuna clasifica cada dato en alta, media o baja, y fija una regla: lo alto solo sale si la función lo exige o con consentimiento específico. Los destinos de analítica, publicidad y atribución no son funciones sin las que la bicicleta no se desbloquee: son finalidades del negocio. Todo campo de sensibilidad alta que vaya a uno de ellos pide una justificación, y a publicidad la política lo prohíbe.

Cuenta los campos de sensibilidad alta cuyo destino tiene alguna de esas tres finalidades; los destinos de pagos, fallos o identidad no entran en esta cuenta.

Los informes de fallos son útiles y peligrosos: recogen textos de error escritos por programadores que no pensaron en quién los leería. Un mensaje que incluye el correo de quien sufrió el error mete un dato personal en un sistema pensado para mensajes técnicos, que además se retiene por mucho tiempo y lo leen más personas de las que deberían. La corrección es del equipo: limpiar el mensaje antes de enviarlo.

El primer reflejo es poner un aviso más grande. La remediación más sólida es otra: minimizar. Enviar solo lo que la finalidad necesita, redondear la ubicación a la precisión que la función pide, sustituir el correo por un identificador interno, quitar del mensaje de error los datos de la persona, y desactivar en la configuración del SDK la recogida de lo que no se usa. Lo que no sale no necesita consentimiento, ni contrato, ni línea en la etiqueta.