Por qué la minimización y la protección de datos desde el diseño empiezan antes de recibir el dato

En protección de datos solemos mirar demasiado tarde.

Miramos cuando el dato ya está dentro. Cuando ya se ha recogido. Cuando ya aparece en una base de datos. Cuando ya se ha incorporado a un expediente. Cuando ya circula por un sistema. Cuando ya hay que conservarlo, limitarlo, borrarlo, comunicarlo o protegerlo.

Pero hay una pregunta anterior, mucho más incómoda y mucho más importante:

¿Por qué lo pedimos?

La reciente doctrina del Tribunal Supremo sobre el alcance del concepto de “tratamiento” en el RGPD obliga precisamente a volver a esa pregunta inicial. Según la publicación profesional de Garrigues, fuente especialmente cualificada por su intervención en la dirección letrada del recurso de casación de la AEPD, el Tribunal Supremo ha declarado que la mera solicitud de datos personales puede constituir tratamiento a efectos del artículo 4.2 del RGPD, aunque los datos no lleguen finalmente a ser facilitados por la persona interesada. (Garrigues)

La idea parece sencilla. Pero sus consecuencias son profundas.

Si pedir un dato ya puede activar el RGPD, entonces el cumplimiento no empieza cuando el dato entra en la organización. Empieza antes: cuando alguien decide pedirlo.

Y eso cambia muchas cosas.

Cambia cómo diseñamos formularios. Cambia cómo configuramos sistemas. Cambia cómo entrenamos a Recursos Humanos. Cambia cómo opera marketing. Cambia cómo trabaja atención al usuario. Cambia cómo se diseñan procesos de alta y acogida. Cambia cómo se auditan programas de privacidad. Cambia cómo se entiende la minimización. Cambia, en definitiva, el punto de arranque del cumplimiento.

La tesis puede formularse así:

La STS 1590/2026, de 26 de marzo de 2026, consolida una precisión interpretativa de gran relevancia para la aplicación del RGPD: el tratamiento no comienza necesariamente cuando el dato entra materialmente en poder del responsable, sino que puede comenzar antes, cuando la organización solicita a una persona física la entrega de datos personales como parte de una actuación dirigida a obtenerlos.

La AEPD, en su comentario institucional sobre la sentencia, destaca que el concepto de tratamiento no se limita a las actuaciones posteriores a la obtención material de los datos, sino que también comprende actuaciones previas dirigidas a su obtención, como la solicitud.

La frase podría resumirse así:

La minimización no empieza en la base de datos. Empieza en la pregunta.

1. El caso: una solicitud aparentemente administrativa

El caso parte de una situación que, en muchas organizaciones, podría parecer rutinaria.

Una persona trabajadora justifica una ausencia por motivos de salud. Aporta documentación médica genérica. La organización solicita después información más concreta: diagnóstico médico y tratamiento prescrito. La persona afectada se niega a facilitar esos datos, al entender que pertenecen a su intimidad y que no resultan necesarios para justificar la ausencia.

La STS 1590/2026, de 26 de marzo de 2026, consolida una precisión interpretativa de gran relevancia para la aplicación del RGPD: el tratamiento no comienza necesariamente cuando el dato entra materialmente en poder del responsable, sino que puede comenzar antes, cuando la organización solicita a una persona física la entrega de datos personales como parte de una actuación dirigida a obtenerlos.

Visto superficialmente, podría parecer un caso laboral.

Pero no lo es solo.

Es un caso sobre la frontera entre pedir y tratar. Es un caso sobre el momento exacto en que nace el cumplimiento. Es un caso sobre el diseño de las preguntas. Es un caso sobre la cultura interna de las organizaciones. Es un caso sobre cómo un exceso aparentemente pequeño puede revelar una debilidad estructural.

Porque el problema no está únicamente en que se pidiera un dato de salud.

El problema está en que alguien dentro de la organización consideró normal pedirlo.

Y esa es la pregunta que deberíamos hacernos:

¿Cuántas veces una organización pide datos porque “siempre se ha hecho así”, sin detenerse a justificar si realmente los necesita?

2. La tesis formalista: “si el dato no llegó a recibirse, no hubo tratamiento”

La controversia previa giraba en torno a una tesis formalista o restrictiva: si el dato no había llegado a recibirse, incorporarse al expediente o quedar bajo disponibilidad efectiva del responsable, no podía hablarse propiamente de tratamiento.

