Checklist de evaluaciones de intereses legitimos para fundadores y responsables de compliance

Una evaluacion de intereses legitimos solo es util si ayuda al equipo a decidir, antes de empezar el tratamiento, si el articulo 6(1)(f) del GDPR puede sostener una actividad concreta. La checklist debe obligar a contestar tres preguntas: que interes legitimo se persigue, si el tratamiento es necesario para ese fin y si los intereses o derechos de la persona prevalecen.

Para fundadores y responsables de compliance, el objetivo no es convertir cada idea de producto en un memo legal. Es crear un registro repetible que producto, legal, seguridad y operaciones puedan usar cuando una nueva funcionalidad, proveedor, analitica, control antifraude, proceso de soporte o cambio de seguridad de cuenta dependa de intereses legitimos.

Usa esta checklist cuando se considere intereses legitimos como base juridica, cuando una LIA anterior haya quedado desactualizada o cuando la due diligence de clientes pregunte como se documentan las decisiones de privacidad. Encaja con data protection by design and default, revisiones de privacidad durante la planificacion de producto y planificacion de compliance GDPR.

1. Confirmar que intereses legitimos es el candidato correcto

Empieza comprobando si el equipo esta eligiendo entre bases juridicas o simplemente usando la que parece mas flexible. Intereses legitimos no es un sustituto de analizar consentimiento o contrato. Solo encaja cuando el responsable o un tercero tiene un interes real, el tratamiento es necesario para ese interes y los intereses, derechos y libertades de la persona no prevalecen.

Registra la actividad en lenguaje claro. Nombra area de producto, sistema, categoria de datos, grupo afectado, finalidad, owner, proveedores, periodo de retencion y fecha prevista de lanzamiento o cambio. Si la actividad no puede describirse claramente, el equipo aun no esta preparado para evaluar la base juridica.

Comprueba tambien si otra base encaja mejor. Contrato puede ser mejor para tratamientos necesarios para entregar el servicio solicitado. Obligacion legal puede aplicar cuando una norma exige el tratamiento. Consentimiento puede ser necesario cuando el usuario debe tener una eleccion real, sobre todo en ePrivacy, cookies, tracking o marketing directo.

2. Definir el interes legitimo con precision

La prueba de finalidad debe identificar un interes especifico, no una preferencia de negocio vaga. "Mejorar el producto" es demasiado amplio. "Usar eventos agregados de onboarding para identificar donde abandonan los usuarios de negocio" se puede evaluar. "Seguridad" es demasiado generico. "Procesar metadatos de login durante 30 dias para detectar credential stuffing y accesos sospechosos" describe un caso real.

Escribe quien se beneficia. La empresa puede beneficiarse por prevencion de fraude, seguridad de cuentas, mejora del servicio o soporte B2B. Clientes o usuarios pueden beneficiarse con cuentas mas seguras, servicio mas fiable, menos abuso o mejor rendimiento del producto. Tambien terceros pueden tener un interes legitimo, pero el registro debe explicarlo.

El interes debe ser licito, especifico y actual. No debe depender de una finalidad contraria a otra ley, incompatible con el aviso de privacidad o basada en reutilizar datos de una forma que los usuarios no esperarian razonablemente.

3. Probar necesidad antes de disenar controles

Necesidad no significa conveniencia. Significa que el fin no puede alcanzarse razonablemente con un metodo menos intrusivo. Antes de aprobar la base, pregunta si bastaria con menos datos, menor retencion, datos agregados, seudonimizacion, un conjunto mas limitado de eventos, acceso restringido, procesamiento local u otro flujo.

Documenta alternativas consideradas y por que se aceptaron o rechazaron. Este suele ser el tramo mas importante del registro. Si un cliente o autoridad pregunta por que eran necesarios datos a nivel de usuario en vez de metricas agregadas, el equipo no deberia reconstruir la razon meses despues.

En SaaS, las alternativas comunes incluyen analitica agregada en vez de analitica a nivel de usuario, logs muestreados, menor retencion diagnostica, dashboards limitados por rol, opt-outs, feature flags, enrichment diferido y excluir campos sensibles del data warehouse.

4. Ejecutar la prueba de equilibrio

