+34 960 500 761

Smart contracts y GDPR – Parte II

Abordamos el último artículo sobre smart contracts y GDRP hablando sobre el derecho del interesado a obtener intervención humana, el derecho del interesado a ser informado, evaluaciones de impacto y protección de datos por diseño y por defecto.

Derecho del interesado a obtener intervención humana

Para no perdernos en el análisis, de nuevo exponemos el contenido del artículo 22 GDPR:

Todo interesado tendrá derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos en él o le afecte significativamente de modo similar.

El apartado 1 no se aplicará si la decisión:

a) es necesaria para la celebración o la ejecución de un contrato entre el interesado y un responsable del tratamiento;

b) está autorizada por el Derecho de la Unión o de los Estados miembros que se aplique al responsable del tratamiento y que establezca asimismo medidas adecuadas para salvaguardar los derechos y libertades y los intereses legítimos del interesado, o

c) se basa en el consentimiento explícito del interesado.

En los casos a que se refiere el apartado 2, letras a) y c), el responsable del tratamiento adoptará las medidas adecuadas para salvaguardar los derechos y libertades y los intereses legítimos del interesado, como mínimo el derecho a obtener intervención humana por parte del responsable, a expresar su punto de vista y a impugnar la decisión.

Una vez releído el artículo, observamos que en el apartado 3 del mismo se contemplan derechos y garantías con los que cuenta el interesado en el tratamiento automatizado.

Aplicando el apartado 3 al ámbito de los smart contracts, emergen 3 cuestiones:

1) ¿Qué se considera intervención humana?

2) ¿En qué punto ha de darse dicha intervención?

3) ¿El responsable del tratamiento puede proporcionar dicha intervención humana?

En virtud de la Guía del Grupo de Trabajo del Artículo 29, para que una acción se considere bajo participación humana, el responsable del tratamiento debe garantizar que cualquier supervisión de la decisión sea significativa, en vez de ser únicamente un gesto simbólico. El Grupo de Trabajo del Artículo 29 establece que toda revisión debe ser llevada a cabo por una persona con la autorización y capacidad adecuadas para modificar la decisión.

Otro aspecto muy interesante de la Guía del Grupo de Trabajo del Artículo 29 es que la intervención humana puede tener lugar después de que haya ocurrido la decisión, y no necesariamente en el curso de la misma. En el contexto de los smart contracts podríamos imaginar una “revisión” del resultado de un smart contract una vez ha sido ejecutado. Desde un punto de vista puramente técnico, esto es relativamente sencillo, dado que leer un código con estructura “if this, then that”, no supone un gran reto desde el punto de vista técnico.

En contraste con esta viabilidad desde el punto de vista técnico, las posibilidades de intervención humana contemplada en el artículo 22.3 del GDPR son quizás más difíciles de alcanzar en el contexto de los smart contracts.

Someter un smart contract a la intervención humana en un entorno empresarial tradicional, como una cadena de suministro, puede ser fácilmente implementado, ya que el smart contract no deja de ser un medio técnico para mejorar procesos dirigidos por personas. Sin embargo, si nos dirigimos a otros contextos, diseñados para alejarse de la intervención humana, la situación cambia, y esta no sería fácilmente implementable.

Consideremos, por ejemplo, el caso de un smart contract que “gobierna” la compraventa de tokens; o un smart contract que “gobierna” una DAO u Organización Autónoma Descentralizada (una DAO es un tipo de empresas que utilizan blockchain como forma de funcionamiento. Estas empresas tienen sus propias reglas y formas democráticas de obtener consenso. No existen en ningún registro mercantil ni son parte de ningún estado). En este tipo de casos, la capacidad de intervención humana será más limitada, ya que este tipo de sistemas lo que buscan es alejarse de la misma.

Por último, debemos fijarnos en la cuestión 3 que ha surgido en torno al artículo 22.3 GDPR.

En virtud del mismo, el responsable debe proporcionar las medidas adecuadas para salvaguardar los derechos y libertades del interesado, que tendrá como mínimo el derecho a obtener intervención humana por parte del responsable.

Como se ha venido observando a lo largo de este artículo, la identidad del responsable del tratamiento en blockchains públicas es incierta, y debe argumentarse que habrá un número de corresponsables del tratamiento en los niveles de infraestructura y aplicación y que el titular de la clave privada (que seguramente será una de las partes intervinientes en el smart contract) también puede ser calificado como un responsable del tratamiento.