Esa fue, en esencia, la lectura que acogió la Audiencia Nacional al anular la sanción. La lógica parecía sencilla.

No se recibió el dato. No se incorporó al expediente. No se registró. No se conservó. No se comunicó. No se utilizó.

Por tanto, no habría tratamiento.

Pero esa forma de razonar mira demasiado tarde. Sitúa el foco en la entrada material del dato, no en la decisión previa de solicitarlo.

Y ahí está el punto crítico.

Una solicitud de datos no es un acto vacío. No es una simple frase. No es una operación jurídicamente neutra.

Cuando una organización pide un dato, ya ha hecho varias cosas.

Ha decidido que ese dato le interesa. Ha vinculado ese dato a una finalidad. Ha elegido un canal para solicitarlo. Ha creado una expectativa de entrega. Ha trasladado una presión a la persona afectada. Ha generado un riesgo de exceso. Ha activado una relación de poder.

En especial, cuando la solicitud se produce en contextos asimétricos —laboral, sanitario, educativo, financiero, administrativo o de prestación esencial de servicios— la persona afectada puede sentirse obligada a entregar más información de la necesaria.

Por eso, el razonamiento formalista resulta insuficiente.

La pregunta no puede ser solo:

¿Entró finalmente el dato?

La pregunta debe ser también:

¿Era legítimo pedirlo?

3. La doctrina del Tribunal Supremo: el tratamiento empieza antes

La STS 1590/2026 rechaza que el concepto de tratamiento dependa exclusivamente de la recogida material del dato. El Tribunal Supremo parte de la definición amplia del artículo 4.2 RGPD, pero no la interpreta de forma aislada: la conecta con los principios del artículo 5 y con la protección de datos desde el diseño y por defecto del artículo 25.

El Reglamento define el tratamiento como cualquier operación o conjunto de operaciones sobre datos personales, e incluye operaciones como la recogida, el registro, la organización, la estructuración, la conservación, la consulta, la utilización, la comunicación o la supresión.

Este criterio tiene una enorme importancia porque desplaza el eje del cumplimiento.

Ya no basta con controlar qué ocurre cuando el dato entra en el sistema. Hay que controlar la fase anterior: la decisión de pedirlo.

Esto conecta directamente con una interpretación amplia y funcional del artículo 4.2 RGPD. El Reglamento define el tratamiento como cualquier operación o conjunto de operaciones sobre datos personales, e incluye expresamente operaciones como recogida, registro, organización, estructuración, conservación, consulta, utilización, comunicación o supresión. El mismo Reglamento regula los principios del tratamiento en el artículo 5 y la protección de datos desde el diseño y por defecto en el artículo 25. (boe.es)

La clave está en no leer esa lista como una fotografía cerrada de operaciones técnicas, sino como parte de un ciclo de vida.

En ese ciclo, la solicitud es el umbral de entrada.

Antes de que el dato se almacene, alguien lo pidió. Antes de que se consulte, alguien lo exigió. Antes de que se conserve, alguien diseñó un campo. Antes de que se comunique, alguien lo incorporó a un proceso. Antes de que haya una brecha, alguien permitió que ese dato existiera dentro del sistema.

Por eso la doctrina es tan relevante.

No está diciendo simplemente que pedir datos es importante. Está diciendo algo más exigente:

La solicitud de datos personales forma parte del fenómeno regulado por el RGPD y debe someterse a sus principios desde el primer momento.

4. La minimización empieza en la pregunta

El principio de minimización exige que los datos sean adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados. Esta exigencia está recogida en el artículo 5.1.c) del RGPD. (boe.es)

Pero el caso obliga a hacer una lectura más profunda.

La minimización no puede entenderse solo como una operación de limpieza posterior.

No es únicamente borrar campos antiguos. No es únicamente limitar columnas en una base de datos. No es únicamente eliminar adjuntos innecesarios. No es únicamente revisar expedientes ya creados.

La minimización empieza antes.

Empieza cuando alguien redacta un formulario. Empieza cuando alguien decide qué campos serán obligatorios. Empieza cuando Recursos Humanos diseña una plantilla de justificación. Empieza cuando marketing crea un formulario de descarga. Empieza cuando atención al cliente pide documentación. Empieza cuando cumplimiento solicita evidencias. Empieza cuando tecnología configura un campo libre. Empieza cuando una organización pregunta.

La pregunta central cambia.

Antes preguntábamos:

