El Margen de la Ley :: El Blog de Audens

Abogados de Nuevas Tecnologías

Blockchain, IA y supresión de datos personales

La tecnología blockchain emergió como una herramienta revolucionaria con aplicaciones que van mucho más allá de las criptomonedas, como por ejemplo los smart contracts que permiten automatizar el cumplimiento de acuerdos sin intermediarios, la gestión de cadenas de suministros, la gestión de derechos de autor o los sistemas de voto electrónico para ciertas operaciones. Su característica principal es que se trata de un sistema distribuido, algo que ofrece ventajas importantes como la seguridad y la inmutabilidad de los registros, ya que ya que los datos no se almacenan en un único servidor, sino que se replican en múltiples nodos de la red. De esto ya he hablado en otras entradas del blog.

Al no existir una autoridad central que controle la blockchain, surgen dudas o impedimentos sobre quién es responsable en caso de fallos o usos indebidos, o en cómo aplicar las normas de los estados cuando todo está tan distribuido, como por ejemplo, la protección de datos personales en las redes blockchain. Es un oxímoron, pues mientras que la blockchain garantiza la inmutabilidad de los datos, el Reglamento General de Protección de Datos establece derechos como la rectificación o la supresión.

La Agencia Española de Protección de Datos (AEPD) ha publicado recientemente una nota técnica titulada “Blockchain y protección de datos: hacia un tratamiento compatible con el RGPD”, en la que analiza cómo alinear el uso de la tecnología blockchain con los requisitos del RGPD así como proporcionar pautas para diseñar soluciones que cumplan con las normativas europeas en materia de privacidad y protección de datos. O por lo menos lo intenta.

Según la Agencia, las soluciones basadas en blockchain deberían implementar estrategias técnicas como el cifrado, el uso de hashes o referencias externas, para limitar el acceso a los datos personales de forma preventiva sin comprometer la integridad del sistema. Es decir, que la mejor solución es evitar que los datos personales se incluyan directamente en la blockchain; así, no habrá necesidad de suprimir ni modificar nada. O como diría mi abuela: muerto el perro, se acabó la rabia.

Sin embargo, en su análisis, la AEPD también admite que estas soluciones no resuelven completamente las tensiones entre la tecnología blockchain y el RGPD, precisamente por que estas medidas deberían aplicarse al más puro estilo del principio de la privacidad desde el diseño y por defecto. Para ello, la Agencia sugiere explorar esquemas de gobernanza que permitan asignar roles claros dentro de la red blockchain.

En mi opinión hay dos problemas claros de difícil solución. El primero es que la blockchain es descentralizada desde el diseño y por defecto y tratar de controlarla legalmente con las herramientas actuales no va a servir de nada sin una regulación especial al efecto. Por supuesto, no es algo fácil y hay que pensarlo bien, pues cuanta más regulación existe, más lejos de ella se montan estas redes, lo que supone un riesgo para los derechos y libertades de las personas, y también para su patrimonio. Actualmente, localizar a los titulares de algunas redes o sistemas que usan esta tecnología es tremendamente complicado cuando se quieren perseguir estafas o robos con criptomonedas, no digamos ya para rectificar un dato personal.

El segundo es el impacto de la Inteligencia artificial en la blockchain. De hecho, creo que la AEPD no ha considerado que la IA que puede complicar aún más las cosas. En los últimos años, la inteligencia artificial está permitiendo desarrollar aplicaciones cada vez más sofisticadas en el ámbito del blockchain, como el análisis de grandes volúmenes de datos generados por estas infraestructuras, facilitando la extracción y análisis de datos personales dentro de una red blockchain, aumentando los riesgos de reidentificación, incluso en datos que inicialmente han sido cifrados o anonimizados.