Si todas estas partes deben proporcionar una opción de intervención humana es un asunto que las Autoridades de Control deben aclarar.

Derecho del interesado a ser informado

Cuando tenga lugar un tratamiento automatizado, el interesado tiene derecho a que se le informe de este hecho. Qué información exacta se le debe proporcionar suscita cierto debate.

El artículo 12 del GDPR indica que el responsable debe proporcionar a los interesados información concisa, transparente, inteligible y de fácil acceso acerca del tratamiento de sus datos.

Cómo funciona este derecho del interesado en el tratamiento automatizado, va ligado con los artículos 13, 14 y 15 del GDPR, así como el considerando 71.

El artículo 13.2 f) del GDPR establece que el interesado tiene derecho a que se le facilite información acerca de:

La existencia de decisiones automatizas, incluida la elaboración de perfiles, a que se refiere el artículo 22, apartados 1 y 4, y, al menos en tales casos, información significativa sobre la lógica aplicada, así como la importancia y las consecuencias previstas de dicho tratamiento para el interesado.

El artículo 14.2 g) GDPR impone la misma obligación al responsable del tratamiento en caso de que los datos personales no hayan sido obtenidos directamente del interesado, y lo mismo se reitera en el artículo 15.1 h) GDPR.

Por tanto, la información que debe proporcionarse al interesado es (i) la existencia de decisiones automatizadas; (ii) información acerca de la lógica aplicada; y (iii) la importancia y consecuencias de dicho tratamiento.

Teniendo en cuenta la complejidad del aprendizaje automatizado, resulta complicado saber qué información acerca de la lógica aplicada debe trasladarse al interesado.

El Grupo de Trabajo del Artículo 29 aborda en la Guía esta situación con el siguiente ejemplo; un responsable del tratamiento utiliza la calificación crediticia para evaluar y rechazar la solicitud de préstamo de una persona. En virtud de la información que debe proporcionarse al interesado, el responsable del tratamiento debe explicar que este proceso le ayuda a tomar decisiones justas y responsables sobre préstamos. Asimismo deberá ofrecer detalles acerca de las principales características consideradas a la hora de tomar la decisión, la fuente de información y la pertinencia.

A la hora de aplicar este requisito en el contexto de un smart contract, deben tenerse en cuenta dos puntos:

1) Teniendo en cuenta que la obligación de informar al interesado recae sobre el responsable del tratamiento, nos encontramos con el mismo problema que hemos ido abordando a lo largo de este artículo: la dificultad de localizar a los responsables del tratamiento en una blockchain.

2) El cumplimiento de la obligación debe ser sencillo: los smart contracts cuya estructura se está analizando en el presente artículo no involucran grandes cantidades de datos, y la lógica que se les aplica es una estructura sencilla basada en una relación “if/then”. Por tanto, el cumplimiento de la obligación de informar en este punto debe ser fácil en comparación con el punto anterior analizado.

Vale la pena señalar la conexión entre el derecho a informar al interesado y la capacidad de legitimar el tratamiento automatizado a través del consentimiento del interesado.

Cabe plantearse qué nivel de información es necesario para que el consentimiento del interesado sea válido, ya que, si no se entienden los detalles del tratamiento automatizado se puede considerar que el consentimiento no es válido por no cumplir los requisitos recogidos en el GDPR.

Evaluaciones de impacto

En algunas situaciones, el uso del tratamiento automatizado desencadena la obligación de llevar a cabo evaluaciones de impacto.

El artículo 35 del GDPR estipula lo siguiente:

 La evaluación de impacto relativa a la protección de los datos a que se refiere el apartado 1 se requerirá en particular en caso de:

  • evaluación sistemática y exhaustiva de aspectos personales de personas físicas que se base en un tratamiento automatizado, como la elaboración de perfiles, y sobre cuya base se tomen decisiones que produzcan efectos jurídicos para las personas físicas o que les afecten significativamente de modo similar;
  • tratamiento a gran escala de las categorías especiales de datos a que se refiere el artículo 9, apartado 1, o de los datos personales relativos a condenas e infracciones penales a que se refiere el artículo 10; o
  • observación sistemática a gran escala de una zona de acceso público.

A primera vista, nada nos lleva a concluir que una evaluación de impacto debe preceder a la ejecución de un smart contract. Y es que, las evaluaciones de impacto son obligatorias cuando hay un tratamiento automatizado (nótese que la obligación aparece con los tratamientos automatizados no en las decisiones basadas únicamente en tratamientos automatizados) destinado a la evaluación sistemática y exhaustiva de aspectos personales de personas físicas, lo cual nos aleja del contexto de los smart contracts.