¿Qué hacemos con este dato una vez recibido?

Ahora debemos preguntar antes:

¿Por qué vamos a pedir este dato?

Y todavía más:

¿Podemos cumplir la finalidad sin pedirlo?

Esa es la pregunta que revela la madurez del programa.

5. El dato de salud que no debía pedirse

El ejemplo del diagnóstico médico es especialmente pedagógico.

Una organización puede necesitar verificar una ausencia laboral. Puede necesitar acreditar que existe una justificación. Puede necesitar gestionar permisos, bajas, incapacidades, ausencias o controles internos.

Pero eso no significa que necesite conocer el diagnóstico médico concreto.

Hay una diferencia enorme entre saber que una ausencia está justificada y conocer la patología de la persona.

Una cosa es verificar la existencia de una circunstancia habilitante. Otra cosa es acceder al detalle clínico.

Una cosa es gestionar una relación laboral. Otra cosa es penetrar en la esfera sanitaria de la persona.

Una cosa es pedir un justificante. Otra cosa es pedir el diagnóstico.

Ahí opera la minimización.

La organización debe preguntarse:

¿Qué necesito realmente para cumplir mi finalidad?

Si la finalidad es justificar una ausencia, puede bastar un documento que acredite la asistencia médica o la situación correspondiente, sin revelar diagnóstico, tratamiento o detalle clínico.

Por eso, el caso enseña algo fundamental:

La finalidad no legitima cualquier dato relacionado con ella. Solo legitima el dato necesario para alcanzarla.

6. La licitud también debe existir antes de pedir

La minimización no es el único principio afectado.

Si pedir un dato ya activa el RGPD, entonces antes de pedirlo la organización debe haber resuelto también la cuestión de la licitud.

No basta con decir:

“Ya veremos cómo justificamos el dato si nos lo entregan”.

La base jurídica no puede improvisarse después. La finalidad no puede definirse después. La necesidad no puede argumentarse después. La proporcionalidad no puede reconstruirse después. La información a la persona interesada no puede maquillarse después.

La solicitud debe nacer jurídicamente ordenada.

Antes de pedir un dato, la organización debería poder responder:

¿Qué dato concreto se solicita? ¿A quién se solicita? ¿Para qué finalidad específica? ¿Con qué base jurídica? ¿Es obligatorio u opcional? ¿Qué ocurre si no se facilita? ¿Existe una alternativa menos intrusiva? ¿Se trata de una categoría especial de datos? ¿Es proporcionado pedirlo en este contexto? ¿Se ha informado adecuadamente? ¿Qué evidencia queda de esta decisión?

No son preguntas burocráticas.

Son preguntas de protección efectiva.

Porque cuando una organización pide un dato sin haber pensado esto, no está simplemente cometiendo una imprecisión documental. Está trasladando a la persona afectada el coste de su falta de diseño.

7. La protección de datos desde el diseño deja de ser retórica

El artículo 25 del RGPD exige aplicar medidas técnicas y organizativas apropiadas tanto en el momento de determinar los medios del tratamiento como durante el propio tratamiento. La guía de la AEPD sobre protección de datos por defecto recuerda que los principios, derechos y obligaciones del RGPD deben tenerse en cuenta desde el diseño y por defecto. (aepd.es)

Las Directrices 4/2019 del Comité Europeo de Protección de Datos explican también que la protección de datos desde el diseño y por defecto es una obligación de los responsables, con independencia de su tamaño, y que debe aplicarse en el diseño de las operaciones de tratamiento. (edpb.europa.eu)

El caso aterriza esta obligación de forma muy concreta.

Protección de datos desde el diseño no significa únicamente incorporar seguridad técnica al sistema. No significa solo cifrado, control de accesos o registros de actividad. No significa solo incluir una cláusula informativa al final del formulario.

Significa preguntarse, antes de diseñar el formulario:

¿De verdad necesito este dato?

Significa preguntarse, antes de configurar un campo obligatorio:

¿La finalidad se puede cumplir sin exigirlo?

Significa preguntarse, antes de pedir documentación:

¿Puedo verificar lo necesario sin acceder a información excesiva?

Significa preguntarse, antes de lanzar un proceso:

¿Estoy diseñando una experiencia respetuosa con los principios del RGPD?

La privacidad desde el diseño no es una decoración jurídica. Es una disciplina de concepción.

No llega al final para corregir. Debe estar al principio para evitar que el error nazca.