En mi opinión, la nota técnica de la AEPD representa un avance para abordar los retos que plantea la blockchain en el cumplimiento del RGPD pero pone de manifiesto que aún estamos ante un terreno complejo y abierto. Siempre he defendido que el equilibrio entre innovación y cumplimiento normativo es crucial para impulsar la competitividad y el desarrollo de los negocios, pero lo cierto es que la blockchain es mayoritariamente utilizada por personas que invierten o confían en sistemas y redes poco adecuadas, ubicadas en países como Singapur, Hong Kong, las Islas Cook o San Vicente y las Granadinas u otros chiringuitos financieros, entre otros motivos, por la falta de incentivos para desarrollarse en Europa y debido a su hiperregulación, habría que atajar esta situación y puede que solo a base de legislar y sancionar no sea el camino adecuado. El equilibrio es complicado, pero no imposible.

Reglamento IA: de la teoría a la práctica

La inteligencia artificial (IA) lleva más de tres décadas transformando sectores clave, desde la industria y las telecomunicaciones hasta la medicina y la educación. Sin embargo, el auge de la IA generativa y su reciente democratización han supuesto una revolución, planteando no solo nuevas oportunidades, sino también desafíos inéditos en términos de regulación y cumplimiento normativo. Gracias a la publicación del Reglamento IA de la Unión Europea (Reglamento 2024/1689 de 13 de junio de 2024) el pasado 12 de julio en el Diario Oficial de la UE, contamos con normas armonizadas para garantizar un uso ético y seguro de los sistemas de inteligencia artificial. Este marco regulatorio afecta tanto a desarrolladores y comercializadores de IA como a cualquier empresa que utilice estas tecnologías: de ahí que sea crucial entender los puntos clave de esta normativa y cómo pueden impactar en los negocios, para poder tomar las decisiones adecuadas desde este mismo momento.

El Reglamento IA tiene como objetivo establecer un estándar legal común para asegurar un uso ético y seguro de los sistemas de inteligencia artificial (con especial énfasis en aquellos que presenten un riesgo para la salud, la seguridad o los derechos fundamentales) desde su desarrollo, comercialización y utilización. De hecho, el legislador busca un enfoque equilibrado que garantice que la tecnología se utilice de manera responsable sin eliminar su potencial beneficio, en una industria en auge donde Europa no puede permitirse quedar por detrás de otras potencias.

El RIA es una norma compleja, llena de excepciones y salvedades, por lo que abordarla con detalle en un post es imposible. De todas formas, a modo de resumen, (la norma tiene 180 considerandos, 113 artículos, 13 anexos y 419 páginas) quiero destacar varios aspectos clave a tener en cuenta:

En primer lugar, se trata de una norma de producto, es decir, sus obligaciones principales recaen en los «sistemas basados en máquinas» de IA, con el fin de preservar derechos de las personas, la democracia, el Estado de Derecho y la protección del medio ambiente, mediante obligaciones a fabricantes, distribuidores y usuarios. Para favorecer esta protección, se ha establecido un ámbito de aplicación tremendamente amplio, pues se aplicará también a sistemas IA creados o desplegados fuera de la UE cuando se introduzcan en nuestro mercado único europeo, o cuando cuando los resultados de salida generados por el sistema de IA se utilicen en Europa.

En segundo lugar, se prohíben directamente determinados sistemas de IA por considerarlos contrarios a los valores democráticos de la UE (aunque con algunas excepciones). Esto incluye el empleo de técnicas subliminales para alterar el comportamiento de una persona de manera perjudicial, el tratar de aprovechar vulnerabilidades de grupos específicos o el uso por autoridades públicas para evaluar o clasificar la fiabilidad de personas según su conducta social, con posibles consecuencias negativas. El uso de estos sistemas puede conllevar multas de hasta 30 millones de euros o, en el caso de empresas, de hasta el 6% de su volumen de negocio total anual mundial del ejercicio financiero anterior. ¡Y las multas del RGPD nos parecían altas!

Además, el Reglamento IA especifica una serie de sistemas de alto riesgo sobre los que recaen obligaciones específicas. Podríamos englobarlos en dos categorías: los sistemas consistentes en componentes de seguridad de productos, o que son productos en sí mismos, como los integrados en máquinas, juguetes, ascensores, equipos radioeléctricos, equipos de embarcaciones de recreo, productos sanitarios, automoción o aviación, entre otros; y los que se consideran de alto riesgo por su finalidad, como los que se utilizan para la identificación biométrica y la categorización de personas físicas, la determinación del acceso o la asignación de personas a centros de educación o formación, la evaluación de acceso, la gestión, evaluación, contratación o despido del personal, así como aquellos relacionados con infraestructuras críticas, la aplicación de leyes, la administración de justicia o el acceso a servicios públicos esenciales, entre otros. Para todos quienes están desarrollando o utilizando estos sistemas, la norma prevé una amplia batería de obligaciones.

