[vcw-converter symbol1=»BTC» symbol2=»USD» color=»grey» initial=»1″ fullwidth=»yes»]
 
[vcw-price-big-label symbol=»BTC» color=»orange» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]
[vcw-price-big-label symbol=»XRP» color=»amber» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]
[vcw-price-big-label symbol=»ETH» color=»yellow» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]
[vcw-price-big-label symbol=»BCH» color=»grey» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]
[vcw-price-big-label symbol=»EOS» color=»grey» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]
[vcw-price-big-label symbol=»LTC» color=»grey» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]
[vcw-price-big-label symbol=»ADA» color=»grey» currency1=»USD» currency2=»EUR» currency3=»GBP» url=»» target=»_blank» fullwidth=»yes»]

Compatibilidad de Smart Contracts y GDPR (III)

Compatibilidad de Smart Contracts y GDPR (III)


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 éste 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 clausula 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.