8. El efecto dominó en los principios del RGPD

Una sentencia de este tipo no afecta a un solo principio. Genera un efecto dominó.

Minimización

El dato no debe pedirse si no es necesario.

La minimización deja de ser una revisión posterior y se convierte en una regla previa de diseño.

Licitud

La organización debe tener una base jurídica antes de solicitar el dato.

No se pide primero y se busca justificación después.

Finalidad

La finalidad debe estar definida antes de la solicitud.

Una finalidad vaga produce solicitudes expansivas.

Transparencia

La persona debe entender por qué se le pide el dato y qué ocurrirá si lo facilita o si no lo facilita.

La transparencia no empieza cuando el dato se almacena. Empieza cuando se formula la solicitud.

Limitación de conservación

Aunque el dato no llegue a recibirse, el proceso debe tener previsto qué ocurriría si se recibe.

No se puede diseñar una solicitud sin saber cuánto tiempo se conservaría la información solicitada.

Integridad y confidencialidad

El canal por el que se solicita el dato también importa.

Pedir un dato sensible por un canal inseguro ya revela un fallo de diseño.

Responsabilidad proactiva

La organización debe poder demostrar que pensó antes de pedir.

La evidencia no debe nacer solo cuando hay una inspección. Debe nacer cuando se diseña el proceso.

9. El programa de protección de datos debe mirar los puntos de entrada

Muchos programas de privacidad están construidos alrededor de lo que ya existe.

Registros de actividades. Contratos con encargados. Políticas de privacidad. Procedimientos de derechos. Gestión de brechas. Evaluaciones de impacto. Auditorías periódicas.

Todo eso es necesario.

Pero este caso obliga a añadir una pregunta:

¿Quién controla los puntos de entrada del dato?

Porque los datos entran por algún sitio.

Entran por formularios. Entran por correos. Entran por adjuntos. Entran por plataformas. Entran por CRM. Entran por ERP. Entran por sistemas de recursos humanos. Entran por guiones de atención telefónica. Entran por procesos de alta. Entran por solicitudes documentales. Entran por campos libres. Entran por hábitos.

Un programa maduro no puede limitarse a gestionar los datos una vez que han entrado. Debe gobernar las puertas de entrada.

Y para gobernarlas necesita reglas.

Ningún formulario nuevo debería publicarse sin revisar sus campos. Ningún campo sensible debería habilitarse sin justificación reforzada. Ninguna solicitud documental estándar debería aprobarse sin criterio de minimización. Ningún campo obligatorio debería existir sin finalidad y necesidad. Ningún texto libre debería utilizarse para recoger información que podría estructurarse y limitarse. Ningún proceso de Recursos Humanos debería pedir más información médica que la estrictamente necesaria.

10. El sistema de información también debe minimizar

Aquí el caso se vuelve especialmente relevante para tecnología.

A veces se piensa que el problema de minimización es jurídico.

No lo es solo.

También es un problema de arquitectura.

Un sistema que permite pedir cualquier dato, en cualquier campo, sin control, sin clasificación, sin justificación y sin trazabilidad, está diseñado para el exceso.

Puede que tenga buen cifrado. Puede que tenga doble factor. Puede que tenga control de accesos. Puede que tenga registros de actividad.

Pero si permite pedir datos innecesarios, el fallo está antes.

Está en el diseño funcional.

Por eso, la protección de datos desde el diseño debe traducirse en controles técnicos y organizativos concretos:

Catálogo de campos autorizados. Clasificación de datos por nivel de sensibilidad. Justificación de finalidad por campo. Campos obligatorios solo cuando sean necesarios. Campos opcionales claramente diferenciados. Bloqueo o revisión reforzada de categorías especiales. Control de campos de texto libre. Trazabilidad de cambios en formularios. Registro de versiones. Alertas cuando se añaden nuevos campos. Revisión periódica de formularios activos. Plantillas preaprobadas de solicitud documental.

La pregunta tecnológica de fondo es esta:

¿El sistema ayuda a pedir menos o facilita pedir de más?

Esa pregunta debería formar parte de cualquier revisión seria de privacidad desde el diseño.

11. No basta con informar; hay que diseñar bien

Muchas organizaciones creen que el cumplimiento se resuelve informando.

Añaden una cláusula. Incluyen un enlace a la política de privacidad. Ponen un aviso bajo el formulario. Redactan una finalidad amplia. Incluyen una casilla.

