Las 6 bases legales del tratamiento según el RGPD

Cada vez que su empresa SaaS trata datos personales — cada registro de base de datos, cada evento de analítica, cada correo electrónico enviado, cada entrada de log — necesita una base legal para ese tratamiento. Esto no es una formalidad. El artículo 6 del RGPD exige que cada actividad de tratamiento esté fundamentada en una de las seis bases legales específicas. Sin una base válida, el tratamiento es ilícito — sin más.

Elegir la base legal correcta para cada actividad tiene consecuencias en cascada. Determina qué debe comunicar a las personas en su aviso de privacidad, si los interesados pueden oponerse al tratamiento, si puede transferir los datos internacionalmente y qué ocurre si se cuestiona su base legal.

Esta guía explica las seis bases, cuándo usar cada una y las implicaciones prácticas para las empresas SaaS.

Las seis bases legales

1. Consentimiento — Artículo 6(1)(a)

Qué significa: El interesado ha dado su acuerdo claro y afirmativo al tratamiento de sus datos personales para una o más finalidades específicas.

Cuándo usarlo:

• Correos electrónicos de marketing y boletines
• Cookies y tecnologías de seguimiento no esenciales
• Tratamiento que va más allá de lo necesario para prestar su servicio
• Funcionalidades opcionales que implican nuevos tipos de tratamiento de datos
• Investigación o encuestas

Cuándo NO usarlo:

• Tratamiento necesario para prestar su servicio (use la necesidad contractual en su lugar)
• Tratamiento que hará independientemente de que la persona consienta
• Situaciones donde la persona no puede rechazar de forma realista (desequilibrio de poder)

Requisitos: El consentimiento según el RGPD tiene requisitos estrictos — libremente otorgado, específico, informado e inequívoco. Las casillas premarcadas no cuentan. El consentimiento agrupado que cubra múltiples finalidades no cuenta. Y debe hacer que la retirada sea tan fácil como el otorgamiento original. Consulte nuestra guía de gestión del consentimiento para los requisitos completos.

Implicación clave: Si el consentimiento es su base y alguien lo retira, debe detener el tratamiento. No puede cambiar a una base legal diferente retroactivamente.

Ejemplo SaaS: Un SaaS de gestión de proyectos quiere enviar a los usuarios un boletín mensual con consejos de productividad. Esto es independiente del servicio al que se registraron. El consentimiento es la base correcta — el usuario opta activamente, y el boletín se detiene si cancela la suscripción.

2. Necesidad contractual — Artículo 6(1)(b)

Qué significa: El tratamiento es necesario para la ejecución de un contrato con el interesado, o para la aplicación de medidas precontractuales a petición de este.

Cuándo usarlo:

• Almacenar y gestionar cuentas de usuario de su producto SaaS
• Procesar información de pago para facturar su servicio
• Prestar las funcionalidades principales de su producto
• Proporcionar soporte al cliente relacionado con el servicio
• Medidas precontractuales como procesar una solicitud de demostración o registro de prueba gratuita

Cuándo NO usarlo:

• Tratamiento que es útil pero no necesario para el contrato (analítica, marketing, mejora del producto)
• Tratamiento que sirve a sus intereses más que a la prestación del servicio
• Tratamiento de funcionalidades que el usuario no ha activado ni adquirido

La prueba de “necesidad”: El tratamiento debe ser genuinamente necesario para ejecutar el contrato — no meramente útil o deseable. Almacenar el nombre y correo electrónico de un usuario para que pueda iniciar sesión es necesario. Rastrear sus movimientos de ratón para un mapa de calor no es necesario para el contrato, aunque le ayude a mejorar el producto. El CEPD ha sido claro: la necesidad contractual debe interpretarse de forma restrictiva.

Ejemplo SaaS: Un SaaS de CRM almacena registros de contactos de clientes, datos del pipeline de acuerdos y registros de actividad porque la finalidad misma del servicio es gestionar esos registros. Tratar estos datos es directamente necesario para ejecutar el contrato.

3. Obligación legal — Artículo 6(1)(c)

Qué significa: El tratamiento es necesario para cumplir una obligación legal a la que está sujeto el responsable.

Cuándo usarlo:

• Conservar registros financieros para declaraciones fiscales (típicamente 7-10 años)
• Informar a los reguladores financieros (prevención del blanqueo de capitales)
• Cumplir con órdenes judiciales o procedimientos legales
• Requisitos de la legislación laboral (nóminas, seguridad social, registros de salud y seguridad en el trabajo)
• Obligaciones de reporte regulatorio

Cuándo NO usarlo:

