“Protección de Datos: Aclarando conceptos” (Recopilatorio)

 

“Protección de Datos: Aclarando conceptos”

 

En protección de datos ocurre algo que todos los profesionales reconocen: los términos se utilizan constantemente, pero rara vez con precisión. Conceptos como consentimiento, interés legítimo, responsable, encargado, categorías especiales, DPIA, minimización, finalidad, conservación, bloqueo o brecha aparecen en políticas, auditorías y contratos, pero su significado real suele estar distorsionado o simplificado.

La serie que publiqué ayer sobre anonimización y seudonimización —ahora disponible también como recopilatorio— ha puesto de manifiesto esta realidad: cuando se explica un concepto con rigor, ejemplos y orientación práctica, las organizaciones descubren que estaban operando con supuestos equivocados. Y esos supuestos, aunque parezcan pequeños, tienen impacto directo en la validez del tratamiento, la seguridad jurídica y la capacidad de demostrar cumplimiento.

Por eso recupero ahora este ciclo que publiqué en su día y que vuelve a ser especialmente útil en el contexto actual. Su objetivo es aclarar conceptos esenciales del RGPD, explicar qué significan realmente, qué no significan, qué errores cometen las organizaciones y cómo aplicarlos correctamente en la práctica.

El recopilatorio está estructurado en diez entradas que abordan los pilares fundamentales del cumplimiento:

• cómo elegir la base jurídica correcta,
• cómo distinguir responsable, encargado y corresponsable,
• qué son los datos especialmente protegidos,
• cómo diferenciar análisis de riesgos y DPIA,
• cómo aplicar minimización y limitación de la finalidad,
• cómo gestionar conservación, bloqueo y supresión,
• y cómo distinguir incidente de brecha de seguridad.

Publico este recopilatorio ahora porque complementa de forma natural la reflexión sobre trazabilidad, tokenización, gobernanza y ciclo de vida del dato que estamos trabajando estos días. Si esta serie ayuda a clarificar conceptos y a fortalecer la práctica del cumplimiento, habrá cumplido su propósito.

 

Introducción general del ciclo “Protección de Datos: Aclarando conceptos”

En protección de datos ocurre algo curioso: todo el mundo utiliza los mismos términos, pero casi nadie los usa igual. Conceptos como anonimización, seudonimización, base jurídica, minimización, brecha, encargado, transferencia internacional o privacy by design aparecen en políticas, auditorías, contratos y formaciones… pero su significado real suele estar distorsionado, simplificado o directamente mal entendido.

La serie sobre anonimización y seudonimización lo ha demostrado con claridad: cuando se explica un concepto con rigor, con ejemplos y con orientación práctica, las empresas descubren que estaban operando con supuestos equivocados. Y esos supuestos —aunque parezcan pequeños— tienen impacto directo en:

• la validez de un tratamiento,
• la seguridad jurídica,
• la gestión del riesgo,
• la relación con proveedores,
• y la capacidad de demostrar cumplimiento ante una auditoría o una brecha.

Por eso nace este nuevo ciclo: aclarar conceptos complejos que condicionan la práctica diaria del cumplimiento, y hacerlo con un enfoque didáctico, operativo y accesible para directivos, DPOs, equipos técnicos y responsables de negocio.

Cada entrada abordará un concepto que suele generar confusión, explicando:

• qué significa realmente,
• qué no significa (igual de importante),
• qué errores cometen las organizaciones,
• y cómo aplicarlo correctamente en la práctica.

Empezamos con uno de los más mal interpretados: la base jurídica del tratamiento y su eterna confusión con el consentimiento en la entrada 1 de este nuevo ciclo.

 

Entrada 1 — Consentimiento, interés legítimo y contrato: cómo elegir la base jurídica correcta

 

1. Por qué este concepto necesita aclararse

Si hay un error universal en protección de datos es este: creer que todo se basa en pedir consentimiento.

Muchas organizaciones lo utilizan como comodín, incluso cuando:

• no es necesario,
• no es válido,
• o directamente es inaplicable.

El RGPD no funciona así. La base jurídica es la columna vertebral del tratamiento, y elegirla mal implica:

• tratamientos inválidos,
• riesgos jurídicos innecesarios,
• obligaciones mal aplicadas,
• y una pérdida de confianza del usuario.

Esta entrada explica cómo elegir la base jurídica correcta y por qué el consentimiento es solo una de las opciones, no la regla general.

2. Las seis bases jurídicas del RGPD (y por qué no son intercambiables)

El RGPD establece seis bases jurídicas. Las tres más utilizadas —y más confundidas— son:

1) Consentimiento

Válido solo cuando es:

• libre,
• informado,
• específico,
• inequívoco,
• y revocable.

No sirve cuando existe desequilibrio entre las partes (empleados, alumnos, pacientes). No sirve cuando el tratamiento es necesario para un servicio. No sirve cuando la empresa no puede asumir la revocación.

2) Ejecución de un contrato

Aplica cuando el tratamiento es estrictamente necesario para:

• prestar un servicio,
• ejecutar un contrato,
• o tomar medidas precontractuales.

No cubre tratamientos accesorios, analíticos o comerciales.

3) Interés legítimo

Es la base más potente y la más mal entendida. Permite tratar datos cuando:

• existe un interés real del responsable,
• el impacto sobre el interesado es limitado,
• y se realiza una ponderación documentada.

No sirve para todo. No sirve para tratamientos intrusivos. No sirve sin análisis previo.

3. El error más común: usar consentimiento cuando no corresponde

Ejemplos típicos:

• pedir consentimiento a empleados para gestionar nóminas,
• pedir consentimiento a clientes para ejecutar un contrato,
• pedir consentimiento para analítica interna necesaria para el servicio,
• pedir consentimiento para comunicaciones que podrían basarse en interés legítimo.