Pero informar de una solicitud excesiva no la convierte en lícita.

La transparencia no cura la desproporción. La información no legitima lo innecesario. El consentimiento, cuando exista, no convierte en necesario lo que no lo es. La cláusula informativa no sustituye la minimización.

Esta es una de las lecciones más importantes del caso:

No basta con explicar bien por qué se pide un dato si el dato no debía pedirse.

La transparencia es necesaria, pero no suficiente.

Un formulario puede ser transparente y excesivo. Una solicitud puede estar bien redactada y ser desproporcionada. Una política puede informar correctamente y, aun así, sostener un tratamiento innecesario.

Por eso, el análisis debe empezar antes de la información.

Debe empezar con la necesidad.

12. Recursos Humanos necesita entrenamiento específico

El caso tiene una conexión evidente con el ámbito laboral.

Recursos Humanos suele manejar información delicada: ausencias, bajas, adaptación de puestos, prevención de riesgos, expedientes disciplinarios, selección, evaluaciones, conflictos internos, conciliación, diversidad, discapacidad, salud laboral y documentación contractual.

En ese contexto, el riesgo de pedir de más es muy alto.

No siempre por mala fe. Muchas veces por inercia.

“Pide el informe completo.”
“Que nos mande el diagnóstico.”
“Solicita toda la documentación médica.”
“Que justifique exactamente qué tiene.”
“Mejor pedirlo todo por si acaso.”

Ese “por si acaso” es enemigo de la minimización.

Recursos Humanos necesita criterios claros.

Qué puede pedir. Qué no debe pedir. Qué debe tacharse o anonimizarse. Qué puede verificarse sin conocer el detalle. Qué información médica corresponde al servicio médico o a terceros habilitados. Qué datos no deben quedar en expedientes laborales ordinarios. Qué canales son adecuados. Qué hacer si la persona entrega más información de la necesaria.

La formación no debe limitarse a decir “los datos de salud son sensibles”.

Debe enseñar a decidir.

Debe entrenar escenarios.

Debe trabajar casos.

Debe incorporar frases prácticas:

“No necesitamos el diagnóstico, solo la acreditación de la situación.”
“No remita información clínica adicional.”
“Puede aportar justificante sin detalle médico.”
“Si el documento contiene diagnóstico, consulte antes de incorporarlo al expediente.”
“Cuando exista duda, escale la consulta antes de solicitar información adicional.”

La protección de datos también se entrena en el lenguaje cotidiano.

13. Marketing también debe revisar sus preguntas

Aunque el caso nace en un contexto laboral, su impacto se extiende a marketing.

Los formularios comerciales son una fuente habitual de exceso.

Para descargar un documento, se pide cargo, teléfono, empresa, sector, tamaño, país, necesidades, presupuesto y consentimiento para comunicaciones. Para inscribirse a un seminario web, se piden datos que no son necesarios para gestionar la asistencia. Para recibir una newsletter, se exige información que solo sirve para segmentar comercialmente. Para participar en una campaña, se convierten en obligatorios campos accesorios.

La pregunta crítica es:

¿Este dato es necesario para la finalidad declarada o simplemente útil para el negocio?

Lo útil no siempre es necesario.

Y el RGPD no exige que el dato sea interesante, cómodo o rentable. Exige que sea adecuado, pertinente y limitado a lo necesario para la finalidad.

Eso no significa que marketing no pueda tratar datos.

Significa que debe diseñar mejor.

Puede distinguir campos necesarios y opcionales. Puede modular finalidades. Puede recoger datos progresivamente. Puede evitar formularios invasivos. Puede explicar mejor. Puede permitir preferencias. Puede usar datos agregados o menos intrusivos. Puede aplicar privacidad por defecto.

La lección es clara:

La conversión no justifica pedirlo todo.

14. Atención al usuario debe aprender proporcionalidad

Atención al cliente y soporte también están en el centro del problema.

Para verificar identidad, resolver incidencias o tramitar solicitudes, muchas organizaciones piden documentos, capturas, justificantes, fotografías, números identificativos o información adicional.

A veces es necesario.

Pero no siempre en la misma intensidad.

No toda consulta requiere el mismo nivel de verificación. No toda incidencia exige copia de documento de identidad. No toda solicitud necesita adjuntar documentos completos. No toda gestión justifica pedir información sensible.

La proporcionalidad exige ajustar la solicitud al riesgo.