• Conservación “por si acaso” — la obligación debe ser específica y actual
• Mejores prácticas del sector que no están legalmente mandatadas
• Obligaciones contractuales (use la necesidad contractual en su lugar)

El requisito de especificidad: Debe poder señalar una ley, regulación u obligación legal específica que exija el tratamiento. “Podríamos necesitar esto por motivos legales” no cualifica. La obligación debe ser real, actual y aplicable a su organización.

Ejemplo SaaS: Una empresa SaaS conserva facturas de clientes y registros de pago durante 10 años para cumplir con la legislación fiscal alemana (Abgabenordnung). La ley específica y el plazo de conservación se documentan en el RAT.

4. Intereses vitales — Artículo 6(1)(d)

Qué significa: El tratamiento es necesario para proteger los intereses vitales del interesado o de otra persona física.

Cuándo usarlo: Esencialmente solo en situaciones de vida o muerte — emergencias médicas, desastres naturales, crisis humanitarias.

Relevancia para SaaS: Esta base casi nunca es aplicable a las empresas SaaS. Si está construyendo un producto de monitorización de salud o respuesta a emergencias, podría aplicarse en casos extremos. Para las operaciones empresariales estándar, mire las otras cinco bases.

5. Interés público / Autoridad oficial — Artículo 6(1)(e)

Qué significa: El tratamiento es necesario para el cumplimiento de una misión realizada en interés público o en el ejercicio de poderes públicos conferidos al responsable.

Cuándo usarlo: Organismos gubernamentales, entidades públicas y organizaciones que desempeñan funciones de interés público (salud pública, investigación, archivo).

Relevancia para SaaS: Raramente aplicable a menos que esté contratado por un organismo gubernamental para realizar una función pública. Si es una empresa SaaS privada, es improbable que esta base se aplique a alguna de sus actividades de tratamiento.

6. Interés legítimo — Artículo 6(1)(f)

Qué significa: El tratamiento es necesario para los fines de los intereses legítimos perseguidos por el responsable o por un tercero, excepto cuando prevalezcan los intereses, derechos o libertades fundamentales del interesado.

Cuándo usarlo:

• Analítica de producto y seguimiento de uso (agregado, no intrusivo)
• Prevención de fraude y monitorización de seguridad
• Seguridad de redes e información (incluido el registro y monitorización)
• Administración interna y operaciones empresariales
• Marketing directo a clientes existentes (en algunas jurisdicciones, con garantías apropiadas)
• Encuestas de satisfacción del cliente
• Seguimiento de errores y reporte de bugs

Cuándo NO usarlo:

• Tratamiento que es principalmente para su beneficio con impacto significativo en los individuos
• Elaboración de perfiles a gran escala sin transparencia
• Tratamiento que las personas no esperarían razonablemente
• Cuando el consentimiento u otra base es más apropiada

La prueba de ponderación: El interés legítimo es la base más flexible, pero requiere una prueba de ponderación documentada — la Evaluación de Interés Legítimo (EIL). Debe sopesar sus intereses contra los derechos y expectativas del interesado. Si los intereses del interesado prevalecen sobre los suyos, el interés legítimo no funciona.

El proceso de EIL:

1. Identifique el interés legítimo. ¿Qué interés específico está persiguiendo? Debe ser real, no hipotético.
2. ¿Es el tratamiento necesario? ¿Podría lograr el mismo objetivo sin los datos, o con menos datos?
3. Pondere contra los intereses del interesado. Considere: ¿Esperarían las personas este tratamiento? ¿Cuán intrusivo es? ¿Podría causar daño? ¿Qué garantías existen?
4. Documente la evaluación. Registre su análisis y conclusión.

Ejemplo SaaS: Una empresa SaaS usa analítica de producto para rastrear qué funcionalidades se usan, con qué frecuencia y por cuántos usuarios. Los datos se seudonimizan y agregan para el análisis. El interés legítimo es la mejora del producto; el impacto en los usuarios es mínimo (sin elaboración de perfiles individuales, sin datos sensibles, alineado con las expectativas del usuario). Una EIL documentada respalda esta base.

Cómo elegir la base correcta

Marco de decisión

Para cada actividad de tratamiento, siga este orden:

1. ¿Existe una obligación legal? Si la ley exige el tratamiento, use la obligación legal. Esta es la base más clara.

2. ¿Es el tratamiento necesario para un contrato? Si el tratamiento es genuinamente necesario para prestar el servicio al que se registró la persona, use la necesidad contractual.

