En esta sección se analiza cómo el RGPD contiene únicamente obligaciones para los responsables del tratamiento (y procesadores) y cómo esto puede influir indirectamente en los proveedores de tecnología.

La protección de datos desde el diseño puede considerarse como la consideración de la protección de datos no sólo en las operaciones de tratamiento que tienen lugar en la fase operativa, sino también en las fases anteriores de planificación y ejecución. En términos más generales, se podría considerar que la protección de datos desde el diseño es una metodología que tiene en cuenta la protección de datos en todas las fases del ciclo de vida de una actividad^[1] de tratamiento, desde su concepción, pasando por su diseño e implementación, hasta su uso operativo y su desmantelamiento final.

El ciclo de vida completo suele implicar actividades por parte de otros actores además del responsable y el encargado del tratamiento. Lo más importante es que muchas decisiones que afectan a los aspectos de protección de datos de una actividad de tratamiento son tomadas por los proveedores de tecnología, que a menudo diseñan e implementan software y sistemas. Cuando los proveedores de tecnología invierten en el desarrollo de productos y servicios que luego se ofrecen en el mercado, también contribuyen a definir el estado de la técnica de un determinado tipo de tratamiento de datos personales.

En cambio, el RGPD establece obligaciones para los responsables y los encargados del tratamiento. Carece de cualquier obligación directa para los proveedores de tecnología. En su dictamen preliminar sobre la privacidad desde el diseño^[2], el SEPD señala este hecho al afirmar lo siguiente: ^[3]

“Una grave limitación de las obligaciones del artículo 25 es que solo se aplican para imponer una obligación a los responsables del tratamiento y no a los desarrolladores de esos productos y tecnología utilizados para procesar datos personales. La obligación para los proveedores de productos y tecnología no está incluida en las disposiciones sustanciales del RGPD.”

Dado que el RGPD en su conjunto, y el art. 25 en particular, expresan únicamente obligaciones para los responsables del tratamiento (y los encargados del mismo), el alcance de la presente sección se limita en consecuencia.

Aunque no existen obligaciones legales para los proveedores de tecnología, el art. 25 del RGPD les influye indirectamente. El considerando 78 del RGPD lo insinúa al afirmar lo siguiente^[4]“Los principios de protección de datos por diseño y por defecto también deben tenerse en cuenta en el contexto de las licitaciones públicas”. El modo en que se produce la influencia sobre los proveedores de tecnología se describe con más detalle en la siguiente sección.

El argumento se centra en el software creado por un proveedor de tecnología.Haydos opciones para que un controlador pueda obtener dicho software:

• Como resultado de un desarrollo a medida, o
• Adquiriendo el software en el mercado.

En el primer caso, el diseño y el desarrollo del software es impulsado por el controlador y el proveedor de tecnología puede ser interno o externo; en el segundo caso, hay una multitud de controladores con necesidades similares que crean una demanda de mercado para ciertos tipos de software. El diseño y el desarrollo del software lo desencadena el proveedor de tecnología con el objetivo de lograr una posición competitiva en el mercado.

Los detalles técnicos inherentes al desarrollo de software suelen ser inaccesibles para los controladores y sus representantes.Por lo tanto, en ambos casos, la interacción entre los controladores y los proveedores de tecnología se limita a la comunicación sobre los requisitos. En concreto, el papel de los requisitos en los dos casos es el siguiente:

• En el caso del desarrollo a medida, los requisitos son la principal herramienta de los controladores para expresar los objetivos del proceso de desarrollo. Los requisitos también se utilizan para determinar si el proceso de desarrollo ha concluido con éxito. Esto ocurre durante las pruebas de aceptación.
• En el caso de los controladores que compran software, necesitan requisitos que les guíen en la selección del software adecuado entre la oferta del mercado. En el caso de las licitaciones, estos requisitos pueden comunicarse a los proveedores de tecnología para solicitar ofertas adecuadas a las necesidades; en el caso de la compra de software sin licitación, los controladores deben verificar si varias ofertas de software candidatas satisfacen los requisitos. En ambos casos, la validación de las ofertas en relación con los requisitos es un factor importante en la decisión de compra por parte del controlador.

Así, mientras que las obligaciones de los proveedores de tecnología están fuera del ámbito del art. 25, los responsables del tratamiento están obligados a determinar los requisitos de protección de datos adecuados y a asumir la plena responsabilidad del software que utilizan. La validación de los programas informáticos con respecto a los requisitos puede tener en cuenta el estado de la técnica y el coste de la aplicación (véase el artículo 25 del RGPD y el debate posterior). Sin embargo, la ausencia o el coste excesivo de un software adecuado en el mercado no puede considerarse una justificación válida para utilizar un software inadecuado.

 

 

1. El término actividad de tratamiento se utiliza aquí en el sentido del Art. 30 del RGPD y 4(16)(b) del RGPD. En ambos casos, una actividad de tratamiento es la unidad básica de la empresa de un controlador que implica el tratamiento de datos personales. ↑
2. El Supervisor Europeo de Protección de Datos (SEPD), Dictamen 5/2018, Dictamen preliminar sobre la privacidad desde el diseño, 31 de mayo de 2018, https://edps.europa.eu/sites/edp/files/publication/18-05-31_preliminary_opinion_on_privacy_by_design_en_0.pdf (última visita 29/6/2020). ↑
3. Páginas 7 y 8. ↑
4. Véase la frase 5. ↑