Una consulta general no debería requerir identificación reforzada. Una modificación contractual sí puede exigir más garantías. Una solicitud de acceso puede requerir verificación, pero no siempre copia íntegra de documento. Una reclamación sencilla no debe convertirse en una recogida masiva de datos.

La pregunta para atención al usuario es:

¿Estoy pidiendo el mínimo dato necesario para resolver esta gestión con seguridad suficiente?

Esa pregunta une protección de datos, experiencia de usuario y eficiencia operativa.

Pedir menos, cuando se diseña bien, no debilita el proceso. Lo mejora.

15. El DPD debe llegar antes

Este caso también ayuda a ubicar correctamente el papel del Delegado de Protección de Datos.

El DPD no sustituye al responsable. No aprueba ni reprueba tratamientos como si fuera el órgano decisor. No asume la decisión gerencial.

Su función es informar, asesorar y supervisar.

Pero para que esa función sea útil, debe poder intervenir a tiempo.

Si el DPD solo revisa procesos cuando el formulario ya está publicado, llega tarde. Si solo interviene cuando la campaña ya está lanzada, llega tarde. Si solo se le consulta cuando el sistema ya está configurado, llega tarde. Si solo aparece cuando hay reclamación, llega tarde.

La doctrina refuerza una idea esencial:

El asesoramiento del DPD debe poder operar en la fase de concepción del tratamiento, no solo en la fase de corrección del problema.

Esto no significa que todo deba pasar por el DPD.

Significa que deben existir criterios de escalado:

Nuevos formularios con datos sensibles. Solicitudes documentales de alto impacto. Procesos laborales con datos de salud. Tratamientos con menores. Cambios relevantes en procesos de alta. Nuevos campos obligatorios. Procesos de verificación de identidad. Automatización de recogida de datos. Uso de campos libres en contextos sensibles.

La pregunta de gobierno es:

¿El DPD conoce las decisiones relevantes antes de que produzcan riesgo?

16. La auditoría debe revisar lo que se pregunta

Una auditoría de protección de datos no debería limitarse a revisar bases de datos, contratos, políticas o registros.

Debe revisar las preguntas.

Debe revisar formularios. Debe revisar campos. Debe revisar plantillas. Debe revisar guiones. Debe revisar correos tipo. Debe revisar solicitudes documentales. Debe revisar pantallas de alta. Debe revisar campos obligatorios en CRM, ERP, LMS, HRIS o plataformas internas. Debe revisar qué documentación se pide y por qué.

La pregunta de auditoría más importante puede ser esta:

¿Puede la organización demostrar por qué cada dato que pide es necesario antes de pedirlo?

No por qué lo conserva.
No por qué lo usa.
No por qué lo protege.

Antes:

por qué lo pide.

Eso convierte la solicitud de datos en objeto auditable.

Y obliga a generar evidencia:

Matriz de campos. Justificación de finalidad. Base jurídica por dato. Criterio de obligatoriedad. Clasificación de sensibilidad. Fecha de aprobación. Responsable interno. Versión del formulario. Revisión por privacidad. Alternativas descartadas. Fecha de revisión periódica.

La responsabilidad proactiva no vive en declaraciones. Vive en evidencias.

17. Una matriz práctica para pensar antes de pedir

Una organización que quiera aplicar bien esta doctrina podría incorporar una matriz sencilla de decisión antes de crear o modificar formularios y solicitudes.

Esta matriz no es una carga administrativa.

Es una herramienta de pensamiento.

Sirve para obligar a la organización a detenerse antes de pedir.

Y esa pausa puede evitar muchos incumplimientos.

18. Del “pedir por si acaso” al “pedir con justificación”

El caso permite identificar una cultura organizativa muy frecuente: la cultura del “por si acaso”.

Pedimos más por si acaso. Guardamos más por si acaso. Exigimos documentos por si acaso. Convertimos campos en obligatorios por si acaso. Pedimos diagnósticos por si acaso. Solicitamos copias completas por si acaso. Mantenemos campos libres por si acaso.

El problema es que el “por si acaso” no es un principio del RGPD.

El RGPD exige finalidad. Exige licitud. Exige minimización. Exige proporcionalidad. Exige transparencia. Exige seguridad. Exige responsabilidad.

La cultura madura no pregunta:

“¿Nos vendría bien tener este dato?”

Pregunta:

¿Podemos justificar que necesitamos pedirlo?

Esa diferencia separa el cumplimiento aparente del cumplimiento real.