También se establecen normas para el resto de los sistemas de IA, tanto comunes como aquellos que puedan implicar un riesgo sistémico, basadas en obligaciones de transparencia, evaluación de riesgos y protección de ciberseguridad, así como un continuo recordatorio del cumplimiento del Reglamento General de Protección de Datos cuando se emplee información personal en dichos modelos o sistemas, o tengan incidencia en su entrenamiento o uso posterior.

Destaca también que la norma establece mecanismos de control, vigilancia y supervisión del mercado, así como obligaciones de colaboración con las autoridades de control. Este punto va a resultar complejo en la práctica, pues en España habrá varios organismos con competencias en la materia, dependiendo del tipo de sistema IA que se use y su finalidad. De forma general, la supervisión corresponderá a la AESIA, con sede en A Coruña; pero en función del sistema IA, su composición, finalidad y uso, podrán entrar en juego otras agencias y reguladores, como la AEPD en lo concerniente a datos personales, la Agencia Española de Medicamentos y Productos Sanitarios o en la Agencia Estatal de Seguridad Aérea, por ejemplo.

A modo de conclusión, me gustaría destacar dos ideas. En primer lugar, el Reglamento IA exige un enfoque integral que permita evaluar el grado de implicación de la inteligencia artificial en las organizaciones. Para ello, será imprescindible establecer modelos de gobernanza de IA a nivel interno que integren aspectos técnicos, procesos y organización. Esto implica no solo inventariar todos los sistemas que se empleen (incluidos aquellos integrados en aplicaciones de terceros), sino también analizar su interacción con normativas clave como la de protección de datos, la propiedad intelectual o la reciente Directiva (UE) 2024/2853, sobre responsabilidad por daños causados por productos defectuosos. Solo mediante un modelo de gobernanza interna adecuado, las organizaciones podrán identificar, gestionar y mitigar los riesgos asociados a estos sistemas, sentando así una base sólida para un uso responsable y estratégico de la inteligencia artificial.

La segunda, y quizás la más importante, es aprender de la experiencia de la entrada en vigor del Reglamento General de Protección de Datos en 2016 y su plena aplicación en 2018 y es que este nuevo Reglamento IA será de plena aplicación a los dos años, el 2 de agosto de 2026. Y dos años pasan muy rápido.

En este sentido, resulta imprescindible participar en espacios donde se debate y analiza esta norma en profundidad, como a través de los foros y eventos de la Asociación Profesional de Profesionales de la Privacidad (APEP), o en actualizarse con programas formativos como el curso que estamos impartiendo junto a Aranzadi La Ley. Reforzar el entendimiento técnico y estratégico será esencial para que empresas y profesionales logren convertir esta regulación en un aliado para la innovación y la confianza. Y como sucedió con el RGPD, los próximos años marcarán el ritmo de la transformación digital en Europa. Permítanme cerrar este post como terminé uno escrito el 29 de junio de 2017, sobre la inminente aplicación del RGPD: tempus fugit!

Atención a las licencias «open source»

Foto: Walkator (via Unsplash)

Imaginen que se han embarcado en el desarrollo de una nueva aplicación informática, un proyecto que promete ser un éxito. Tras meses de trabajo, el equipo de desarrolladores está a punto de concluir el producto: ya parece estar listo para su lanzamiento. Están revisando los detalles finales, y alguien lanza una pregunta aparentemente inocente, pero crucial al fin y al cabo: ¿lo vamos a poder monetizar?