El resultado es un tratamiento jurídicamente débil, porque:

• el consentimiento puede revocarse,
• la empresa queda expuesta,
• y se genera inseguridad operativa.

4. Cómo elegir correctamente la base jurídica (modelo práctico)

Paso 1 — Pregunta clave

¿Es el tratamiento necesario para prestar el servicio o ejecutar el contrato? → Si la respuesta es sí, la base jurídica es contractual.

Paso 2 — Segunda pregunta

¿El tratamiento responde a un interés legítimo del responsable y tiene un impacto limitado? → Si es así, puede aplicarse interés legítimo (con ponderación).

Paso 3 — Solo si ninguna de las anteriores aplica

→ Consentimiento.

El consentimiento es la última opción, no la primera.

5. Señales de que una empresa está eligiendo mal la base jurídica

• Formularios llenos de casillas de consentimiento innecesarias.
• Políticas que mezclan bases jurídicas sin criterio.
• Tratamientos esenciales basados en consentimiento.
• Ponderaciones inexistentes o genéricas.
• Revocaciones que paralizan procesos internos.

6. Cierre: hacia la Entrada 2

La base jurídica es el primer pilar del cumplimiento. La siguiente entrada abordará otro concepto que genera confusión constante:

Responsable, encargado y corresponsable: quién decide qué, quién ejecuta qué y quién responde de qué.

 

Entrada 2 — Responsable, encargado y corresponsable: quién decide qué, quién ejecuta qué y quién responde de qué

1. Por qué este concepto necesita aclararse

Pocas áreas generan tanta confusión como la distinción entre:

• Responsable del tratamiento,
• Encargado del tratamiento,
• Corresponsables.

Las empresas mezclan estos roles constantemente. Y cuando se mezclan, se producen errores graves:

• contratos mal redactados,
• obligaciones mal asignadas,
• brechas mal gestionadas,
• y responsabilidades que nadie sabe quién debe asumir.

Este concepto es crítico porque define quién toma decisiones, quién ejecuta, quién responde y quién debe documentar qué. Sin esta claridad, el cumplimiento se vuelve frágil.

2. Responsable del tratamiento: quien decide la finalidad y los medios esenciales

El responsable es quien responde a estas dos preguntas:

1.    ¿Para qué se tratan los datos? (finalidad)

2.    ¿Qué medios esenciales se utilizan? (tipo de datos, categorías, destinatarios, plazos)

Si una organización decide esto, es responsable. Ejemplos claros:

• una empresa que gestiona datos de clientes,
• un hospital que trata datos de pacientes,
• una universidad que gestiona expedientes académicos.

Errores comunes:

• pensar que el proveedor “es el responsable porque tiene los datos”,
• creer que el responsable es quien “tiene la tecnología”,
• delegar decisiones esenciales en terceros sin documentarlo.

3. Encargado del tratamiento: quien presta un servicio siguiendo instrucciones

El encargado:

• no decide la finalidad,
• no decide los medios esenciales,
• no puede usar los datos para fines propios,
• y solo actúa siguiendo instrucciones documentadas del responsable.

Ejemplos típicos:

• servicios de hosting,
• proveedores de software en la nube,
• empresas de mantenimiento informático,
• call centers que gestionan atención al cliente.

Señal inequívoca: Si el proveedor no puede usar los datos para nada que no sea prestar el servicio, es encargado.

Errores comunes:

• firmar contratos de encargo con proveedores que realmente actúan como responsables,
• permitir que el encargado use datos para analítica propia,
• no revisar subencargados.

4. Corresponsables: cuando dos o más deciden conjuntamente

La corresponsabilidad aparece cuando dos entidades deciden juntas:

• la finalidad,
• o los medios esenciales.

No es necesario que decidan todo conjuntamente: basta con que compartan decisiones clave.

Ejemplos típicos:

• campañas de marketing conjuntas,
• proyectos de investigación compartidos,
• plataformas digitales con gobernanza compartida.

Obligación crítica: Debe existir un acuerdo de corresponsabilidad que:

• reparta obligaciones,
• explique quién informa al interesado,
• y determine quién gestiona derechos y brechas.

Errores comunes:

• creer que corresponsabilidad = responsabilidad solidaria,
• no documentar el reparto de funciones,
• usar contratos de encargo cuando hay decisiones compartidas.

5. Cómo distinguir correctamente cada figura (modelo práctico)

Paso 1 — Pregunta clave

¿Quién decide la finalidad del tratamiento? → Ese es el responsable.

Paso 2 — Segunda pregunta

¿Quién decide los medios esenciales? → Si es el mismo, sigue siendo responsable. → Si es otro, puede haber corresponsabilidad.

Paso 3 — Tercera pregunta

¿El proveedor solo ejecuta instrucciones sin decidir nada esencial? → Es encargado.

Paso 4 — Cuarta pregunta

¿Ambas partes deciden conjuntamente aspectos esenciales? → Son corresponsables.

6. Señales de que una empresa está clasificando mal los roles

• Contratos de encargo con proveedores que usan datos para fines propios.
• Proyectos conjuntos sin acuerdos de corresponsabilidad.
• Encargados que deciden medios esenciales sin autorización.
• Responsables que delegan decisiones sin documentarlas.
• Políticas internas que mezclan roles sin criterio.

7. Cierre: hacia la Entrada 3

Comprender quién es responsable, quién es encargado y quién es corresponsable es esencial para asignar obligaciones, gestionar riesgos y documentar correctamente el cumplimiento.

La Entrada 3 abordará otro concepto que genera confusión constante:

Qué es un dato especialmente protegido y por qué cambia todo en términos de garantías, riesgos y obligaciones.

 

Entrada 3 — Qué es un dato especialmente protegido y por qué cambia todo