19. El efecto dominó en el programa de protección de datos

La doctrina genera un efecto dominó claro.

En el gobierno, obliga a definir quién puede decidir qué datos se piden y bajo qué procedimiento.

En el Registro de Actividades de Tratamiento, obliga a que no sea solo un inventario de bases de datos, sino una herramienta para comprender finalidades, categorías de datos, puntos de entrada y justificación de necesidad.

En las políticas, obliga a incluir reglas claras sobre formularios, solicitudes documentales, campos obligatorios y categorías especiales.

En los procedimientos, obliga a incorporar revisión previa de privacidad cuando se diseñan o modifican flujos de recogida.

En los sistemas, obliga a configurar controles que impidan o dificulten pedir datos excesivos.

En la formación, obliga a entrenar a las áreas para preguntar mejor.

En la auditoría, obliga a revisar no solo lo que se conserva, sino lo que se solicita.

En la evidencia, obliga a documentar por qué se pide cada dato relevante.

Este es el efecto dominó real.

No cambia solo la interpretación de una palabra. Cambia el modo en que una organización debe concebir el ciclo de vida del dato.

20. Preguntas para que una organización se examine

Cualquier organización podría hacerse estas preguntas:

¿Tenemos inventariados todos los formularios activos?

¿Sabemos quién puede crear o modificar campos?

¿Revisamos los campos obligatorios?

¿Tenemos criterios para pedir datos de salud?

¿Distinguimos entre dato necesario y dato conveniente?

¿Evitamos recoger datos “por si acaso”?

¿Nuestros sistemas bloquean solicitudes excesivas?

¿Nuestros equipos saben qué no deben pedir?

¿El DPD interviene antes o después del problema?

¿Auditamos las solicitudes documentales?

¿Tenemos evidencia de por qué pedimos cada dato?

¿Formamos a las áreas para diseñar preguntas proporcionales?

¿Revisamos periódicamente formularios antiguos?

¿Sabemos qué campos se añadieron, cuándo y por quién?

¿Podríamos defender mañana ante una autoridad por qué pedimos cada dato?

Si la respuesta a varias de estas preguntas es negativa, el problema no está solo en un formulario.

Está en el programa.

21. Conclusión: la organización madura piensa antes de preguntar

La doctrina del Tribunal Supremo obliga a mirar el cumplimiento desde su concepción.

No desde la base de datos. No desde el expediente. No desde la brecha. No desde la reclamación. No desde la auditoría.

Desde antes.

Desde la pregunta.

Ese es el verdadero valor del caso.

Nos recuerda que el riesgo no nace únicamente cuando el dato se almacena. Puede nacer antes, cuando la organización decide pedirlo sin haber justificado su necesidad.

Nos recuerda que la minimización no es una operación correctiva. Es una disciplina de diseño.

Nos recuerda que la protección de datos desde el diseño no es una cláusula elegante. Es una forma de pensar procesos, sistemas y decisiones.

Nos recuerda que la responsabilidad proactiva no consiste en tener documentos, sino en poder demostrar que la organización pensó correctamente antes de actuar.

Y nos deja una lección sencilla, pero exigente:

La organización madura no es la que explica bien por qué conserva un dato. Es la que puede demostrar por qué decidió pedirlo.

Por eso, la frase final debería quedar grabada en cualquier programa de protección de datos:

La minimización no empieza en la base de datos. Empieza en la pregunta.

Bibliografía

Garrigues. “El Tribunal Supremo fija el alcance del concepto de ‘tratamiento’ y obliga a cumplir los principios del RGPD desde la solicitud de datos personales”, 28 de abril de 2026. (Garrigues)

Sentencia del Tribunal Supremo. STS 1590/2026, de 26 de marzo de 2026. STS 1590/2026 – ECLI:ES:TS:2026:1590 – Poder Judicial

Reglamento (UE) 2016/679, Reglamento General de Protección de Datos, texto publicado en el BOE/DOUE. Especialmente artículos 4.2, 5 y 25. (boe.es)

Agencia Española de Protección de Datos. Guía de Protección de Datos por Defecto. (aepd.es)

Agencia Española de Protección de Datos. Comentario a la Sentencia. ¿En qué momento comienza legalmente un tratamiento de datos personales? | AEPD

Comité Europeo de Protección de Datos. Directrices 4/2019 relativas al artículo 25. Protección de datos desde el diseño y por defecto. (edpb.europa.eu)