Privacidad diferencial y derecho al borrado

La privacidad diferencial es un marco matemático que mide cuánta privacidad pierde una persona por aparecer en un conjunto de datos. En entrenamiento se logra añadiendo ruido controlado, de modo que el resultado casi no cambie si una persona concreta estuviera o no en los datos. Se resume en un número, épsilon: cuanto menor, más ruido, más privacidad y, por lo general, menos utilidad. El NIST publicó en marzo de 2025 la guía SP 800-226, «Guidelines for Evaluating Differential Privacy Guarantees», para evaluar esas garantías; es lectura recomendada, no se exige aquí aplicarla.

No es una varita: una garantía con un épsilon muy alto casi no protege, y mal implementada puede no cumplir lo que promete.

Abre la ficha de privacidad diferencial. Muestra dos corridas de ejemplo sobre un modelo pequeño de clasificación de mensajes, con valores inventados: cada una con su épsilon y la precisión que alcanzó. Elegir entre ellas es una decisión de riesgo, no un puro dato técnico: se pregunta qué protección se necesita y cuánta utilidad se está dispuesto a perder.

Lee los dos épsilon y localiza la corrida con mayor privacidad.

Un titular pide que se borre su dato. Una cosa es borrar la fila de una base y otra borrar todo rastro: su dato puede estar en el CRM, en el registro de conversaciones, en el índice de documentos, en copias de seguridad y, si se usó para afinar, dentro de los pesos de un modelo. El RGPD recoge este derecho en el artículo 17; en Colombia, el artículo 8, literal e, de la Ley 1581 de 2012 reconoce la supresión del dato, con las condiciones que la propia ley fija. Aquí no se discute el alcance legal, sino qué puede hacerse técnicamente en cada sitio.

Abre el mapa del dato de la solicitud y localiza dónde no existe hoy un borrado selectivo.

Cada solicitud de un titular tiene una fecha de recepción y un plazo de respuesta. Las normas fijan los suyos, que hay que consultar en la fuente oficial al caso; en un expediente de trabajo, el plazo que importa es el que el sistema de tickets del responsable anotó como fecha límite, porque es el que las personas van a vigilar.

Lee la solicitud y localiza esa fecha, en el formato AAAA-MM-DD.

La respuesta honesta tiene tres partes: lo que se borró y dónde, lo que se borrará más tarde y cuándo (las copias de seguridad rotan; el afinado no admite borrado selectivo), y qué se hace para que ese dato no vuelva a entrar. Decir «ya se borró todo» cuando un modelo afinado conserva lo que aprendió es un error que se paga cuando alguien lo comprueba.

No hay que prometer lo que técnicamente no se puede cumplir, ni negar lo que sí se puede.