1. Por qué este concepto necesita aclararse

En protección de datos, pocas categorías generan tanta confusión como los datos especialmente protegidos (o “categorías especiales” del artículo 9 del RGPD). Muchas organizaciones creen que:

• solo son “sensibles” los datos médicos,
• basta con tratarlos “con más cuidado”,
• o que solo importan cuando se recogen directamente del interesado.

Nada de esto es correcto.

Los datos especialmente protegidos no son una etiqueta emocional, sino una categoría jurídica que activa:

• prohibiciones de tratamiento,
• excepciones estrictas,
• garantías reforzadas,
• y obligaciones adicionales.

Comprender qué datos entran en esta categoría —y por qué— es esencial para evitar riesgos graves.

2. Qué son exactamente los datos especialmente protegidos

El RGPD define como categorías especiales los datos que revelan:

• origen étnico o racial,
• opiniones políticas,
• convicciones religiosas o filosóficas,
• afiliación sindical,
• datos genéticos,
• datos biométricos dirigidos a identificar de manera unívoca,
• datos relativos a la salud,
• datos relativos a la vida sexual o la orientación sexual.

Estos datos están prohibidos por defecto. Solo pueden tratarse si concurre una de las excepciones del artículo 9.2 (consentimiento explícito, interés público esencial, medicina, investigación, etc.).

3. El error más común: creer que solo importan los datos “directos”

Muchas empresas piensan que solo son datos especialmente protegidos cuando:

• se recogen explícitamente,
• se piden en un formulario,
• o se almacenan como tales.

Pero el RGPD es claro: también lo son los datos que permiten inferir estas categorías, aunque no se recojan directamente.

Ejemplos:

• un patrón de ausencias médicas puede revelar salud,
• un historial de donaciones puede revelar ideología,
• una geolocalización recurrente puede revelar afiliación religiosa,
• un análisis de voz puede generar datos biométricos.

Esto es crítico en IA, analítica avanzada y big data.

4. Qué implica que un dato sea especialmente protegido

Cuando un tratamiento incluye categorías especiales, la organización debe aplicar garantías reforzadas, entre ellas:

1) Base jurídica + excepción del artículo 9

No basta con una base jurídica del artículo 6. Debe existir una excepción válida del artículo 9.

2) Medidas de seguridad reforzadas

Incluye:

• cifrado,
• seudonimización,
• control de accesos estricto,
• trazabilidad completa,
• políticas de retención más estrictas.

3) DPIA obligatoria en la mayoría de casos

El tratamiento de datos especialmente protegidos suele activar la necesidad de una Evaluación de Impacto.

4) Limitación estricta de finalidades

No se pueden reutilizar para fines secundarios sin una nueva excepción válida.

5) Formación específica

Los equipos que acceden a estos datos deben recibir formación reforzada.

5. Señales de que una empresa está gestionando mal esta categoría

• Trata datos de salud sin excepción del artículo 9.
• Usa consentimiento “normal” en lugar de consentimiento explícito.
• No aplica medidas de seguridad reforzadas.
• No realiza DPIA cuando es obligatoria.
• No identifica datos inferidos como especialmente protegidos.
• Permite accesos amplios o no controlados.
• Reutiliza datos sensibles para finalidades no previstas.

6. Cómo identificar correctamente si un dato es especialmente protegido (modelo práctico)

Paso 1 — Pregunta directa

¿El dato pertenece a una de las categorías del artículo 9? → Si sí, es especialmente protegido.

Paso 2 — Pregunta indirecta

¿El dato permite inferir una de esas categorías? → Si sí, también es especialmente protegido.

Paso 3 — Pregunta contextual

¿El contexto convierte un dato neutro en sensible? Ejemplo:

• una dieta puede revelar religión,
• un horario puede revelar afiliación sindical.

→ Si sí, debe tratarse como dato especial.

7. Cierre: hacia la Entrada 4

Comprender qué es un dato especialmente protegido —y por qué activa obligaciones reforzadas— es esencial para gestionar el riesgo y evitar incumplimientos graves.

La Entrada 4 abordará otro concepto que se confunde constantemente:

Análisis de riesgos y DPIA: cuándo se hace cada uno, cómo se relacionan y por qué no son lo mismo.

 

Entrada 4 — Análisis de riesgos y DPIA: cuándo se hace cada uno, cómo se relacionan y por qué no son lo mismo

1. Por qué este concepto necesita aclararse

En protección de datos, pocas confusiones generan tantos errores como esta: creer que el análisis de riesgos y la DPIA son lo mismo.

Las consecuencias de esta confusión son graves:

• DPIAs que se hacen tarde o no se hacen,
• análisis de riesgos incompletos,
• medidas de seguridad mal justificadas,
• y decisiones que no resisten una auditoría.

La realidad es simple: el análisis de riesgos es continuo; la DPIA es un procedimiento formal. Ambos se relacionan, pero no se sustituyen.

2. Qué es el análisis de riesgos (y qué no es)

El análisis de riesgos es un proceso continuo que evalúa:

• la probabilidad de que ocurra un incidente,
• el impacto que tendría sobre los derechos y libertades,
• y las medidas necesarias para reducir ese riesgo.

Es un ejercicio dinámico, que debe actualizarse cuando:

• cambia la tecnología,
• cambia el tratamiento,
• cambia el contexto,
• o aparece un nuevo riesgo.

Errores comunes:

• tratarlo como un documento estático,
• limitarlo a riesgos técnicos,
• no incluir riesgos para los derechos de las personas,
• no revisarlo tras una brecha o un cambio de proveedor.

3. Qué es una DPIA (y por qué es un procedimiento formal)

La Evaluación de Impacto en Protección de Datos (DPIA) es un procedimiento obligatorio cuando un tratamiento puede generar un alto riesgo para los derechos y libertades.