3. ¿Se aplica el interés legítimo? Si el tratamiento sirve a un interés empresarial real, es proporcionado y no sorprendería al interesado, realice una prueba de ponderación. Si la supera, el interés legítimo puede ser la base correcta.

4. ¿Es apropiado el consentimiento? Si ninguna de las anteriores se aplica — el tratamiento es opcional, sirve a sus intereses más que a los del usuario, o la persona debería tener una elección genuina — use el consentimiento.

Actividades de tratamiento comunes en SaaS y sus bases

Actividad de tratamiento	Base recomendada	Justificación
Creación y gestión de cuentas de usuario	Necesidad contractual	Necesario para prestar el servicio
Procesamiento de pagos	Necesidad contractual + Obligación legal	Contrato para facturación; ley fiscal para registros
Funcionalidad principal del producto	Necesidad contractual	Para lo que el usuario se registró
Soporte al cliente	Necesidad contractual	Parte de la prestación del servicio
Analítica de producto (seudonimizada)	Interés legítimo	Mejora del producto, bajo impacto
Monitorización de seguridad y registro	Interés legítimo	Seguridad de red, prevención de fraude
Correos de marketing a prospectos	Consentimiento	No existe relación de cliente previa
Correos de marketing a clientes (productos similares)	Interés legítimo (varía por país)	Soft opt-in permitido en algunas jurisdicciones
Boletín a no clientes	Consentimiento	No existe relación previa
Cookies no esenciales	Consentimiento	Requisito de la Directiva ePrivacy
Procesamiento de nóminas de empleados	Necesidad contractual + Obligación legal	Contrato laboral y legislación fiscal
Datos de candidatos	Consentimiento o Interés legítimo	Depende de la jurisdicción y contexto
Conservación de registros financieros	Obligación legal	Legislación fiscal y contable
Investigación de mejora del producto	Interés legítimo o Consentimiento	Depende de los datos usados y la metodología

Errores comunes

Recurrir al consentimiento por defecto para todo. El consentimiento parece la opción más segura — “preguntamos y aceptaron”. Pero basarse en el consentimiento cuando no es la base correcta crea problemas. Si el consentimiento no es libremente otorgado (porque rechazarlo significa perder el servicio), es inválido. Y si realmente no dejaría de tratar cuando se retira el consentimiento, no está siendo honesto sobre su base legal.

No documentar la base elegida. Su RAT debe registrar la base legal para cada actividad de tratamiento, junto con la justificación. Las autoridades de control preguntarán por esto. “Pensamos que el interés legítimo estaba bien” sin una EIL documentada no demuestra responsabilidad proactiva.

Usar una base pero comunicar otra. Su aviso de privacidad debe indicar con precisión qué base legal se aplica a cada finalidad de tratamiento. Si su aviso dice “consentimiento” pero realmente se basa en el interés legítimo, hay una desconexión que crea problemas tanto legales como de confianza.

Intentar cambiar de base cuando se cuestiona. Si alguien retira el consentimiento, no puede reclamar retroactivamente que tenía un interés legítimo todo el tiempo. El CEPD ha dejado claro que cambiar de base para evitar las consecuencias de la elección original no está permitido. Elija cuidadosamente desde el principio.

Confundir interés legítimo con “tenemos una razón”. Toda organización tiene razones para tratar datos. El interés legítimo requiere más — una evaluación documentada que muestre que su interés es real y específico, que el tratamiento es necesario para ese interés y que los derechos del interesado no prevalecen.

Cómo GRCTrail respalda la documentación de bases legales

GRCTrail le ayuda a documentar y mantener sus elecciones de base legal:

RAT con seguimiento de bases legales. Cada actividad de tratamiento en su Registro de Actividades de Tratamiento incluye la base legal documentada, vinculada a las evaluaciones de respaldo (EIL para interés legítimo, registros de consentimiento para consentimiento).

Comprobaciones de coherencia. GRCTrail señala inconsistencias entre su base legal documentada y su aviso de privacidad publicado, ayudando a garantizar que lo que comunica a los interesados coincide con su documentación interna.

Plantillas de EIL. Realice y documente Evaluaciones de Interés Legítimo usando plantillas estructuradas que cubren todos los elementos requeridos.

Documente sus bases legales de forma sistemática →

Guías relacionadas

• Gestión del consentimiento — Cuando el consentimiento es la base correcta
• Registro de Actividades de Tratamiento (RAT) — Documentación de su tratamiento y bases
• Requisitos del aviso de privacidad — Comunicar sus bases legales a los interesados
• Lista de verificación de cumplimiento del RGPD — El marco de cumplimiento completo

Comience con GRCTrail →