Pongámonos en contexto: desarrollar software hoy en día es un proceso que, inevitablemente, implica la integración de librerías de terceros: carece de sentido reinventar la rueda cuando ya existen soluciones sólidas y estables en el mercado, sobradamente probadas. Hacer uso de frameworks o líneas de código ajenos es una práctica común y eficiente, pero requiere un cuidadoso manejo de las licencias que los acompañan, incluyendo las grandes olvidadas: las de “software libre”. Las hay de varios tipos y, como veremos, la elección de unas u otras puede generar un impacto significativo en la posterior explotación del nuestro producto. Especialmente si buscamos comercializarlo… o atraer inversiones.

El software libre se distribuye bajo licencias que permiten utilizar, modificar y redistribuir el código libremente: de ahí que también se conozca como “de código abierto”. Sin embargo, existen multitud de modalidades de textos legales que, en la práctica, dan lugar a implicaciones muy distintas: de ahí que comprender sus diferencias se vuelva fundamental, comenzando por la distinción entre las dos grandes familias de licencias open source: las permisivas y las restrictivas, no siempre compatibles entre sí.

  • Las licencias permisivas, como la MIT o la BSD, conceden mayor libertad al usuario en el uso del código. Por lo general, permiten integrar su contenido en desarrollos propios, crear una nueva versión e, incluso, integrarlo en un proyecto comercial con pocas restricciones. A menudo, basta con incorporar una referencia a la licencia en cuestión; si bien, en algunos casos, debemos publicar los cambios realizados sobre el código original.
  • Por su parte, las licencias restrictivas, como la GNU GPL, imponen requisitos más severos. Al utilizar librerías distribuidas bajo uno de estos acuerdos, podríamos estar obligados a liberar el código fuente de nuestro software en términos similares; lo que permitiría a cualquiera acceder a su contenido, modificarlo y reutilizarlo bajo esas mismas reglas. Aunque esta filosofía es coherente con los principios del software libre y ha dado lugar a no pocos negocios exitosos, puede chocar frontalmente con los intereses comerciales de una empresa que busca mantener en secreto su propiedad intelectual… ¡o atraer inversores!

Pongámonos en el caso de una start-up tecnológica: fondos y business angels, por ejemplo, querrán asegurarse de que su software no está supeditado a restricciones que puedan limitar el retorno de su inversión. Un mal manejo de las licencias open source podría no solo ralentizar la comercialización, sino también hacer que pierdan oportunidades de entrada de capital.

Algo similar podría ocurrir si desarrollamos programas a medida para terceros. Las cesiones de derechos de propiedad intelectual llevan aparejada una garantía de explotación pacífica del software, es decir, de que el cliente pueda utilizarlo sin temor a problemas legales. Si incorporamos código con una licencia restrictiva, sin ser plenamente conscientes de sus términos y condiciones, podemos limitar la capacidad del cliente para explotar el software comercialmente o para integrarlo en otros desarrollos propietarios, o incluso enfrentarnos a posibles demandas en el futuro. Como ven, no se trata de una cuestión trivial: de ahí que resulte crucial conocer las implicaciones jurídicas de las licencias open source que incorporemos a nuestros desarrollos y saber si encajan con nuestro modelo de negocio, para evitar sorpresas desagradables y garantizar que alcanzamos las expectativas de clientes e inversores.

Es evidente que cualquier empresa desea ver su software finalizado, cubriendo las necesidades de los usuarios y, cómo no, generando beneficios. Pero para que este aparente éxito no se convierta en una desagradable sorpresa, es imprescindible prestar atención a las librerías de software libre que se utilicen en el proceso de desarrollo. De ahí que recomendemos que, desde la fase inicial del proyecto, tanto el equipo de desarrollo interno como los colaboradores externos tengan directrices claras sobre los tipos de licencias a los que deben ceñirse: definir este aspecto desde el principio y verificar que se respetan estas directrices nos permitirá asegurar, ya no solo que el código que tan cuidadosamente han elaborado funcione bien, sino que también esté libre de restricciones legales que puedan comprometer nuestro modelo de negocio.

En definitiva, mi consejo es claro: antes de lanzar su próximo producto al mercado, asegúrense de documentar bien las licencias detrás de cada línea de código, ¡y de conocer sus implicaciones! Es un pequeño paso adicional en el proceso de desarrollo, ¡pero podría ahorrarles muchos problemas en el futuro!