Incluye:

• descripción detallada del tratamiento,
• evaluación de necesidad y proporcionalidad,
• análisis de riesgos específicos,
• medidas para mitigarlos,
• y, si persiste un riesgo alto, consulta previa a la autoridad.

La DPIA no es un análisis de riesgos ampliado: es un proceso jurídico-técnico con estructura, contenido y requisitos propios.

Errores comunes:

• hacer una DPIA cuando no corresponde,
• no hacerla cuando es obligatoria,
• confundirla con un checklist,
• no documentar la proporcionalidad.

4. Cuándo se hace cada uno: la regla práctica

El análisis de riesgos se hace siempre.

Para todos los tratamientos, sin excepción.

La DPIA se hace solo cuando hay alto riesgo.

Ejemplos típicos:

• datos especialmente protegidos a gran escala,
• vigilancia sistemática,
• perfiles con efectos jurídicos,
• uso de IA que afecta a derechos,
• tratamientos innovadores o intrusivos.

Regla de oro: El análisis de riesgos alimenta la DPIA, pero la DPIA no sustituye el análisis de riesgos.

5. Cómo se relacionan (modelo práctico)

Paso 1 — Análisis de riesgos inicial

Identifica riesgos y medidas básicas.

Paso 2 — Determinación del nivel de riesgo

Si el riesgo es alto → se activa la DPIA.

Paso 3 — DPIA

Analiza en profundidad:

• necesidad,
• proporcionalidad,
• impacto,
• medidas reforzadas.

Paso 4 — Revisión continua

El análisis de riesgos se actualiza; la DPIA se revisa cuando cambian las condiciones.

6. Señales de que una empresa está confundiendo ambos conceptos

• DPIAs hechas “por si acaso”, sin análisis previo.
• Tratamientos de alto riesgo sin DPIA.
• Análisis de riesgos que no mencionan derechos y libertades.
• DPIAs que no incluyen proporcionalidad.
• Documentación duplicada o contradictoria.
• Medidas de seguridad sin justificación.

7. Cierre: hacia la Entrada 5

Comprender la diferencia entre análisis de riesgos y DPIA es esencial para aplicar medidas proporcionadas, justificar decisiones y demostrar cumplimiento. No hacer análisis de riesgos de forma viva convierte la DPIA en un acto aislado y defensivo, no en una herramienta de gobierno.

La Entrada 5 abordará otro concepto que se confunde constantemente:

Minimización y limitación de la finalidad: dos principios que parecen similares, pero que exigen decisiones distintas en el diseño y uso de los datos.

 

Entrada 5 — Minimización y limitación de la finalidad: dos principios que las empresas siguen mezclando

1. Por qué este concepto necesita aclararse

En protección de datos, pocas parejas conceptuales generan tanta confusión como:

• minimización,
• limitación de la finalidad.

Muchas organizaciones creen que significan lo mismo (“usar pocos datos” o “usar datos solo para lo necesario”), pero en realidad son dos obligaciones distintas, con implicaciones diferentes:

• la minimización decide qué datos se recogen,
• la limitación de la finalidad decide para qué se usan.

Cuando se mezclan, se producen errores graves:

• recogida excesiva de datos,
• reutilización indebida,
• análisis secundarios no justificados,
• y tratamientos que no resisten una auditoría.

Esta entrada explica cómo distinguirlos y aplicarlos correctamente.

2. Qué es la minimización (y qué no es)

El principio de minimización exige que los datos sean:

• adecuados,
• pertinentes,
• limitados a lo necesario para la finalidad.

Esto significa que la empresa debe justificar cada dato que recoge. No basta con que “pueda ser útil”, ni con que “siempre se haya hecho así”.

Ejemplos de mala minimización:

• pedir fecha de nacimiento cuando basta con la edad,
• pedir dirección postal para un servicio digital,
• pedir DNI para un registro que no lo requiere,
• pedir datos de salud sin necesidad real.

Ejemplos de buena minimización:

• sustituir datos exactos por rangos,
• recoger solo los atributos imprescindibles,
• eliminar campos históricos que ya no aportan valor.

La minimización actúa en la fase de diseño: decide qué datos entran en el sistema.

3. Qué es la limitación de la finalidad (y qué no es)

El principio de limitación de la finalidad exige que los datos:

• se recojan para una finalidad concreta,
• no se usen para finalidades incompatibles,
• y solo se reutilicen cuando exista una base jurídica válida.

No basta con informar: la finalidad debe ser legítima, específica y compatible.

Ejemplos de mala limitación de la finalidad:

• usar datos de clientes para marketing sin base jurídica,
• reutilizar datos de empleados para analítica no relacionada,
• usar datos recogidos para seguridad en procesos comerciales,
• compartir datos con terceros para fines no previstos.

Ejemplos de buena limitación de la finalidad:

• separar finalidades en sistemas distintos,
• documentar finalidades secundarias,
• aplicar tests de compatibilidad,
• pedir consentimiento cuando la finalidad cambia.

La limitación de la finalidad actúa en la fase de uso: decide qué se puede hacer con los datos una vez recogidos.

4. Cómo distinguirlos en la práctica (modelo operativo)

Minimización = ¿Qué datos necesito?

→ Se decide antes de recogerlos.

Limitación de la finalidad = ¿Para qué los voy a usar?

→ Se decide antes de tratarlos y antes de reutilizarlos.

Regla práctica:

• Minimización controla la entrada de datos.
• Limitación de la finalidad controla la circulación y reutilización de datos.

5. Señales de que una empresa está mezclando ambos principios

• Formularios con datos innecesarios.
• Reutilización de datos sin análisis de compatibilidad.
• Políticas que mezclan finalidades sin criterio.
• Sistemas que no separan usos distintos.
• Tratamientos secundarios sin base jurídica.
• Datos históricos que se conservan “por si acaso”.