A pesar de ello, se puede argumentar que, en determinadas circunstancias, los smart contracts son una nueva tecnología que requiere de evaluaciones de impacto. Aunque la estructura “if/then” sobre la que se configuran los smart contracts lleva tiempo usándose en diferentes contextos (como las máquinas de refrescos, como vimos al comienzo de este artículo), la blockchain sobre la que descansan sí constituye una nueva tecnología que implica un alto riesgo desde el punto de vista de protección de datos.

Habrá que analizar caso por caso cada smart contract de forma que el riesgo específico sea analizado; y en caso de duda, una evaluación de impacto será siempre una forma de asegurar el cumplimiento del GDPR.

Protección de datos por diseño y por defecto

El artículo 25 del GDPR obliga al responsable del tratamiento a aplicar las medidas técnicas y organizativas apropiadas con miras a garantizar que, por defecto, solo sean objeto de tratamiento los datos personales que sean necesarios para cada uno de los fines específicos del tratamiento.

Esta obligación tiene implicaciones para los smart contracts. El artículo 25 del GDPR desencadena una serie de obligaciones por defecto que pueden hacer que los desarrolladores se lo piensen dos veces antes de implementar su código de smart contract en una blockchain.

Por ejemplo, tenemos el problema del cumplimiento del principio de la minimización de los datos, o el problema de implementar mecanismos de ejercicio de derechos de los interesados.

A la luz de tanta incertidumbre, resulta atractiva la posibilidad de acudir a un mecanismo de certificación, como un elemento probatorio para acreditar el cumplimiento de los requisitos del GDPR y evitar así la imposición de multas por incumplimiento.

Del análisis arriba expuesto hemos revelado que la prohibición de que los interesados sean objeto de una decisión basada únicamente en el tratamiento automatizado se aplica a los smart contracts.

Teniendo en cuenta que el uso de los mismos puede justificarse cuando sea necesaria la celebración o la ejecución de un contrato entre el interesado y un responsable del tratamiento, cuando esté autorizado por el Derecho de la Unión, o bien cuando se base en el consentimiento explícito del interesado, estos sistemas deben diseñarse desde un punto de vista “data protection – friendly”. Esto incluirá el derecho del interesado a obtener intervención humana por parte del responsable, a ser informado respecto a los tipos de tratamiento y, en algunos casos, una evaluación de impacto.

El cumplimiento con estos requisitos implicará algunas dificultades, especialmente en el contexto de la tecnología blockchain.

Smart contracts sofisticados

Con su origen en la ideología ciberpunk, la tecnología blockchain fue diseñada inicialmente para evitar interferencias de terceros, incluido el Estado. Partiendo de esa base, esta tecnología no se diseñó para cumplir con la regulación. Con el tiempo, las nuevas aplicaciones de la tecnología blockchain se han distanciado de esa idea original y es claro que blockchain debe adaptarse a derecho de cara a un reconocimiento y una adopción a gran escala.

Existe una tendencia continua a sofisticar aún más los smart contracts con el fin de hacerlos compatibles con los requisitos del mundo actual. Conscientes del hecho de que las cosas pueden salir mal (como un bug en el código) o que pueden surgir circunstancias inesperadas, la ejecución automatizada que caracteriza a los smart contracts podrían no ser siempre la mejor opción. A pesar de que la ejecución automatizada promete importantes mejoras en eficiencia y la realización de nuevos modelos de negocios, hay una ola de experimentación continua con mecanismos que aprovechan las ventajas que los smart contracts y su ejecución automatizada mientras mitigan su inevitabilidad absoluta.

Dos amplias opciones emergen a este respecto.

En primer lugar, se están llevando a cabo investigaciones y se están haciendo esfuerzos por parte de la industria para hacer una estructura más sofisticada para los smart contracts que la utilizada “if/then” para permitir su uso en situaciones más complejas.

Esto puede llegar a tener importantes efectos secundarios para el cumplimiento de GDPR, ya que prevén una opción de intervención humana. Estas configuraciones incluyen el uso de la verificación de firma múltiple (“MultiSig”), por lo que las partes deben activar el software con sus respectivas claves privadas antes de que pueda ejecutarse.