La prueba de equilibrio pregunta si los intereses, derechos fundamentales o libertades de la persona prevalecen sobre el interes legitimo. El considerando 47 destaca las expectativas razonables segun la relacion entre la persona y el responsable. El equipo debe preguntar que esperarian usuarios, admins, empleados, prospects o contactos de cliente en el contexto de recogida.

Evalua la naturaleza de los datos. Datos de categorias especiales, datos penales, datos de menores, financieros, ubicacion, contenido de comunicaciones, tickets sensibles de soporte y perfiles de comportamiento detallados requieren mas cuidado. Considera tambien si los datos vienen de la persona, de un administrador de cliente, de una fuente externa o del comportamiento observado en el producto.

Evalua el impacto. Podria afectar al acceso al servicio, crear profiling injusto, exponer informacion confidencial, dificultar derechos, sorprender a usuarios, ampliar vigilancia interna o crear riesgo de seguridad? Cuanto mayor sea el impacto, mas fuertes deben ser el interes y las salvaguardas.

5. Identificar salvaguardas y tareas de implementacion

Una LIA no debe terminar con "aprobado". Debe crear salvaguardas concretas que ingenieria, producto, legal, seguridad y operaciones puedan implementar. Incluyen minimizacion, agregacion, seudonimizacion, restricciones de acceso, limites de retencion, lenguaje claro en el aviso de privacidad, opt-out o suppression, restricciones a proveedores, monitorizacion y fechas de revision.

Convierte las salvaguardas en tickets o controles. Si la evaluacion depende de retencion de 90 dias, enlaza la configuracion o tarea. Si depende de acceso interno restringido, enlaza el rol o grupo que lo aplica. Si depende de actualizar el aviso de privacidad, asigna owner y plazo.

Aqui GDPR mas alla de banners de cookies se vuelve operativo. La mejor evidencia no es un PDF perfecto, sino un registro breve de decision conectado a los cambios del sistema.

6. Decidir, aprobar y registrar el resultado

La decision debe ser explicita. Registra si el equipo puede basarse en intereses legitimos, no puede basarse en ellos o solo puede hacerlo despues de implementar salvaguardas concretas. Incluye owner, revisor, fecha, evidencias enlazadas y proximo desencadenante de revision.

Evita aprobaciones condicionales que nadie sigue. Si la respuesta es "si, cuando se reduzca la retencion y se actualice el aviso", la LIA debe seguir abierta hasta completar esas tareas. Si la respuesta es "no", documenta la base alternativa o la decision de parar o rediseniar el tratamiento.

El registro debe ser lo bastante corto para mantenerse. Para riesgo moderado, una pagina estructurada suele bastar. Actividades de mayor riesgo pueden exigir una revision mas profunda o una DPIA.

7. Actualizar la evaluacion cuando cambien los hechos

Las LIAs caducan cuando cambian los hechos. Reabre el registro cuando cambie la finalidad, se amplien categorias de datos, aumente la retencion, entre un nuevo proveedor, se anada un modelo o automatizacion, se amplie acceso interno, cambie el grupo afectado o la experiencia de usuario sea materialmente distinta.

Anade una fecha de revision incluso para tratamientos estables. Para menor riesgo, una revision anual puede bastar. Para monitorizacion de seguridad, fraude, enrichment, soporte asistido por IA, analitica a nivel de usuario o datos operativos sensibles, revisa con mas frecuencia o en ciclos de release importantes.

FAQ

Que deben entender los equipos sobre las evaluaciones de intereses legitimos?

Deben entender que una LIA es un registro estructurado de decision. Prueba finalidad, necesidad, equilibrio, salvaguardas, ownership y desencadenantes de revision para una actividad concreta.

Por que importan en la practica?

Importan porque permiten decidir la base juridica antes de que diseno de producto, proveedores, analitica, monitorizacion de seguridad o compromisos con clientes sean dificiles de cambiar.

Cual es el mayor error?

El mayor error es tratar la LIA como papeleo despues de que la decision ya se tomo. Debe influir en el diseno, no solo documentarlo.

Fuentes

• Union Europea, Reglamento General de Proteccion de Datos, articulo 6 y considerando 47.
• European Data Protection Board, Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR.
• Information Commissioner's Office, guia detallada sobre legitimate interests, actualizada el 23 de marzo de 2026.