6. Cómo aplicar ambos principios correctamente (modelo práctico)

Paso 1 — Definir la finalidad con precisión

Sin finalidad clara, no hay minimización posible.

Paso 2 — Justificar cada dato

Preguntar: “¿Qué pasa si no recojo este dato?” Si no pasa nada, no debe recogerse.

Paso 3 — Documentar finalidades secundarias

Y aplicar test de compatibilidad.

Paso 4 — Separar datos por finalidad

Técnica y organizativamente.

Paso 5 — Revisar periódicamente

Finalidades, datos y usos cambian con el tiempo.

7. Cierre: hacia la Entrada 6

Comprender la diferencia entre minimización y limitación de la finalidad permite diseñar tratamientos más seguros, más eficientes y más defendibles ante auditorías.

La Entrada 6 abordará otro concepto que genera errores constantes:

Conservación, bloqueo y supresión: cómo gestionar correctamente el ciclo de vida del dato.

 

Entrada 6 — Conservación, bloqueo y supresión: cómo gestionar correctamente el ciclo de vida del dato

1. Por qué este concepto necesita aclararse

En protección de datos, pocas áreas generan tantos incumplimientos como la gestión del ciclo de vida del dato. Las organizaciones suelen confundir:

• conservar con “guardar indefinidamente”,
• bloquear con “archivar”,
• suprimir con “borrar sin más”,
• y los plazos legales con “lo que siempre hemos hecho”.

El resultado es un riesgo elevado:

• datos conservados más tiempo del necesario,
• sistemas llenos de información obsoleta,
• incumplimientos en auditorías,
• y brechas que afectan a datos que ya no deberían existir.

Esta entrada aclara qué significa cada concepto y cómo aplicarlo correctamente.

2. Qué es la conservación (y qué no es)

La conservación es el periodo durante el cual los datos se mantienen activos porque siguen siendo necesarios para la finalidad para la que fueron recogidos.

Esto implica:

• no se pueden conservar “por si acaso”,
• no se pueden ampliar los plazos sin justificación,
• no se pueden mezclar finalidades para alargar la vida del dato.

Ejemplos de conservación correcta:

• conservar datos de clientes mientras dura la relación contractual,
• conservar datos contables durante los plazos legales,
• conservar historiales médicos según normativa sanitaria.

Ejemplos de conservación incorrecta:

• mantener datos de candidatos no seleccionados durante años,
• conservar datos de clientes inactivos sin finalidad,
• guardar copias antiguas de bases de datos sin control.

3. Qué es el bloqueo (y por qué es tan mal entendido)

El bloqueo es una figura propia del ordenamiento español (art. 32 LOPDGDD). Consiste en mantener los datos inaccesibles, salvo para:

• atender responsabilidades legales,
• responder a reclamaciones,
• o cumplir obligaciones normativas.

Los datos bloqueados:

• no pueden usarse,
• no pueden tratarse,
• no pueden consultarse,
• no pueden incorporarse a nuevos procesos.

Solo se conservan para cumplir obligaciones legales.

Errores comunes:

• confundir bloqueo con archivo,
• mantener datos bloqueados sin plazo,
• no documentar el motivo del bloqueo,
• no restringir accesos adecuadamente.

4. Qué es la supresión (y qué implica realmente)

La supresión es la eliminación definitiva de los datos cuando:

• ya no son necesarios,
• ha expirado el plazo de conservación,
• o no existe base jurídica para seguir tratándolos.

La supresión debe ser:

• segura,
• documentada,
• irreversible,
• y aplicarse también a copias, backups y sistemas secundarios.

Errores comunes:

• borrar datos sin eliminar copias,
• no documentar la supresión,
• no aplicar supresión en entornos de pruebas,
• no revisar backups históricos.

5. Cómo se relacionan conservación, bloqueo y supresión (modelo operativo)

Fase 1 — Conservación activa

Los datos se usan para la finalidad original.

Fase 2 — Bloqueo

Cuando ya no son necesarios, pero existe obligación legal de mantenerlos.

Fase 3 — Supresión

Cuando expiran las obligaciones legales o los plazos de responsabilidad.

Regla de oro: Conservar → Bloquear → Suprimir Nunca al revés.

6. Señales de que una empresa está gestionando mal el ciclo de vida del dato

• No existen plazos de conservación definidos.
• Los sistemas acumulan datos históricos sin control.
• No se aplica bloqueo cuando termina la finalidad.
• No se documentan supresiones.
• Los backups contienen datos que deberían estar suprimidos.
• No hay un procedimiento formal para gestionar el ciclo de vida.

7. Cómo aplicar correctamente estos conceptos (modelo práctico)

Paso 1 — Definir plazos de conservación por finalidad

No por tipo de dato, sino por finalidad.

Paso 2 — Establecer criterios de bloqueo

Documentar cuándo, por qué y durante cuánto tiempo.

Paso 3 — Automatizar la supresión

Siempre que sea posible, con trazabilidad.

Paso 4 — Revisar backups y entornos secundarios

La supresión debe ser coherente en todos los sistemas.

Paso 5 — Documentar todo el proceso

Es esencial para auditorías y para demostrar diligencia.

8. Cierre: hacia la Entrada 7

Comprender la diferencia entre conservación, bloqueo y supresión permite gestionar el ciclo de vida del dato con rigor, evitar riesgos innecesarios y cumplir con las obligaciones legales.

La Entrada 7 abordará otro concepto que genera errores constantes:

Incidente vs. brecha de seguridad: cómo distinguirlos y qué hacer en cada caso.

 

Entrada 7 — Incidente vs. brecha de seguridad: cómo distinguirlos y qué hacer en cada caso

