Eliminación de Datos
Un marco de campaña para eliminar los datos personales de un individuo del ecosistema comercial de recolección de datos — motores de búsqueda de brechas, herramientas OSINT, sitios de búsqueda de personas, bases de datos de contacto B2B, servicios de verificación de correo electrónico, corredores de datos publicitarios y plataformas de inteligencia de amenazas.
Construido a partir de una campaña real de quince semanas contra 329 organizaciones. Todo en references/ está probado en campo: las direcciones de contacto son las que no rebotaron, las plantillas son las que produjeron eliminaciones, y los modos de fallo documentados en references/troubleshooting.md son los que realmente ocurrieron.
Qué no es esta habilidad
No es asesoramiento legal, y no eres el abogado del usuario. Redacta solicitudes que citan estatutos, y puede indicar al usuario qué regulador tiene jurisdicción, pero cada decisión sobre escalar a un regulador o a un tribunal es del usuario. Dilo una vez, al principio, y luego continúa siendo útil.
Paso 1 — Construir el perfil del sujeto
Las solicitudes de eliminación fallan cuando son vagas. Antes de redactar nada, recopila el perfil. Usa AskUserQuestion donde la interfaz lo soporte; de lo contrario, pregunta en texto plano. Nunca adivines estos valores ni los arrastres de otro usuario.
Obligatorio
- Nombre completo, exactamente como desea que aparezca en los formularios. Pregunta específicamente sobre diacríticos — muchos formularios alojados en EE. UU. alteran
í,ó,ü, y una solicitud que llega con un nombre corrupto es una solicitud que no coincide con un registro. - Direcciones de correo electrónico a eliminar. La mayoría de las personas tienen más de una, y la dirección olvidada de hace una década suele ser la que está en los corpus de brechas.
- País de residencia. Esto solo determina qué ley se aplica y, por lo tanto, qué plantilla usar. No lo infieras de un dominio o un idioma.
Preguntar, pero proceder sin ello
- Nombres de usuario / handles. Varios motores de búsqueda de brechas (Snusbase, DeHashed, Leak-Lookup) indexan por nombre de usuario, por lo que un handle es un selector de búsqueda distinto y necesita su propia solicitud.
- Números de teléfono, y direcciones postales actuales y anteriores — requeridas por la mayoría de las exclusiones de búsqueda de personas en EE. UU., irrelevantes para la mayoría de las solicitudes de la UE.
- Fecha de nacimiento. Algunos corredores de EE. UU. la exigen para desambiguar registros. Advierte al usuario antes de que la entregue: le está dando a un corredor de datos un campo nuevo que quizás no tenía.
Nunca
Nunca preguntes, transcribas o coloques en una solicitud: números de identificación gubernamentales, números de pasaporte o licencia de conducir, detalles de tarjetas de pago o cuentas bancarias, o una fotografía de un documento de identidad. Algunos corredores exigen identificación para "verificar" una solicitud de eliminación. Según el Art. 12(6) del RGPD, un controlador solo puede solicitar identificación que sea proporcionada, y un documento censurado normalmente es suficiente. Dile al usuario que censure todo excepto el nombre y la foto, y que lo suba él mismo a través del portal del controlador — tú no manejas sus documentos de identidad.
Almacena el perfil completado como profile.yml (ver profile.example.yml), y mantenlo fuera de cualquier repositorio o ubicación compartida.
Paso 2 — Elegir la base legal
Lee references/privacy-laws.md. Cubre trece regímenes — RGPD, RGPD del Reino Unido, FADP suizo, CCPA/CPRA y las demás leyes estatales de EE. UU., PIPEDA y la Ley 25 de Quebec, LGPD, POPIA, la Ley de Privacidad de Australia, APPI, PIPA, DPDP y la Ley de Privacidad de Nueva Zelanda — con, para cada uno, el artículo operativo, el plazo legal, si la eliminación es un derecho real o solo una eliminación a solicitud, y el regulador al que reclamar.
Tres reglas deciden el encuadre:
- La residencia del sujeto establece el piso, no la dirección del controlador. El Art. 3(2) del RGPD alcanza a cualquier controlador que ofrezca bienes o servicios a personas en la UE o que monitoree su comportamiento. Un motor de búsqueda de brechas de EE. UU. que indexa la dirección de un residente irlandés está dentro del ámbito del RGPD. Dilo en la solicitud.
- Cita cada régimen que plausiblemente aplique, en una sola solicitud. Un controlador con usuarios en California, Brasil y la UE no tiene incentivos para determinar qué ley lo vincula si nombras las tres. Esto cuesta una oración extra y aumenta materialmente la tasa de respuesta.
- Donde la ley del sujeto es débil, toma prestada la del controlador. Un sujeto en un país sin derecho de eliminación puede invocar las obligaciones del controlador en California o la UE cuando la política de privacidad del controlador extiende esos derechos a todos — la mayoría lo hace, porque operar dos procesos es más costoso que operar uno.
Paso 3 — Seleccionar objetivos
references/site-registry.md (y el CSV junto a él) enumera 329 organizaciones en nueve categorías con contactos de privacidad verificados. No envíes las 329. Selecciona según a lo que el sujeto está realmente expuesto:
| Si el sujeto… | Prioriza |
|---|---|
| aparece en corpus de brechas / HIBP | Búsqueda de brechas y filtraciones, Inteligencia de amenazas |
| es localizable por correo electrónico en herramientas OSINT | OSINT / inteligencia de correo |
| tiene un perfil profesional público | Datos de contacto B2B y generación de leads |
| es residente o ex residente de EE. UU. | Búsqueda de personas, Grandes corredores de datos |
| quiere reducir la publicidad dirigida | Datos publicitarios y de audiencias |
| vive en Reino Unido/DE/AT/BE/FR | Directorio regional |
Comienza con las categorías que publican datos en la web abierta — búsqueda de brechas, OSINT, búsqueda de personas. Esas producen resultados visibles más rápido y son las que más dañan. La publicidad dirigida es la categoría más grande y la menos visible; déjala para una oleada posterior.
Antes de cada oleada, verifica que la dirección de contacto siga activa. Las empresas se adquieren, las páginas de privacidad se mueven, y las direcciones privacy@ se deprecan sin previo aviso. Revisa la política de privacidad actual o /.well-known/security.txt. La columna Notas del registro documenta qué direcciones ya se habían vuelto obsoletas una vez.
Encontrar los sitios que el registro omite
Un registro es una instantánea. Esta categoría cambia más rápido que casi cualquier otra: nuevos servicios de búsqueda de credenciales se lanzan mensualmente, los antiguos son secuestrados o desaparecen, y los nombres más sonados no son los que tienen más datos. Asume que la lista está incompleta y ejecuta estas cuatro barridas al inicio de cada campaña.
1. Explota los agregadores para obtener sus proveedores upstream. La jugada de mayor rendimiento. Los servicios que revenden datos de brechas a través de una API publican la lista de fuentes que consultan — es un punto de venta. Una página de este tipo nombró quince proveedores upstream, cinco de los cuales no aparecían en ningún artículo de "mejor búsqueda de brechas". Esas páginas son una lista de objetivos gratuita escrita por la propia industria. Envía al agregador una solicitud del Artículo 19 nombrando a sus proveedores, y pregúntale a cuáles reenvió la eliminación.
2. Busca por el tipo de dato, no por el tipo de sitio. "Motor de búsqueda de brechas" muestra los mismos ocho nombres famosos cada vez. Los servicios que exponen más buscan en los contenidos: stealer logs, combolist, ULP, infostealer lookup, plaintext passwords, session cookies, hardware ID. Un sitio que devuelve una contraseña junto a la URL a la que pertenece se describe a sí mismo en esos términos, no como un "verificador de brechas".
3. Lee las páginas de alternativas, más allá de la página uno. Los sitios de comparación y listados de alternativas clasifican los servicios conocidos primero y entierran a los pequeños operadores en las páginas dos y tres. Los enterrados suelen ser los que no tienen página de privacidad, ni DPO y los menos escrupulosos — exactamente aquellos a los que vale la pena contactar.
4. Vuelve a verificar un sitio que "no tiene correo electrónico". Un support@ que rebotó o un legal@ que redirige automáticamente a un formulario web no es una respuesta definitiva