Los smart contracts con estructura MultiSig permitirían al comprador de un bien transferir el precio a una dirección de blockchain que se basa en otras tres direcciones: la suya, la del vendedor y la de un árbitro independiente. Si la venta de los bienes se produce sin problema, el comprador y el vendedor firmarían la transacción y liberarían los fondos.

En caso de que tuviese lugar un problema, ambos podrían usar su clave privada para reembolsar los fondos al comprador.

Cuando las partes no pueden resolver el problema, el árbitro usaría su clave para asignar fondos a su conveniencia. Sin embargo, es cuestionable si estos mecanismos podrían satisfacer los requisitos del Artículo 22 (3) GDPR, que parece requerir una intervención humana ex post en lugar de una intervención humana ex ante.

Asimismo, se están desarrollando mecanismos de “arbitraje” para ser incorporados a los smart contract.

En la actualidad, sigue siendo una cuestión abierta la forma en que los sistemas de ejecución automatizada tratan mejor las disputas, en particular cuando el smart contract forma parte de una configuración contractual. Una solución que podría preverse es incorporar un hash de un contrato en papel relacionado en el smart contract y si este falla o tienen un bug, el contrato en papel prevalecerá. Como esta evaluación se haría a través de un ser humano, el requisito previsto en el punto 3 del Artículo 22 del GDPR se cumpliría.

Numerosos proyectos actualmente buscan integrar sistemas de resolución de conflictos en smart contracts. Un multisig podría usarse para detener la ejecución de un smart contract en el caso de una disputa o consecuencias imprevistas para contar con un árbitro. El contrato legal paralelo podría equiparse con una cláusula de arbitraje y el smart contract podría integrar una biblioteca de arbitraje que permite paralizar, reanudar y alterar el software que conecta el smart contract con los seres humanos.

Otros proyectos están trabajando en la posibilidad de detener el efecto de los smart contracts (por ejemplo, en caso de que un empleado abandone la empresa y el contrato o el pago debe ser detenido). El árbitro puede ser cualquiera, desde personas elegidas al azar de forma aleatoria hasta expertos designados por las partes y, quién sabe, tal vez miembros de El poder judicial en el futuro.

Estos mecanismos están motivados principalmente por el deseo de que la ejecución de un smart contract refleje la verdadera intención de sus partes. Al mismo tiempo, estos desarrollos podrían ser un paso hacia el cumplimiento de GDPR, constituyendo una forma de intervención humana en virtud del artículo 22, apartado 3.

Además, cuando se crean interfaces con el mundo real, se pueden explorar para proporcionar información sobre el tratamiento de datos a los sujetos de datos y, por lo tanto, también cumplir con los requisitos relacionados. Cabe destacar que estos procesos implementan algo explícitamente considerado por La Guía, ya que en ella se destaca que el requisito de intervención humana se puede implementar a través de “un mecanismo para la intervención humana en determinados casos puede ser, por ejemplo, ofrecer un enlace a un procedimiento de recurso en el momento en que se informe al interesado de la decisión automatizada, con plazos acordados para su revisión y un punto de contacto designado para cualquier consulta”.

Esto es precisamente lo que estos desarrollos prometen lograr, lo que indica que a medida que los smart contracts basados ​​en blockchain se vuelven más sofisticados, existe una posibilidad de cumplimiento por diseño al asegurarse de que se cumplan los requisitos de GDPR en relación con el tratamiento basado en decisiones automatizadas.

Conclusión

El GDPR insiste en que las personas no deben ser sometidas a decisiones automatizadas que supongan un efecto significativo en sus vidas, legal o de otro tipo, que sean el resultado de un tratamiento de datos personales exclusivamente automatizado. Si bien este tratamiento puede diseñarse para que sea compatible con la ley protección de datos de la UE, el GDPR impone una serie de condiciones tales como que haya opción para la intervención humana y que las modalidades de tratamiento sean explicadas al interesado.

El análisis anterior ha revelado que, pese a que los smart contracts per se no cumplen los requisitos del artículo 22 del GDPR, pueden ser diseñados para ser compatibles con este.

Artículo escrito por:

Marina Foncuberta

Abogada especialista en privacidad, blockchain, ciberseguridad, e-commerce y telecomunicaciones

marina.foncuberta@ath21.com

ATH21 es una firma legal especializada en tecnología Blockchain y criptoactivos. Si quieres saber más o tienes cualquier duda, puedes contactar con nosotros aquí.

Photo by Joshua Sortino on Unsplash

Related posts