1. Por qué este concepto necesita aclararse

En protección de datos, pocas distinciones son tan importantes —y tan mal entendidas— como la diferencia entre:

• un incidente de seguridad,
• y una brecha de seguridad de datos personales.

Muchas organizaciones:

• notifican de más, por miedo,
• notifican de menos, por desconocimiento,
• o notifican tarde, por falta de criterios claros.

El resultado es doblemente peligroso:

• se generan obligaciones innecesarias,
• o se incumplen obligaciones críticas.

Esta entrada explica cómo distinguir ambos conceptos y cómo actuar con rigor.

2. Qué es un incidente de seguridad (y qué no es)

Un incidente de seguridad es cualquier evento que afecta a:

• la disponibilidad,
• la integridad,
• o la confidencialidad de un sistema,
• pero sin afectar necesariamente a datos personales.

Ejemplos típicos:

• caída de un servidor,
• fallo temporal de acceso,
• error interno sin exposición de datos,
• intento de ataque bloqueado,
• pérdida de un dispositivo vacío o cifrado.

Clave: Un incidente puede ser grave, pero no siempre implica datos personales. Por tanto, no siempre activa obligaciones del RGPD.

3. Qué es una brecha de seguridad de datos personales

Una brecha de seguridad es un incidente que sí afecta a datos personales, provocando:

• pérdida,
• alteración,
• acceso no autorizado,
• divulgación,
• o destrucción.

Ejemplos típicos:

• envío de datos a un destinatario incorrecto,
• acceso indebido por un empleado,
• ransomware que cifra datos personales,
• pérdida de un dispositivo sin cifrar,
• publicación accidental de información sensible.

Clave: Toda brecha es un incidente, pero no todo incidente es una brecha.

4. Cómo distinguirlos en la práctica (modelo operativo)

Paso 1 — Identificar el evento

¿Qué ha ocurrido exactamente?

Paso 2 — Determinar si hay datos personales afectados

Si no hay datos personales → incidente. Si sí los hay → posible brecha.

Paso 3 — Evaluar el impacto

¿Existe riesgo para los derechos y libertades?

• Si el riesgo es bajo → brecha no notificable, pero documentable.
• Si el riesgo es alto → brecha notificable a la AEPD.
• Si el riesgo es muy alto → brecha notificable también a los afectados.

Paso 4 — Documentar siempre

Incluso si no se notifica.

5. Señales de que una empresa está gestionando mal esta distinción

• Notifica incidentes que no afectan a datos personales.
• No notifica brechas que sí afectan a datos personales.
• No documenta incidentes ni brechas.
• No evalúa el riesgo para los derechos de las personas.
• No distingue entre impacto técnico e impacto jurídico.
• No tiene un procedimiento formal de gestión de brechas.

6. Qué hacer ante un incidente (modelo práctico)

1.    Identificar el evento.

2.    Contener el impacto técnico.

3.    Verificar si hay datos personales afectados.

4.    Documentar el incidente.

5.    Revisar medidas de seguridad.

Si no hay datos personales afectados, no hay brecha.

7. Qué hacer ante una brecha (modelo práctico)

1.    Activar el protocolo interno.

2.    Evaluar el riesgo para los derechos y libertades.

3.    Determinar si es notificable (AEPD y/o afectados).

4.    Documentar todo el proceso.

5.    Implementar medidas correctoras.

6.    Revisar políticas y controles.

Regla de oro: La notificación debe hacerse en 72 horas desde que se tiene conocimiento.

8. Cierre: hacia la Entrada 8

Comprender la diferencia entre incidente y brecha permite reaccionar con precisión, evitar notificaciones innecesarias y cumplir con las obligaciones del RGPD cuando realmente corresponde.

La Entrada 8 abordará otro concepto crítico en la práctica diaria:

Transferencias internacionales: qué significa realmente transferir datos fuera de la UE y cuándo se activa esta obligación.

 

Entrada 8 — Transferencias internacionales: qué significa realmente transferir datos fuera de la UE

1. Por qué este concepto necesita aclararse

Pocas áreas del RGPD generan tanta confusión como las transferencias internacionales de datos. Muchas organizaciones creen que solo hay transferencia cuando:

• se envían datos a un país tercero,
• se firma un contrato con un proveedor extranjero,
• o se realiza un envío explícito de información.

Pero la realidad es mucho más amplia. La AEPD y el Comité Europeo de Protección de Datos (CEPD) han sido claros: hay transferencia internacional incluso cuando no se “envían” datos, sino cuando un tercero situado fuera de la UE puede acceder a ellos.

Esta confusión provoca tres errores graves:

• no aplicar garantías cuando sí son necesarias,
• aplicar garantías cuando no corresponden,
• y no documentar adecuadamente la evaluación de riesgo.

Esta entrada explica qué es realmente una transferencia y cómo gestionarla.

2. Qué es una transferencia internacional (y qué no es)

Es transferencia internacional cuando:

• los datos se envían a un país fuera del EEE,
• un proveedor accede a los datos desde fuera del EEE,
• un soporte técnico remoto puede visualizar datos personales,
• un sistema alojado en la UE está controlado por una empresa matriz fuera de la UE,
• un proveedor extracomunitario puede requerir acceso por obligaciones legales de su país.

No es transferencia internacional cuando:

• el tratamiento se realiza íntegramente dentro del EEE,
• el proveedor está en la UE y no hay accesos desde fuera,
• los datos están cifrados y el proveedor extracomunitario no tiene la clave,
• se usan datos anonimizados (realmente anonimizados).

Regla clave: La transferencia no depende del movimiento físico del dato, sino del acceso potencial.

3. El error más común: confundir “acceso remoto” con “no transferencia”

Muchas empresas creen que, si los datos “no salen del servidor europeo” no hay transferencia. Esto es incorrecto.

Ejemplos típicos de transferencias inadvertidas:

• soporte técnico desde Estados Unidos que accede a un CRM europeo,
• proveedor de IA con sede fuera de la UE que procesa datos en la nube,
• empresa matriz en un país tercero que supervisa operaciones europeas,
• herramientas SaaS con equipos de desarrollo extracomunitarios.

En todos estos casos, hay transferencia, aunque los datos “no se muevan”.

4. Qué exige el RGPD cuando hay transferencia internacional

Cuando existe transferencia, la organización debe aplicar garantías adecuadas, entre ellas:

1) Decisión de adecuación

Si el país está reconocido como adecuado por la Comisión Europea, la transferencia es válida.

2) Cláusulas Contractuales Tipo (SCC)

Son el mecanismo más habitual. Pero no bastan por sí solas: requieren una evaluación del país de destino (TIA).

3) Normas Corporativas Vinculantes (BCR)

Para grupos empresariales multinacionales.

4) Medidas complementarias

Cuando las SCC no son suficientes:

• cifrado robusto,
• seudonimización,
• minimización,
• controles de acceso estrictos.

5) Evaluación del riesgo país (TIA)

Debe analizar:

• legislación local,
• acceso de autoridades,
• garantías del proveedor,
• medidas técnicas aplicadas.

5. Señales de que una empresa está gestionando mal las transferencias

• Cree que no hay transferencia porque “los datos están en Europa”.
• Usa SCC sin evaluación del país de destino.
• No documenta accesos remotos.
• No revisa subencargados extracomunitarios.
• No aplica medidas complementarias cuando son necesarias.
• No revisa periódicamente la situación jurídica del país tercero.

6. Cómo gestionar correctamente las transferencias (modelo práctico)

Paso 1 — Identificar accesos extracomunitarios

No solo envíos: también soporte, mantenimiento, monitorización.

Paso 2 — Determinar si hay transferencia

Si existe acceso potencial desde fuera del EEE → sí hay transferencia.

Paso 3 — Elegir la garantía adecuada

Adecuación, SCC, BCR o medidas complementarias.

Paso 4 — Realizar la TIA

Evaluar el riesgo jurídico del país tercero.

Paso 5 — Documentar todo

Es esencial para auditorías y para demostrar diligencia.

7. Cierre: hacia la Entrada 9

Comprender qué es realmente una transferencia internacional permite evitar incumplimientos graves, aplicar garantías adecuadas y documentar decisiones con rigor.

La Entrada 9 abordará otro concepto que se menciona mucho pero se aplica poco:

Privacy by design & privacy by default: cómo integrarlos en el diseño real de productos, procesos y sistemas.

 

Entrada 9 — Privacy by design & privacy by default: cómo integrarlos en el diseño real de productos, procesos y sistemas

1. Por qué este concepto necesita aclararse

En protección de datos, pocas expresiones se repiten tanto y se aplican tan poco como:

• privacy by design,
• privacy by default.

Muchas organizaciones los incluyen en políticas, auditorías y presentaciones, pero:

• no saben cómo aplicarlos en el diseño de un producto,
• no los integran en procesos internos,
• no los traducen en decisiones técnicas,
• y no los documentan como exige el RGPD.

El resultado es que estos principios se convierten en eslóganes vacíos. Esta entrada explica qué significan realmente y cómo aplicarlos de forma práctica.

2. Qué es privacy by design (y qué no es)

Privacy by design significa que la protección de datos debe integrarse desde el diseño del producto, proceso o sistema, no después.

Implica:

• definir finalidades claras antes de recoger datos,
• elegir la base jurídica adecuada desde el inicio,
• aplicar minimización en la arquitectura,
• incorporar medidas técnicas desde la fase de diseño,
• prever riesgos antes de que aparezcan,
• y documentar decisiones desde el primer boceto.

Errores comunes:

• añadir medidas de seguridad al final del proyecto,
• diseñar sistemas que recogen más datos de los necesarios,
• no involucrar al DPO en la fase de diseño,
• no realizar análisis de riesgos antes de desarrollar.

Privacy by design = decisiones estructurales.

3. Qué es privacy by default (y qué no es)

Privacy by default significa que, por defecto, el sistema debe:

• recoger solo los datos necesarios,
• usar solo las configuraciones más protectoras,
• limitar accesos al mínimo,
• no activar funcionalidades intrusivas sin acción del usuario,
• y no permitir usos secundarios sin base jurídica.

Ejemplos de privacy by default:

• configuraciones iniciales que desactivan geolocalización,
• perfiles privados por defecto,
• formularios con campos mínimos,
• retención limitada por defecto,
• accesos restringidos desde el primer día.

Errores comunes:

• sistemas que activan todo por defecto,
• configuraciones que maximizan la recopilación de datos,
• accesos amplios para todos los empleados,
• retenciones indefinidas sin justificación.

Privacy by default = decisiones de configuración.

4. Cómo se relacionan ambos principios (modelo operativo)

Privacy by design actúa en la fase de diseño

→ arquitectura, finalidades, flujos de datos, medidas técnicas.

Privacy by default actúa en la fase de configuración y uso

→ parámetros, accesos, retención, opciones del usuario.

Regla práctica:

• Design define el marco.
• Default define el comportamiento inicial.

5. Cómo aplicar estos principios en la práctica (modelo realista)

Paso 1 — Involucrar al DPO desde el inicio

No al final. No para “validar”. Para diseñar.

Paso 2 — Mapear los datos antes de construir

Qué datos entran, por qué, para qué y durante cuánto tiempo.

Paso 3 — Aplicar minimización estructural

Eliminar campos innecesarios antes de que existan.

Paso 4 — Diseñar medidas técnicas desde el principio

Cifrado, seudonimización, segmentación, control de accesos.

Paso 5 — Configurar el sistema con opciones protectoras

No dejar la privacidad en manos del usuario.

Paso 6 — Documentar decisiones

Cada decisión debe tener una justificación y un registro.

Paso 7 — Revisar periódicamente

Los sistemas cambian, los riesgos también.

6. Señales de que una empresa no aplica estos principios

• El DPO revisa proyectos cuando ya están terminados.
• Los sistemas recogen más datos de los necesarios.
• Las configuraciones por defecto son intrusivas.
• No existen revisiones periódicas.
• No hay documentación de decisiones de diseño.
• Los accesos son amplios y no están segmentados.
• Las retenciones son indefinidas.

7. Cierre: hacia la Entrada 10

Comprender y aplicar privacy by design y privacy by default permite construir sistemas más seguros, más eficientes y más respetuosos con los derechos de las personas. Son principios que, bien aplicados, reducen riesgos, simplifican auditorías y fortalecen la confianza.

La Entrada 10 abordará un concepto crítico en la era de la IA:

Datos inferidos: qué son, por qué también son datos personales y qué obligaciones generan.

 

Entrada 10 — Datos inferidos: el gran olvidado del RGPD

1. Por qué este concepto necesita aclararse

En la era de la analítica avanzada y la inteligencia artificial, los datos más sensibles y más valiosos no son los que se recogen, sino los que se generan a partir de ellos.

Sin embargo, muchas organizaciones siguen creyendo que:

• solo son datos personales los que el usuario proporciona,
• los datos inferidos “no cuentan” porque no se recogen directamente,
• los modelos de IA generan información “anónima”,
• y que las obligaciones del RGPD no aplican a inferencias.

Todo esto es incorrecto. El RGPD es claro: los datos inferidos también son datos personales, y pueden ser incluso más sensibles que los originales.

Esta entrada explica qué son, por qué importan y cómo deben gestionarse.

2. Qué son los datos inferidos (y qué no son)

Los datos inferidos son datos personales que no se recogen directamente, sino que se derivan, calculan o predicen a partir de otros datos.

Ejemplos típicos:

• un perfil de riesgo crediticio,
• una predicción de comportamiento,
• una clasificación de salud basada en patrones,
• una estimación de ingresos,
• una probabilidad de abandono,
• una segmentación comercial,
• una predicción de ideología o religión basada en hábitos.

No son datos proporcionados por el usuario, pero sí son datos personales, porque se refieren a una persona identificada o identificable.

3. Por qué los datos inferidos son especialmente delicados

Los datos inferidos presentan tres riesgos críticos:

1) Pueden ser más sensibles que los datos originales

Ejemplo: A partir de hábitos de compra se puede inferir salud, religión o ideología.

2) Pueden ser incorrectos

Las inferencias pueden ser:

• erróneas,
• sesgadas,
• incompletas,
• o basadas en correlaciones débiles.

Y aun así, pueden afectar a decisiones reales.

3) Pueden generar efectos jurídicos o significativos

Especialmente en:

• scoring,
• selección de personal,
• seguros,
• crédito,
• publicidad segmentada,
• decisiones automatizadas.

4. Qué obligaciones genera el tratamiento de datos inferidos

El tratamiento de datos inferidos no está exento del RGPD. Implica obligaciones claras:

1) Base jurídica

Debe existir una base jurídica válida para:

• generar la inferencia,
• y utilizarla.

No basta con tener base jurídica para los datos originales.

2) Transparencia

La empresa debe informar:

• que genera inferencias,
• para qué las usa,
• y cómo afectan al interesado.

3) Minimización

No se pueden generar inferencias que no sean necesarias para la finalidad.

4) Limitación de la finalidad

No se pueden reutilizar inferencias para fines incompatibles.

5) Derechos del interesado

Incluye:

• acceso a las inferencias,
• rectificación (cuando sea posible),
• oposición,
• y, en ciertos casos, no ser objeto de decisiones automatizadas.

6) DPIA

Obligatoria cuando las inferencias generan alto riesgo.

5. Señales de que una empresa está gestionando mal los datos inferidos

• Genera perfiles sin base jurídica clara.
• No informa de las inferencias en la política de privacidad.
• Usa inferencias para finalidades no previstas.
• No permite acceso a los datos inferidos.
• No evalúa sesgos ni errores.
• No realiza DPIA en tratamientos de alto riesgo.
• Considera que las inferencias “no son datos personales”.

6. Cómo gestionar correctamente los datos inferidos (modelo práctico)

Paso 1 — Identificar las inferencias

Mapear qué datos se generan, no solo los que se recogen.

Paso 2 — Justificar la base jurídica

Una para generar, otra para usar.

Paso 3 — Informar con claridad

Explicar qué se infiere, cómo y para qué.

Paso 4 — Evaluar riesgos y sesgos

Especialmente en IA y modelos predictivos.

Paso 5 — Aplicar minimización

No generar inferencias innecesarias.

Paso 6 — Revisar periódicamente

Los modelos cambian, las inferencias también.

7. Cierre del ciclo: lo que hemos aprendido

Con esta entrada cerramos el ciclo Protección de Datos: Aclarando conceptos, en el que hemos abordado:

1.    Bases jurídicas.

2.    Roles (responsable, encargado, corresponsable).

3.    Datos especialmente protegidos.

4.    Análisis de riesgos vs. DPIA.

5.    Minimización y limitación de la finalidad.

6.    Conservación, bloqueo y supresión.

7.    Incidente vs. brecha.

8.    Transferencias internacionales.

9.    Privacy by design & by default.

10.                   Datos inferidos.

Un mapa completo para navegar los conceptos más complejos —y más mal entendidos— del RGPD.