A pesar de su carácter transversal, la Data Act llama la atención no solo por sus nobles objetivos y las nuevas reglas del juego que impone, sino también por otros aspectos más secundarios, como puede ser un redactado excesivamente vago en algunos artículos clave que nos abocan inevitablemente a la confusión, pasándole delibera y anticipadamente la patata caliente al TJUE para que nos alumbre el camino de la interpretación, con conceptos clave ausentes de definición y conceptos jurídicos indeterminados, que a más de uno le estarán acentuando la migraña o la imaginación.

Además de las notorias erratas de traducción en las versiones oficiales en diferentes idiomas, cambiando sustancialmente el significado de algunos de sus preceptos, en función de la versión que uno lea.

Pero si hay algo que realmente clama al cielo, es lo descaradamente desapercibido que está pasando a pesar de su inminente aplicación, debido a la total consagración -casi mesiánica- que le estamos otorgando al Reglamento de Inteligencia Artificial, monopolizando el foco normativo y relegándolo al segundo plano, como ese invitado incómodo al que nadie quiere mirar, pero que tiene las llaves del edificio.

Con un enfoque intersectorial y un alcance extraterritorial, con una rabiosa interacción con el RGPD, este nuevo reglamento va a suponer un punto de inflexión.

La Data Act ya está aquí, y está aquí para quedarse.

¡Pero no todo puede ser tan negativo! La Data Act tiene realmente aspectos muy positivos, empezando por su principal objetivo, que es desmantelar el monopolio de datos, de modo que estos dejen de estar solamente en manos de los fabricantes y puedan ser accedidos, usados y monetizados por los usuarios, que, en definitiva, son los generadores de esos datos.

Con el fin de responder a las necesidades de la economía digital y eliminar obstáculos en un mercado interior de datos, el Reglamento establece un marco armonizado que especifica quién tiene derecho a utilizar los datos, en qué condiciones y sobre qué base.

Empecemos por el principio:

Generalmente, al adquirir un producto tradicional, el usuario recibe el producto, con sus componentes y accesorios. Sin embargo, en la era del Internet-Of-Things (IoT) disponemos de productos, tanto de uso industrial como de uso doméstico, que están conectados a internet y son capaces de generar datos nuevos por el simple uso del producto. Estos datos, se suman al producto, pero hasta la fecha, solo han sido accesibles, y, por ende, utilizados y explotados por el fabricante o el titular de los datos (que en la mayoría de los casos suele ser la misma entidad), sin que el usuario, que es quien los genera en primer lugar, pueda beneficiarse en manera alguna de estos. Y aquí es donde, en esencia, entra este Reglamento en juego, otorgando a las personas y empresas el derecho a acceder a los datos producidos mediante la utilización de objectos, máquinas y dispositivos inteligentes.

En este sentido, la definición de “dato” es total, pues lo abarca, por definición, practicamente todo: cualquier representación digital de actos, hechos o información, en formato sonoro, visual o audiovisual. Y sí, como has imaginado, también incluye datos de carácter personal.

-RGPD entró en el chat-.

Esos datos generados por el uso de un producto conectado representan tanto la digitalización de las acciones del usuario como de eventos. Es decir, abarcan tanto los datos registrados de manera intencionada, como los datos resultantes indirectamente de la intervención del usuario, así como los datos relativos a las interacciones del producto conectado. Es decir: datos personales, datos no personales, datos relativos al rendimiento, datos relativos al uso, al no-uso y datos relativos al entorno de los productos conectados y los servicios relacionados.

Por ejemplo, podríamos estar hablando tanto de los registros de actividad de una máquina industrial, como los datos generados automáticamente por sus sensores (p.ej. velocidad, temperatura, humedad, etc.), así como de los datos registrados por aplicaciones integradas, incluidas las aplicaciones que indican el estado del hardware y los fallos de funcionamiento.

Esto incluye también los datos generados por el producto conectado durante el periodo en el que el usuario no interviene, como cuando este decide no utilizarlo durante un periodo de tiempo determinado, dado que el estado de un aparato, por ejemplo, sus pilas o baterías, suele variar cuando este se encuentra en modo de espera o apagado.

En lo material:

El ámbito material de aplicación del Reglamento se centra en los datos brutos (datos primarios), es decir, en esos datos que se generan automáticamente en el producto conectado sin ninguna forma de tratamiento posterior, así como en los datos pre-tratados, que son aquellos datos que, previamente a su tratamiento y análisis, han sido objeto de un tratamiento destinado a hacerlos comprensibles y que puedan ser utilizados. Por ejemplo, con un sencillo cambio de formato que permita la lectura de esos datos.

Cabe destacar que esto no debe interpretarse en el sentido de imponer al fabricante o al titular de datos una obligación de realizar inversiones sustanciales en el limpiado y la transformación de los datos, pues como ha recientemente puntualizado la Comisión Europea, se espera que el usuario o tercero destinatario de los datos, tenga un nivel razonable de capacidad técnica para interpretar esos datos.

A todo esto, el legislador ha optado por incluir los metadatos correspondientes para facilitar esa interpretación y utilización de dichos datos.

En cambio, toda la información que se infiera o se derive (datos secundarios) de tales datos, como resultado de inversiones adicionales en la asignación de valores o conocimientos que aportan los datos, en particular, mediante algoritmos complejos, no están sujetos a la obligación del titular de datos de ponerla a disposición de un usuario o destinatario.

A modo de ejemplo:

Datos derivados: podrían ser informaciones obtenidas a partir de otros datos mediante cálculos: si tienes una lista de cifras de ventas, los ingresos totales serían datos derivados.

Datos inferidos: podrían ser informaciones deducidas a partir de datos existentes: predecir las preferencias de tu cliente basándose en su historial de compras.

El motivo principal de su exclusión es, por un lado, el hecho de que el Reglamento no pretenda desincentivar la inversión interna por parte del fabricante o del titular de los datos en tecnologías de datos, y por el otro, evitar conflictos de propiedad intelectual, ya que los datos protegidos por IP (p.ej. patentes, diseños, copyrights) quedan excluidos.

Por eso, todo gira en torno a los datos primarios, y no en el contenido como tal.

Por poner un ejemplo: si estás leyendo un e-book, escuchando música en Spotify o mirando Boston Legal (recomendadísima) en Netflix, podrás tener acceso como usuario a los datos que genere tu SmartTV donde indique que tal día como hoy, de 09:00h a 12:00h, la aplicación de Netflix estuvo activa, pero no al contenido de lo que leíste, escuchaste o viste, pues obviamente se trataría de contenido protegido por derechos de autor.

Secretos comerciales:

Entrando en materia de exclusiones, y dada la vasta definición de “dato” bajo el prisma la Data Act, que como veremos a continuación, implicará alguna que otra “friction by Design” con el RGPD, si hay un tema más caliente que Córdoba en agosto es el hecho de que los secretos comerciales no quedan excluidos de la obligación por parte del fabricante o titular de los datos de ponerlos a disposición del usuario o de un tercero de su elección.

Repito: los secretos comerciales no están excluidos. Ni frente al usuario ni frente a un tercero que esté actuando en su representación, siempre y cuando haya una condición que se cumpla: los secretos comerciales se preservarán y se revelarán cuando el titular de datos y el usuario hayan adoptado medidas técnicas y organizativas (las famosas “TOMs”) necesarias para preservar su confidencialidad, tales como cláusulas contractuales tipo, acuerdos de confidencialidad, protocolos de acceso estrictos, aplicación de códigos de conducta, etc.

Y es solo en caso de desacuerdo sobre las medidas a implementar, o cuando el usuario no las aplique debidamente, donde el titular, por regla general, podrá retener o suspender esa puesta a disposición de los datos identificados como secretos comerciales.

El Reglamento establece algunas excepciones de dudosa aplicabilidad en la práctica (p.ej. una demostración del riesgo concreto basada en elementos objetivos de la alta probabilidad de sufrir un perjuicio económico grave que implique una pérdida económica significativa como consecuencia directa de su revelación…) a esta regla, terminando todas ellas con la obligación de notificar a la autoridad competente de tu negativa a compartir tus secretos comerciales tras el requerimiento por parte de un usuario o de un tercero actuando en su nombre.

Este es un tema que promete generar mucho litigio, pues a parte de la legitima negativa por parte de empresas de tener que verse obligados a compartir semejante información sensible en términos de negocio con cualquier usuario o tercero que este capacitado para solicitarlo, no deja de ser en sí paradójico: si el titular de los datos tiene que firmar un contrato con terceros donde, entre otras cosas, se especifiquen los secretos comerciales y las medidas a adoptar para preservar su confidencialidad, en si se contradice la idea de secreto comercial, ya que un secreto comercial es, por definición, una información que no es generalmente conocida ni fácilmente accesible, incluso entre las personas que normalmente manejan ese tipo de información. Compartir listas exhaustivas de secretos comerciales con miles de destinatarios y usuarios, implica, a la larga, que esos datos se acaben volviendo generalmente conocidos, y por ende, pierdan su valor comercial.

A título personal, soy de la opinión de que parte de la respuesta la encontramos en el mismo Reglamento: todos los datos sujetos a las obligaciones impuestas por la Data Act emanan de una premisa clave: el diseño. Los datos que los fabricantes tienen la obligación legal de compartir a partir del 12 de Setiembre de 2025, son, por definición, los que ellos mismos han diseñado para que puedan ser extraídos de sus productos (ya sea mediante una conexión física o electrónica), y, por ende, compartidos.

Si un dato no ha sido diseñado para ser extraído del producto conectado, queda automáticamente fuera del alcance del Reglamento. Así que, quizás, sería una buena estrategia, dentro de la libertad de empresa de la que gozan los fabricantes, empezar a identificar los datasets críticos y plantearse la viabilidad, costes y las consecuencias de rediseñar ciertos aspectos…

Huelga decir que una gran cantidad de datos agregados, aunque por separado no constituyan un secreto comercial, pueden utilizarse para determinar cómo funciona un dispositivo o para descubrir secretos comerciales.

En lo territorial:

En cuanto al ámbito territorial, la Data Act tiene un régimen parecido al del RGPD, pues se aplica independientemente del lugar de establecimiento de los fabricantes, proveedores de servicios y titulares de datos. Los fabricantes y proveedores establecidos fuera de la UE deben cumplir con la normativa si su producto conectado o servicio relacionado se introduce y comercializa en el mercado de la UE y, en el caso de los titulares de datos, si ponen los datos a disposición de destinatarios de datos en la UE.

Aquí es vital matizar conceptos: “introducir en el mercado” hace referencia a la transferencia de propiedad, posesión u otro derecho de propiedad entre dos agentes que ocurre después la fase de fabricación. Como tal, un producto conectado solo se ‘introduce en el mercado’ una vez. Todas las operaciones posteriores se consideran como ‘puesta a disposición en el mercado’.

Por cierto, el concepto se refiere a cada producto individual, no a un tipo de producto.

Los usuarios están definidos como personas físicas o jurídicas que poseen un producto conectado o a la que se le han transferido contractualmente derechos temporales de uso (p.ej. leasing). Basta con que estén en la Unión para poder hacer uso de los derechos que les otorga el Reglamento.

En cuanto a los actores se refiere, y para hacer las cosas un poquito más complicadas, existe una especie de multiverso paralelo donde múltiples combinaciones entre ellos son posibles:

Un mismo producto conectado puede tener varios usuarios independientes y de procedencia dispar. Por ejemplo, una empresa (titular de datos) de alquiler de coches, que cada vez que alquila un coche (producto conectado) a una persona distinta (usuario), tiene que poder garantizar el tratamiento separado de los datos de cada usuario distinto, garantizando su confidencialidad y el acceso de estos por separado. También se puede dar el caso que quien alquila (usuario) el coche, no sea una persona física sino una jurídica (otra empresa), relegando a la ecuación la figura de persona física al conductor final del coche, que también puede tener interés en acceder a sus datos para poder subirlos a una app de un tercero (destinatario) que evalúe su manera de conducir y le de consejos para reducir el gasto de gasolina.

Por otro lado, un producto conectado puede tener más de un titular de datos, que necesitan interactuar entre sí. O también se puede dar una situación en la que tengamos un fabricante y un titular de datos que sean empresas diferentes. O diferentes usuarios. O un proveedor de servicios relacionados con el producto conectado que no sea ni el fabricante ni el titular. O incluso un fabricante que también es titular, pero decide contratar a otra entidad para que desempeñe la función de titular de los datos para la totalidad o parte de los productos conectados que fabrica.

Realmente las posibles constelaciones hibridas y variopintas que pueden y van a surgir con este marco regulatorio en una economía global como la nuestra, van a suponer un reto interesante a nivel contractual. Pero las historietas para no dormir las dejaremos para otro día.

“Friction by Design”

La Data Act, en un intento de virtuosismo literario con poca credibilidad práctica, afirma por activa y por pasiva ya en su primer articulado, que sus disposiciones no afectan ni al RGPD ni a la veterana Directiva ePrivacy (ePD), matizando caballerosamente que, en caso de conflicto, les cederá el paso, pues el Derecho aplicable en materia de protección de datos personales o de la intimidad deberá prevalecer. Ambas normativas disponen del mismo rango, pero están dotadas de una norma de conflicto a favor de la protección de datos. Esto implica que ambas normativas deben armonizarse en la medida de lo posible en su aplicación, y solo cuando surja una contradicción irreconciliable, no deberá aplicarse la disposición pertinente a la Data Act, parar garantizar la plena protección de los datos personales.

A tenor de lo anteriormente expuesto, la definición de ‘dato’ bajo la Data Act engloba los datos de carácter personal, quedando automática y paralelamente sujetos al régimen del RGPD. A mayor abundamiento, cuando los datos personales y los no personales de un conjunto de datos estén indisolublemente vínculos (datasets mixtos), también quedarán sujetos a la primacía del RGPD.

Esto lógicamente implica que todo tratamiento de datos personales en virtud de la Data Act deberá cumplir con el RGPD, empezando por el requisito de disponer de una base jurídica válida para el tratamiento con arreglo al Art.6 RGPD, y, cuando proceda, con una excepción del Art.9 RGPD e incluso del Art.5.3. ePD.

Sin embargo, la Data Act como tal, a diferencia de lo que hemos visto con otra normativa reciente europea, no constituye una base jurídica para el tratamiento como tal.

Es decir, el Reglamento impone a los titulares de datos la obligación de poner los datos personales a disposición de los usuarios o de los terceros elegidos por el usuario. Para eso, deberá proporcionarse el acceso a los datos personales que el titular de datos trate basándose siempre en alguna de las bases jurídicas del Art.6 RGPD.

No obstante, cuando el usuario no sea el interesado, el presente Reglamento no contiene ninguna base jurídica para que se proporcione acceso a los datos personales o estos se pongan a disposición de un tercero, y no concede ningún nuevo derecho al titular de datos a utilizar los datos personales generados por el uso de un producto conectado o de un servicio relacionado.

Llegados a este punto, la Data Act, cual atleta olímpico, hace una pirueta con doble tirabuzón:

• 1er tirabuzón: semi-invirtiendo la carga de la prueba al proponer que “podría redundar en interés del usuario facilitar el cumplimiento de los requisitos establecidos en el Art.6”. Es decir, en caso de sofocos buscando una base legitimadora, se le puede pedir al usuario que colabore un poco y nos traiga de casa un consentimiento firmado bajo el brazo o, al menos, una LIA ponderada como Dios manda.
• 2o tirabuzón: luego, por si fuera poco, introduce a modo de traca la palabra mágica “anonimización” como vía de escape. Huelga recordar que la anonimización (cada más cuestionable en términos absolutos, habida cuenta de la tecnología actual) constituye un tratamiento en sí, el cual también requiere de base legal.

En conclusión: la Data Act no constituye una base jurídica ni para la recogida o generación de datos personales por parte del titular de datos, ni para proporcionar el acceso a eso datos.

-RGPD salió del chat-.

Cierto es que, antes de determinar en qué base jurídica del RGPD podemos subsumir nuestra empresa, en un contexto de cesión de datos a terceros, deberíamos evaluar detenidamente si los datos de carácter personal afectados realmente lo son, en base a la doctrina Scania y demás jurisprudencia del TJUE.

En otro orden de cosas, también cabe destacar los siguientes extremos en cuanto a la interacción con el RGPD:

• Los datos personales solo pueden ser solicitados por un responsable del tratamiento o un interesado.
• El encargado de tratamiento no es ni usuario ni titular de datos.
• Cuando el titular de datos y el usuario sean corresponsables del tratamiento, deberán determinar de mutuo acuerdo sus responsabilidades respectivas en el cumplimiento de la Data Act.
• Por otro lado, cuando el usuario sea el interesado, el derecho de acceso y el de portabilidad con base al RGPD no se ve afectado por la Data Act. Cuando la parte solicitante (usuario) de los datos es también el interesado, la base jurídica del Art.6 RGPD no suele plantear problemas, pues bastaría, por ejemplo, con su consentimiento, el cual, posiblemente formaría parte implícita de la propia solicitud de acceso.
• Sin embargo, cuando el usuario no sea el interesado, sino una empresa (incluido un empresario individual), el usuario tendrá la consideración de responsable del tratamiento. Por consiguiente, dicho usuario, que como responsable desea solicitar los datos personales generados por el producto conectado, deberá tener también una base lícita del RGPD para el tratamiento, como puede ser el consentimiento del interesado, un interés legítimo o la ejecución de un contrato en el que el interesado sea parte.

Supongo que en un futuro será común que, en estos escenarios, las empresas que deseen utilizar datos personales pidan el consentimiento de los interesados, o bien recogiéndolos ellos mismos para luego adjuntarlos a la solicitud de acceso, o bien pidiéndoles directamente a los interesados que envíen ellos mismos sus consentimientos al titular de los datos.

En otro orden de cosas, en cuanto a la aplicación y ejecución de ambos reglamentos se refiere, la Data Act establece que cada Estado miembro designará a una (o varias) autoridad nacional competente para garantizar la aplicación y ejecución del Reglamento. Sin embargo, también establece, que las autoridades de control responsables de supervisar el RGPD, tendrán la responsabilidad de supervisar también la Data Act en todo lo que respecta a la protección de datos personales.

En caso de designar una autoridad de control para la Data Act que no sea la propia autoridad responsable del RGPD, quedará por ver como se garantiza una supervisión homogénea y coordinada, sin que termine siendo un lastre técnico y burocrático para el afectado que se atreva a hacer valer sus derechos.

Y todo esto… ¿para qué?

Como sucintamente nombrado al inicio del post, la idea final es que este nuevo marco regulatorio, aparte de conllevar una democratización de los datos al permitir un acceso más justo y equitativo, elimine los obstáculos del intercambio de datos, los silos, cuellos de botella, desde un punto de vista técnico y contractual, sin abuso de desequilibrios, produciéndose un auténtico incremento de la competitividad y la innovación, impulsando el desarrollo de nuevos modelos de negocios basados en la reutilización de esos datos para nuevos fines y de modo ilimitado, sin pérdida de calidad ni de cantidad.

Así las cosas, más allá de teorías y objetivos nobles, ahora tocará esperar a que la realidad se imponga y nos muestre si este paso pionero que hemos dado a nivel europeo ha sido un acierto, o por el contrario, hemos acabado exponiendo y regalando a nuestros competidores el “know-how” que nutre nuestro tejido industrial, ahogados en un laberinto de solicitudes y protocolos.

Sergi Ariño Mayans

Abogado

La entrada La Data Act ya está aquí… y el silencio es ensordecedor se publicó primero en Citizen8.

¿En qué consiste el “localhost tracking”?

A continuación, una explicación simplificada de un proceso muy técnico que se explica de una forma rigurosa en la web montada por los investigadores que han descubierto la última gran patada de Meta al RGPD en particular y otras normativas en general, como veremos..

Hay que reconocer que son ingeniosos. Ingeniosos rollo romper (otra vez) el record de sanción en materia de privacidad, pero ¡OYE!… ingeniosos.

Este es el proceso a través del cual Meta (Facebook/Instagram) lograba vincular lo que haces en tu navegador (por ejemplo, visitar un periódico o una tienda online) con tu identidad real (tu cuenta de Facebook o Instagram), aunque nunca hayas iniciado sesión en el navegador con tu cuenta ni nada por el estilo.

Meta lo consigue a través de dos canales que tú no ves y que se intercambian información:

(i) La app de Facebook o Instagram que funciona en segundo plano en tu teléfono aunque no la estés utilizando.

(ii) Los scripts de rastreo de Meta (la ideaca ilegal descubierta la semana pasada y retirada inmediatamente por Meta), que operan dentro del navegador web en tu móvil.

Sólo para ingenieros de teleco: a continuación el resumen riguroso de los grandes seres humanos que han revelado este escándalo: Tim Vlummens, Narseo Vallina-Rodriguez, Nipuna Weerasekara, Gunes Acar y Aniketh Girish.

Resto del mundo, saltad al siguiente titular, en el que iré explicando paso a paso.

“El usuario abre la aplicación nativa de Facebook o Instagram, que eventualmente se envía al segundo plano y crea un servicio en segundo plano para escuchar tráfico entrante en un puerto TCP (12387 o 12388) y un puerto UDP (el primer puerto libre entre 12580 y 12585). Los usuarios deben haber iniciado sesión con sus credenciales en las aplicaciones.

El usuario abre su navegador y visita un sitio web que integra el píxel de Meta.

En esta etapa, los sitios web pueden solicitar consentimiento dependiendo de la ubicación del sitio web y del visitante.

El script del píxel de Meta envía la cookie _fbp a la aplicación nativa de Instagram o Facebook a través de WebRTC (STUN) mediante modificación del SDP (SDP Munging).

El script del píxel de Meta también envía el valor de _fbp en una solicitud a https://www.facebook.com/tr junto con otros parámetros como la URL de la página (dl), los metadatos del sitio web y del navegador, y el tipo de evento (ev) (por ejemplo, PageView, AddToCart, Donate, Purchase).

Las aplicaciones de Facebook o Instagram reciben la cookie _fbp del JavaScript del píxel de Meta que se ejecuta en el navegador. Las aplicaciones transmiten _fbp como una mutación GraphQL a (https://graph[.]facebook[.]com/graphql) junto con otros identificadores persistentes del usuario, vinculando la ID fbp del usuario (visita web) con su cuenta de Facebook o Instagram.”

Te lo explico paso a paso, como si fueras Denzel Washington en Philadelphia

Si lo he entendido yo, tú también puedes, créeme.

1: La app instala un “interfono” oculto

«El usuario abre la aplicación nativa de Facebook o Instagram, que eventualmente se envía al segundo plano y crea un servicio en segundo plano para escuchar tráfico entrante en un puerto TCP (12387 o 12388) y un puerto UDP (el primer puerto libre entre 12580 y 12585). Los usuarios deben haber iniciado sesión con sus credenciales en las aplicaciones.”

Traducción

Abres la app de Facebook o Instagram normalmente.

Luego te vas a hacer otra cosa en el teléfono (la app queda en segundo plano).

Sin avisarte, la app sigue funcionando en segundo plano y “escucha” tráfico como si te hubieran puesto un micro escuchando llamadas internas.

Técnicamente, lo hace abriendo “puertos” de red locales (como pequeñas puertas internas en tu teléfono) en los que puede recibir mensajes.

Es importante matizar que esto sólo pasa si ya has iniciado sesión en esas apps con tu cuenta.

2: Piensas, “uhm, se ha quedado buen día para ver mi *guilty pleasure web* en modo anónimo”.

(Inserta aquí tu mierda ultraprivada favorita: vamos a decir que la mía son los vídeos de sexadores de pollos haciendo lo suyo. Es un decir).

» El usuario abre su navegador y visita un sitio web que integra el píxel de Meta.»

Abres Chrome, Firefox o cualquier navegador en el mismo teléfono.

Activas VPN y modo anónimo y, confiado como un gilipollas, te metes derecho en esa web, que casualmente, tiene incrustado un “Meta Pixel”.

Este pixel, con tu consentimiento, recoge información de tus acciones (visitas, clics, compras…) y la envía a Meta.

Lo que se ha demostrado es que, antes de que tuvieras siquiera la ocasión de consentir, el pixel inicia este proceso de localhost tracking que estamos explicando.

Teóricamente esto tendría que ir explicado al pedirte el consentimiento a cookies. Obviamente no se explicaba porque era manifiestamente ilegal.

Quicir, aunque hubieras clickado el botón de consent en la web de sexadores de pollos, ese consentimiento no puede cubrir aquello de lo que no te han informado (ten en cuenta que esta mierda ha sorprendido hasta a Google).

3: El pixel de la web habla con la app de Facebook/Instagram usando WebRTC

» El script del píxel de Meta envía la cookie _fbp a la aplicación nativa de Instagram o Facebook a través de WebRTC (STUN) mediante modificación del SDP (SDP Munging)”

Perdón… ¿Cuálo?

El script del Pixel desde el navegador, intenta enviar información a la app de Facebook / Instagram que está “escuchando” en segundo plano.

Usa una técnica llamada WebRTC, que normalmente se usa para llamadas de voz o vídeo (como Zoom o Google Meet), pero que aquí se está utilizando para enviar datos de forma encubierta entre el navegador y la app.

Además, un truquito técnico llamado “SDP Munging” le permite al navegador escribir datos (como el identificador de la cookie _fbp) dentro del «mensaje de inicio» de WebRTC.

Así, el _fbp (una cookie temporal que se anuncia como efímera, específica de tu sesión de navegación en la web) llega directamente a la app nativa que está a la escucha. En otras palabras, la web que no quieres que nadie sepa que has visitado, le acaba de pasar a tu app de Facebook / Instagram tu cookie de identificación. Esto es todavía un chorizo alfanumérico.

Pero ese chorizo alfanumérico, chavalín, eres tú.

El sistema Android tiene un montón de cosas criticables, pero -en lo que ahora interesa- está específicamente diseñado para que las apps no puedan hacer esto, para que no puedan escuchar puertos locales como localhost.

4: El mismo pixel de tu web favorito, ni corto ni perezoso, envía tu chorizo alfanumérico por internet a los servidores de Meta

» El script del píxel de Meta también envía el valor de _fbp en una solicitud a https://www.facebook.com/tr junto con otros parámetros como la URL de la página (dl), los metadatos del sitio web y del navegador, y el tipo de evento (ev) (por ejemplo, PageView, AddToCart, Donate, Purchase)”

¿GUAT?

Al mismo tiempo, el pixel envía la misma información (la cookie _fbp) a los servidores de Meta por internet, junto con:

• La URL que estás visitando
• Tu navegador y sistema operativo
• El tipo de evento realizado (ej. “página vista”, “añadir al carrito” o, en el caso de lo de los sexadores, mejor no saber, creedme).

Es como si el Pixel enviara la misma carta por dos caminos: (a) Al servidor de Facebook directamente y (b) a la app de Facebook dentro de tu teléfono.

5: La app recibe el mensaje y lo une con tu identidad real

«Las aplicaciones de Facebook o Instagram reciben la cookie _fbp del JavaScript del píxel de Meta que se ejecuta en el navegador. Las aplicaciones transmiten _fbp como una mutación GraphQL a (https://graph[.]facebook[.]com/graphql) junto con otros identificadores persistentes del usuario, vinculando la ID fbp del usuario (visita web) con su cuenta de Facebook o Instagram.»

En cristiano

La app, al recibir ese identificador _fbp, lo empaqueta con tu cuenta real (la que tienes abierta en la app).

Luego, también envían todo junto a los servidores de Meta, donde ahora ya pueden decir:

“Ajajá, este identificador _fbp (de la discutible web que acabas de visitar) pertenece a Jorge García Herrero, usuario de Instagram.”

¿Sexadores de pollos? ¿Seriously Calvo?”

Y así vinculan tu actividad web (navegador) con tu identidad real (cuenta) aunque nunca hayas iniciado sesión en el navegador ni les hayas dado tu consentimiento explícito para ello.

¿Por qué es tan grave?

Meta ha utilizado una vía técnica que los sistemas de protección de privacidad no anticipaban, y que de hecho, estaban pensados para evitar.

Meta conseguía hacer esto incluso cuando:

• No utilizas la app (pero la has dejado abierto con la sesión iniciada).
• No has iniciado sesión en el navegador.
• Estás navegando en modo incógnito.
• Usas VPN.
• Borras cookies al terminar cada sesión.

Meta, una vez más, se ha pasado por el arco del triunfo la necesidad de obtener un consentimiento informado de sus usuarios para recabar y combinar su información personal obtenida de distintas fuentes.

La escala es masiva

El 22% de las webs más visitadas del mundo están afectadas. En Estados Unidos, 17,223 sitios con Meta Pixel y 1,312 con Yandex Metrica inician este tracking **sin consentimiento del usuario**. Durante 8 años (Yandex) y al menos 9 meses (Meta), miles de millones de usuarios fueron rastreados sin su conocimiento.

Los datos capturados incluyen:

– Historial completo de navegación con URLs específicas

– Productos añadidos al carrito y compras realizadas

– Registros en sitios web y formularios completados

– Patrones de comportamiento temporal a través de distintas webs y apps.

– Vinculación directa con identidades reales de redes sociales

No estás afectado:

• Si accedes a Facebook e Instagram via web, sin tener instalada las apps en tu móvil.
• En tu navegación a través de ordenadores o iOS (iPhones).
• Si usabas (siempre en el móvil) el navegador Brave o el buscador DuckduckGo.

Las infracciones

Como hemos dicho al principio, Meta afronta responsabilidad simultánea en virtud de las siguientes normas, de menos a más (no incluyo la Directiva ePrivacy porque me da la risa):

.- De acuerdo con el RGPD necesita el consentimiento para tratar datos personales con la finalidad de personalizar publicidad. Además, ha incumplido el principio de minimización y el de privacidad desde el diseño. (Hasta 4% de facturación anual global).

.- El art 26 DSA prohíbe explícitamente la publicidad personalizada de acuerdo con perfiles basados en categorías especiales de datos personales (p. ej: orientación sexual, opiniones políticas, o datos de salud).

Si de las interacciones del usuario en webs y aplicaciones podían inferirse este tipo de datos (y eso se puede asegurar, dada la escala de la infracción que alcanza al 25% de las webs más visitadas a nivel mundial), la hostiaca podría alcanzar el 10% de su facturación.

El TJUE ha dejado pocas dudas sobre esto: (“Fondas” C-184/20 y Bundeskartellamt).

META fue declarada VLOP en febrero de 2024 y ya estaba siendo investigada por otras infracciones en materia de transparencia en moderación de contenido, protección de menores, y gestión de riesgo para la integridad de procesos electorales.

.- La más jugosa: El art 5.2 de la DMA prohíbe específicamente combinar datos personales entre servicios principales de la plataforma sin obtener un consentimiento explícito del usuario de acuerdo con los requisitos del RGPD.

El localhost tracking combina datos entre, como mínimo, Facebook, Instagram y podría hacerlo también con WhatsApp, y Messenger.

La DMA presenta el mayor riesgo financiero con multas de hasta 10% de facturación global (€16.4 mil millones), escalando hasta un estupendísimo 20% para infracciones repetidas.

Meta fue designada gatekeeper en septiembre del 2023, y ya recibió su primera multa por infringir la DMA en abril 2025: 200 millones de floros por su modelo «pagar o consentir».

Meta dirá, sin ninguna duda, que ya tenía el consentimiento del usuario para hacer esto, pero… ¿saben qué? Lo cierto es que necesitaba obtener tres consentimientos específicos para tratar datos (RGPD), acceder al dispositivo (ePrivacy) y combinar perfiles entre servicios (DMA) y sólo pidió uno y encima con una alternativa que obligaba al usuario a pagar (“pay or okay”).

Lamentablemente, la última gran sanción de Meta ha sido precisamente por su “pay or okay”.

Las sanciones

RGPD, DMA y DSA protegen bienes jurídicos diferentes, así que las sanciones previstas en cada una se pueden imponer de forma conjunta.

El riesgo teórico máximo combinado alcanza aproximadamente 32 mil millones (4% + 6% + 10% de la facturación global anual de Meta, que supera los 164 mil millones).

Nunca se han aplicado antes multas máximas simultaneas, pero alguien podría decir que estos bastardos se lo merecen.

Varios factores juegan a favor de sentar ese precedente: el histórico de infracciones (Meta tiene el récord de multas RGPD en Europa), la falta de cooperación con las investigaciones de las autoridades, el impacto sistémico de la ideaca dado su dominio del mercado, y la intencionalidad de saltarse cualquier protección técnica y/o legal dispuesta a favor de sus usuarios.

Jorge García Herrero

Delegado de Protección de Datos

La entrada El “localhost tracking” puede costar a Meta 32 mil millones. Te lo explicamos se publicó primero en Citizen8.

Below is a simplified explanation of a very technical process, rigorously detailed on the website set up by the researchers who uncovered Meta’s latest major blow to the GDPR specifically, and to other regulations more broadly, as we’ll see.

Credit where it’s due — it’s ingenious. Ingenious in the sense of breaking (yet again) the record for a privacy-related fine, but hey!… ingenious.

This is the process through which Meta (Facebook/Instagram) managed to link what you do in your browser (for example, visiting a news site or an online store) with your real identity (your Facebook or Instagram account), even if you never logged into your account through the browser or anything like that.

Meta accomplishes this through two invisible channels that exchange information:

(i) The Facebook or Instagram app running in the background on your phone, even when you’re not using it.

(ii) Meta’s tracking scripts (the now-pulled illegal brainchild uncovered last week), which operate inside your mobile web browser.

Thanks to the outstanding human beings who revealed this scandal: Tim Vlummens, Narseo Vallina-Rodriguez, Nipuna Weerasekara, Gunes Acar, and Aniketh Girish.

The entire flow of the _fbp cookie from web to native and the server is as follows:

1. The user opens the native Facebook or Instagram app, which eventually is sent to the background and creates a background service to listen for incoming traffic on a TCP port (12387 or 12388) and a UDP port (the first unoccupied port in 12580-12585). Users must be logged-in with their credentials on the apps.
2. The user opens their browser and visits a website integrating the Meta Pixel.
3. At this stage, websites may ask for consent depending on the website’s and visitor’s locations.
4. The Meta Pixel script sends the _fbp cookie to the native Instagram or Facebook app via WebRTC (STUN) SDP Munging.
5. The Meta Pixel script also sends the _fbp value in a request to https://www.facebook.com/tr along with other parameters such as page URL (dl), website and browser metadata, and the event type (ev) (e.g., PageView, AddToCart, Donate, Purchase).
6. The Facebook or Instagram apps receive the _fbp cookie from the Meta Pixel JavaScript running on the browser. The apps transmit _fbp as a GraphQL mutation to (https://graph[.]facebook[.]com/graphql) along with other persistent user identifiers, linking users’ fbp ID (web visit) with their Facebook or Instagram account.

I’ll explain it step by step, like you’re Denzel Washington in Philadelphia

If I understood it, you can too — trust me.

Step 1: The app installs a hidden «intercom»

“The user opens the native Facebook or Instagram app, which eventually goes into the background and creates a background service to listen for incoming traffic on a TCP port (12387 or 12388) and a UDP port (the first free port between 12580 and 12585). Users must have logged in with their credentials in the apps.”

Translation:

You open the Facebook or Instagram app like normal.

Then you go do something else on your phone (the app remains running in the background).

Without telling you, the app keeps running and “listens” for traffic — like having a hidden microphone eavesdropping on internal calls.

Technically, it does this by opening local network “ports” (like little internal doors in your phone) through which it can receive messages.

It’s important to clarify that this only happens if you’ve already logged into those apps with your account.

Step 2: You think, “hmm, nice day to check out my guilty pleasure website in incognito mode.”

(Insert your favorite ultra-private vice here — let’s say mine is watching chick sexers doing their thing. Just saying.)

“The user opens their browser and visits a website that integrates Meta’s Pixel.”

You open Chrome, Firefox, or any browser on the same phone.

You turn on VPN and incognito mode and, confidently like a fool, head straight to that website — which, by coincidence, has a Meta Pixel embedded.

This pixel, with your consent, collects data about your actions (visits, clicks, purchases…) and sends it to Meta.

What has now been proven is that, before you even had the chance to give consent, the pixel starts the localhost tracking process we’re explaining here.

Theoretically, this should have been explained when asking for cookie consent. Obviously, it wasn’t — because it was blatantly illegal.

I mean, even if you had clicked the “consent” button on the chick sexer website, that consent can’t cover something you were never informed about (note that this trick even caught Google off guard).

Step 3: The web pixel talks to the Facebook/Instagram app using WebRTC

“The Meta Pixel script sends the _fbp cookie to the native Instagram or Facebook app via WebRTC (STUN) using SDP modification (SDP Munging).”

Excuse me… what now?

The Pixel script in your browser tries to send information to the Facebook/Instagram app that’s “listening” in the background.

It uses a technique called WebRTC, normally used for voice or video calls (like Zoom or Google Meet), but here it’s being used to secretly transmit data between the browser and the app.

Additionally, a technical trick called “SDP Munging” allows the browser to insert data (like the _fbp cookie identifier) into the WebRTC “initial handshake” message.

In this way, the _fbp (a temporary cookie supposedly limited to your current web session) is sent directly to the native app that’s listening. In other words, the website you didn’t want anyone to know you visited just passed your identification cookie to your Facebook/Instagram app. It’s still just an alphanumeric string at this point.

But that alphanumeric sausage, my friend — is you.

Android has many flaws, but in the relevant part here, it’s specifically designed to prevent apps from doing this — from listening to local ports like localhost.

Step 4: The same pixel on your favorite website, without hesitation, sends your alphanumeric sausage over the internet to Meta’s servers

“The Meta Pixel script also sends the _fbp value in a request to https://www.facebook.com/tr along with other parameters such as the page URL (dl), website and browser metadata, and the event type (ev) (e.g., PageView, AddToCart, Donate, Purchase).”

WHAT?

At the same time, the Pixel sends the same information (the _fbp cookie) to Meta’s servers over the internet, along with:

• The URL you’re visiting
• Your browser and operating system
• The type of event performed (e.g., “page view,” “add to cart” or, in the case of chick sexer videos… better not know, trust me)

It’s like the Pixel is sending the same letter through two routes:
(a) directly to Facebook’s servers, and
(b) to the Facebook app inside your phone.

Step 5: The app receives the message and links it to your real identity

“The Facebook or Instagram apps receive the _fbp cookie from the Meta Pixel JavaScript running in the browser. The apps transmit _fbp as a GraphQL mutation to (https://graph[.]facebook[.]com/graphql) along with other persistent user identifiers, linking the user’s fbp ID (web visit) with their Facebook or Instagram account.”

In plain English:

The app, upon receiving the _fbp identifier, bundles it together with your real account (the one you’re logged into in the app).

Then, it sends it all to Meta’s servers, where they can now say:

“Aha! This _fbp identifier (from that questionable website you just visited) belongs to Jorge García Herrero, Instagram user.”

“Chick sexers? Seriously, bald guy?”

And just like that, they link your web activity (browser) to your real identity (account) — even if you never logged into your account in that browser or gave any explicit consent for it.

Why this localhost tracking is so serious?

Meta has used a technical loophole that privacy protection systems didn’t anticipate — in fact, they were specifically designed to prevent it.

Meta managed to do this even when:

• You aren’t using the app (but have a session open in the background).
• You haven’t logged into your account in the browser.
• You’re browsing in incognito mode.
• You’re using a VPN.
• You delete cookies at the end of every session.

Once again, Meta has blatantly disregarded the requirement to obtain informed user consent before collecting and combining personal information from different sources.

The scale is massive

22% of the most visited websites in the world are affected. In the U.S., 17,223 sites with the Meta Pixel and 1,312 with Yandex Metrica initiated this tracking without user consent. Over 8 years (Yandex) and at least 9 months (Meta), billions of users were tracked without their knowledge.

The captured data includes:

• Complete browsing history with specific URLs
• Products added to cart and purchases made
• Registrations on websites and completed forms
• Temporal behavioral patterns across websites and apps
• Direct linking to real identities on social networks

You’re not affected if (and only if)

• You access Facebook and Instagram via the web, without having the apps installed on your phone
• You browse on desktop computers or use iOS (iPhones)
• You always used the Brave browser or the DuckDuckGo search engine on mobile

The Infringements

As stated at the beginning, Meta faces simultaneous liability under the following regulations, ranked from lesser to greater severity (not including the ePrivacy Directive — it’s a joke at this point):

• GDPR: Requires consent to process personal data for ad personalization. Meta also violated the principles of data minimization and privacy by design. (Up to 4% of global annual turnover)
• DSA (Art. 26): Explicitly prohibits personalized advertising based on profiles created from special categories of personal data (e.g., sexual orientation, political views, health data).

If such data could be inferred from users’ interactions on websites and apps (which is almost certain, given the scale of the violation — reaching 25% of the world’s most visited sites), the penalty could reach 10% of turnover.

CJEU has been clear about this one (“Fondas” C-184/20 and Bundeskartellamt).

Meta was declared a VLOP (Very Large Online Platform) in February 2024 and was already under investigation for violations involving content moderation transparency, child protection, and election integrity.

• DMA (Art. 5.2): The most damaging one: it specifically prohibits combining personal data between core platform services without the user’s explicit consent, as defined by GDPR. The localhost tracking technique combines data across at least Facebook and Instagram, and potentially WhatsApp and Messenger as well.

The DMA carries the highest financial risk — fines up to 10% of global turnover (€16.4 billion), increasing to 20% for repeat offenses.

Meta was designated a gatekeeper in September 2023 and received its first DMA fine in April 2025: €200 million for its “pay or consent” model.

Meta will undoubtedly claim it already had user consent to do this, but here’s the truth: it needed three specific consents to process the data (GDPR), access the device (ePrivacy), and combine profiles across services (DMA). It only requested one — and even that with a coercive “pay or okay” alternative.

Unfortunately, Meta’s most recent fine was precisely over its “pay or okay” approach.

The Penalties

GDPR, DMA, and DSA protect different legal rights, so the penalties under each can be imposed cumulatively.

The combined theoretical maximum risk amounts to approximately €32 billion (4% + 6% + 10% of Meta’s global annual revenue, which exceeds €164 billion).

Maximum fines have never before been applied simultaneously, but one could argue these guys have earned it.

Several factors favor setting that precedent: Meta’s long record of violations (it holds the record for GDPR fines in Europe), its lack of cooperation with regulatory investigations, the systemic impact of this scheme given its market dominance, and the clear intent to bypass all technical and legal protections established for users.

Jorge García Herrero

Data Protection Officer

La entrada “Localhost tracking” explained. It could cost Meta 32 billion. se publicó primero en Citizen8.

En Citizen, hemos hablado unas cuentas veces de IA: el 1º post grupal de pautas de uso para ChatGPT/Generativas,  el de Guillermo sobre “areneros”, el de Sara sobre la versión final del RIA, el de Jorge sobre oposición al entrenamiento de IA de META, o el de Carmen con el ejemplo algorítmico del sistema BOSCO. Con todo, no habíamos aterrizado el punto ya vigente de las finalidades prohibidas del RIA sobre uno de los “areneros” menos vigilados del momento: los micropagos en los videojuegos. Vivimos rodeados del ansia viva de un sector que cada vez tiene menos freno: jugadores que pasan de leer, desarrollos cada vez más caros, despidos masivos para mantener las primas y beneficios, o adopción sin pasar por legal (o pasando sin mirar mucho) de cualquier innovación que pite.

En la hegemonía actual de los juegos como servicio (“games as a services”), nos encontramos de bruces con el artículo 5.1, apartados a y b del RIA.

“(a) la comercialización, la puesta en servicio o el uso de un sistema de IA que utilice técnicas subliminales que escapen a la conciencia de una persona o técnicas deliberadamente manipuladoras o engañosas, con el objetivo o el efecto de distorsionar materialmente el comportamiento de una persona o de un grupo de personas, mermando de forma apreciable su capacidad de tomar una decisión con conocimiento de causa, haciéndoles tomar una decisión que de otro modo no habrían tomado, de forma que causen o sea razonablemente probable que causen a esa persona, a otra persona o a un grupo de personas un daño significativo;”

“(b) la comercialización, la puesta en servicio o el uso de un sistema de IA que explote cualquiera de las vulnerabilidades de una persona física o de un grupo específico de personas debido a su edad, discapacidad o una situación social o económica específica, con el objetivo, o el efecto, de distorsionar materialmente el comportamiento de esa persona o de una persona perteneciente a ese grupo de manera que cause o sea razonablemente probable que cause a esa persona o a otra un daño significativo;”

¿El literal de cada apartado recuerda a alguna cosa que se ve/sufre en los videojuegos más conocidos? ¿Recuerda muy mucho a gastar irreflexivamente cantidades importantes de dinero en loot boxes, sobres, bailes, skins y demás objetos digitales in-game  a “bajo precio”? Con estos recuerdos de Vietnam, vamos a jugar en este artículo. Vamos a intentar aterrizar el RIA sobre los micropagos, vía psicología aplicada.

Técnicas subliminales, manipuladoras, vulnerabilidades y efectos significativos

Partiendo de la presunción iuris tantum de que del otro lado de la pantalla esté alguien de la hermandad jurídica (necesaria para entender el latinismo usado), podemos prescindir de las definiciones de IA y de algoritmo que todos controlamos más o menos. Y así ahorramos palabras, que no se viene un artículo precisamente corto. Al final, es el tema de moda sobre el que todos estamos intentando retener conocimiento al estilo de aquel niño chino que “absorbe el libro”.

De lo que es mejor no prescindir para nada, es de definir los elementos clave de estos dos apartados del 5.1 del RIA. Al igual que el GT29 nos dio las directrices sobre decisiones automatizadas que aterrizan los conceptos de decisión, perfilado, efectos jurídicos o significativamente similares (tampoco en el RGPD había maticez que se pillaban bien); la Comisión Europea ha sacado el borrador de las directrices sobre finalidades prohibidas del RIA (efectos secundarios de su aplicabilidad desde el 2 de febrero).

• Técnicas subliminales: no se definen en el articulado del RIA, pero la Comisión Europea lo aterriza, vía lo dispuesto en el Considerando 29: “capaces de influir en el comportamiento de forma que la persona no sea consciente de dicha influencia, de cómo funciona o de sus efectos sobre la toma de decisiones o la formación de valores y opiniones de la persona. Básicamente, provocar una respuesta inconsciente en el cerebro para que hagamos, demos o digamos lo que quiera el que lo dispuso. Aquí sería el pasar por caja, pero el ejemplo más clásico es de las imágenes intercaladas en un vídeo para que lo captes de manera subconsciente.
• Técnicas deliberadamente manipuladoras o engañosas: tampoco se definen a nivel del RIA, pero podríamos decir que serían todas aquellas encaminadas a intentar confundirnos con tácticas no tan extremas como las subliminales. A efectos, los patrones oscuros, engañosos y adictivos que todos sufrimos. Donde juegan los GAFAM continuamente, y el tipo principal del que vamos a hablar luego. Bueno, hablaremos del subtipo interesante de “patrón adictivo”.
• Distorsión material del comportamiento y efectos significativos: muy en la línea de lo que ya se necesita justificar en las decisiones totalmente automatizadas. En este caso, el perjuicio ocasional de que realices un gasto no previsto/decidido por una técnica subliminal o manipuladora. Nos quedaría colgando el punto de la vulnerabilidad, pero tampoco es algo distinto a lo que ya se tenía que valorar por protección de datos (sobre lo que la ICO ha desarrollado más en guías enfocadas). Lo bueno para nuestro caso, es que la Comisión aprovecha para incluirlo en uno de los pocos ejemplos sobre videojuegos que da en este documento:

“Un juego utiliza IA para analizar el comportamiento y las preferencias individuales de los niños, a partir de las cuales crea recompensas personalizadas e impredecibles mediante programas de refuerzo adictivos y bucles dopaminérgicos para fomentar el juego excesivo y el uso compulsivo. El juego está diseñado para ser altamente adictivo, explotando las vulnerabilidades inherentes a los niños, incluida su limitada capacidad para comprender las consecuencias a largo plazo, su susceptibilidad a la presión, su falta de autocontrol y su inclinación hacia la gratificación instantánea.  

Las consecuencias de esta explotación posibilitada por la IA pueden ser graves y duraderas para los niños, incluyendo un comportamiento potencialmente aditivo, problemas de salud física debidos a la falta de ejercicio y sueño, deterioro de la vista, problemas de concentración y capacidades cognitivas reducidas, bajo rendimiento académico y dificultades sociales. Puede repercutir significativamente en el desarrollo y el bienestar del niño, con posibles consecuencias a largo plazo que pueden extenderse también a la edad adulta.”

Y nunca hay que olvidar el punto de que la finalidad prohibida venga sin que se busque en origen. La típica de que el sistema la líe por el data set de base aportado, o por los mil sesgos aprendidos porque patata. Aquel algoritmo de Amazon para contratar que discriminabas a las mujeres por el histórico de mayoría de hombres contratados para perfil técnico.

Teoría de la autodeterminación y juegos como servicio

¿Cómo se consiguen aterrizar en el mundo real del videojuego (o lo que sea) estas técnicas que distorsionan sin conocimiento/control pleno tus acciones? Como casi todo en este mundo: a través de la psicología aplicada.

En 2025 nos creemos que se inventan muchas cosas, pero la mayor parte de veces son vueltas de tuerca de conceptos o actuaciones más viejas que una Secuoya. La diferencia estriba en la palabrería marketiniana y en la fanfarria de lucecitas digitales. Toda la vida la publicidad ha intentado “pulsarnos las inquietudes y las pasiones”, pero el mundo digital es el que ha conseguido llevarlo al summum de la inmediatez y del consumismo acelerado. La omnipresencia bolsillesca del móvil no es inocua para nadie.

Un videojuego, como casi cualquier otro producto o servicio, necesita ser atractivo para el público objetivo. A todos nos suena la famosa teoría del juego que se aplica a las tragaperras para que nunca te vayas ni seas consciente del despilfarro, pero no tanto la “teoría de la autodeterminación”, aka cubrir las necesidades psicológicas básicas de todo ser humano:

• Autonomía: esa necesidad de libre albedrío y de que tú seas el dueño absoluto de tus acciones. En los videojuegos se fuerza con las mil misiones que sólo puedes hacer tú como el héroe inigualable que eres.
• Socialización: esa caprichosa necesidad de los animales gregarios de vivir en la manada que es la sociedad. El ser parte de algo más grande que tú mismo. En los videojuegos se fuerza con recompensas que sólo puedes conseguir con cooperación con otros jugadores. También con falsa cooperación (el dar vidas a amigos que “haces” de la lista que te doy para ello del Candy Crush), pero queda más claro con el 1º ejemplo de juego tipo Destiny o «mazmorras para varios jugadores».
• Dominio: esa necesidad de creer que siempre mejoras en lo que haces o en lo que te gusta hacer. Los videojuegos lo aterrizan con niveles, mejoras y “dificultad dinámica” (luego hablamos de ello).

Todo videojuego que se precie de serlo, busca el equilibro entre estas tres pautas. Por no enrollarnos más de lo necesario, tendríamos tres fases o hitos cronológicos de aplicación/mal uso de esta base psicológica para hacer dinero:

– Juegos como producto: aquella época maravillosa hasta el advenimiento de las plataformas y apps/launchers en la que el dinero venía de hacer y vender juegos + posibles expansiones de contenido. El marketing estaba en forma de anuncios que serían muy discutibles legalmente por el tono y por dirigirse a menores a saco, pero que nos respetaba sin “publicidad dirigida”.  Nos respetaban porque era “dirigida” a que te tomaras el tiempo y el esfuerzo en rellenarlo, revisarlo y enviarlo por correo (postal, claro). Un consentimiento libre de verdad.

– Juegos como servicio: con la estandarización de las bibliotecas de juegos unidas a un perfil/cuenta de usuario, llegó la posibilidad de hacer la publicidad dirigida, programática y cansina vía cookies y tecnologías equivalentes que seguimos sufriendo. Todo a lo que juegues, mires y compres se va a analizar y parametrizar para proponerte comprar cositas que saben que te interesan más de lo que quieres reconocer. No se cumple con todo lo que se debería en lo legal, pero no es nada nuevo que no pase en los mil servicios, app y lo que sea. Ojalá se hubieran quedado aquí.

– Juegos como servicio en el último círculo del infierno: una de las peores cosas que han demostrado juegos como Fornite o Candy Crush, es que se puede estirar el chicle de un juego sacando contenido cosmético o potenciadores in aeternum. Los famosos “free to play”, “freemium”, “Pay to Win”, “Pay to Progress” o “Pay to Fast”.

¿Ejemplos? Casi todo lo multijugador de gran presupuesto a lo que juegan los mayores y los menores (puedan por edad recomendada o no): Fornite, Candy Crush, Clash Royale, Call of Duty Warzone, Geshin Impact, World of Tanks, World of Warships, League of Legends, Counter Strike, Apex Legends, Marvel Snap, Valorant, FIFA Ultimate Team o Roblox.

Micropagos y loot boxes

¿Qué contenidos o potenciadores se ofrecen para reducir nuestra cartera? Podemos hacer dos tipos de microtransacciones (por no utilizar el mismo concepto de micropago para todo): micropagos y loot boxes.

– Micropagos: se suelen entender como un concepto único, pero si nos ponemos algo pejigueros tiene subtipos:

• Objetos cosméticos: aquellos que únicamente alteran la estética del personaje, apariencia del arma, interfaz de juego, narración de voz, animaciones de victoria, bailes y todo lo que no suponga una ventaja frente a jugadores. Lo más conocidos son los emotes de Fornite y las skins.
• Potenciadores: aquellos que sí otorgan ventajas en el juego, ya sean en la propia partida o para agilizar el progreso en el mismo. Candy Crush juega fuerte a este tipo de micropago.
• Conversiones a dinero del juego: aunque no parezca un micropago como tal, lo es en el sentido de actuar como casa de cambio de moneda con a interés fijo. Moneda real en moneda del juego que no puede volverse a convertir en dinero de curso legal. Y con el punto de que los precios se ajustan para obligarte a pasar a convertir varias veces: justito te falta un poco para lo que quieres, pero acabas con un excedente de moneda de juego que inconscientemente ya estás pensando en qué más gastarlo.
• Downloable Content o DLC: los más viejos del libro. Contenido jugable del propio juego: mayor extensión, duración o profundidad que los anteriores. Se pervierte mucho este tipo en la actualidad, pero debería ser la típica expansión del modo historia o un contenido majo con fondo de bastantes personas jugables nuevos.
• Pago con anuncios: el que no se considera como tal por no saca dinero de manera directa del jugador, pero que lo es por “obligarte” a ver el vídeo para obtener la recompensar. El micropago que honra la legendaria cita de: “Si no pagas por el producto, entonces tú eres el producto”.

– Cajas de botín o “Loot Boxes”

El tipo de microtransacción que se hizo tan conocido y odiado no hace tanto tiempo. Nuestro extinto Ministerio de Consumo lo intentó regular de una manera tan atroz que se quedó durmiendo el sueño de los justos como anteproyecto en 2022. En Europa empezaron a pintar bastos cuando las autoridades de países como Bélgica y Holanda las consideraron juego regulado que debía cumplir con esta normativa tan restrictiva y específico. Poca broma con la obligación de autorización administrativa previa, registro de jugadores a los que prohibir el acceso, o registro de familiares de empleados para evitar amaños……

Hubo debate jurídico sobre si cumplía los tres elementos del concepto de “juego” de la ley pero ahí se quedó. Se decía que no encajaba porque aquí no se arriesgaba cantidades de dinero por siempre tocar algo, pero lo cierto es que mucho de lo que toca carece de valor real para el jugador. El punto más puñetero era de la trasmisibilidad entre participantes que encaja muy bien en el póker, pero aquí haría una buena parte de loot boxes se quedarán fuera.

Las particularidades de este tipo de microtransacciones: aleatoriedad algorítmica o “probabilidad, segregación de objetos por calidad e incentivos sonoros y visuales. Siendo independiente de si permiten o no el intercambio de lo obtenido entre cuentas de varios jugadores.

Este tipo concreto de microtransacciones se popularizó más de lo debido por los cientos de influencers de alto copete grabándose abriendo cajas, sobres y +. De manera patrocinada, sin que ellos perdieran ni un chavo y con alguna sospecha de manipulación algorítmica para que parezca que toca más de lo toca. Al fin y al cabo, la gente que ve este tipo de contenido son potenciales compradores a captar.

Aunque ya están de capa caída, en el proyecto de «Ley Orgánica para la protección de las personas menores de edad en los entornos digitales» (ya en tramitación parlamentaria) tenemos rescatado el concepto. El legislador nunca supo bien qué hacer, pero mantiene el intento miope de Garzón de no darse cuenta que todos los micropagos juegan a lo mismo. ¿Tiene sentido penalizar a un Clash Royale y dejar vivo sin mácula a un Candy Crush? ¿Conseguimos mayor protección para el menor si todos se pasan al modelo micropago manipulador no aleatorio para esquivar el grano de arena regulado? ¿No es bajarse los pantalones hasta los tobillos añadir la coletilla siguiente? : “En su caso, reglamentariamente podrán determinarse los supuestos excepcionales en los que podrá flexibilizarse dicha prohibición, siempre garantizando el principio de protección a la infancia que inspira esta Ley.”. Artículo 5 del proyecto.

Patrones adictivos

¿Qué tipo de acciones concretas basadas en esa psicología aplicada existen para lograr la manipulación subliminal?  Patrones oscuros del subtipo de adictivos.  

A casi todo el mundo le suena el concepto de patrón oscuro, “dark pattern”, “deceptive pattern” o “patrón engañoso”. Sea por la definición y enfoque original de Harry Brignull, o por las variaciones que se han ido haciendo.

El EDPB en sus directrices sobre targeting en redes sociales (mareando más de lo que debería por no mantener los denominativos originales más estandarizados). O los más clásicos: preguntas trampa, sneak into the basket, roach motel, privacy zuckering (ese Zuckerberg, sí), confirmshaming, bait and switch, nudge techniques o continuidad forzada (Mil ejemplos en la página del bueno de Harry Brignull).

Estos patrones que consiguen aterrizar esa psicología aplicada que comentaba al principio para que acabes haciendo/dando/comprando lo que quieren sin que seas consciente de que no ha sido tu decisión real, son el genérico. Para lo que no interesa aquí y ahora, tenemos el subtipo de patrón adictivo que hace más hincapié en el punto de gasto irreflexivo.

Tenemos la suerte de que la AEPD se atreviera a hacerse un informe sobre los mismos (Patrones adictivos en el tratamiento de datos personales Implicaciones para la protección de datos). Y todavía más afortunados por el hecho de que han aterrizado con bastante tino los más conocidos en el mundo de los videojuegos.  Nos quedamos con 6 + 1 ejemplo más novelado de “continuidad forzada del tipo de temporizador”:

“Imaginemos un videojuego de fantasía. El jugador quiere forjar una espada legendaria y el juego le permite crearla, pero esta tarea tardará 4 horas en completarse. El jugador no puede acelerar el proceso; sólo esperar.

Durante estas 4 horas, el jugador se mantiene conectado al juego. Puede que se esté ejecutando en segundo plano, pero es probable que el jugador realice comprobaciones periódicas del progreso del proceso. El jugador necesitará 1 día para actualizar el castillo. Para entrenar tropas, 2 días. Y así sucesivamente para otros recursos valiosos.

Esto es eficaz porque garantiza la retención. Una vez que finalice el temporizador, los jugadores interactuarán con el juego para reclamar los resultados (la espada, el nuevo castillo, etc.). En algunos casos, este patrón permite la monetización. Por ejemplo, el jugador puede omitir el tiempo de espera usando la moneda del juego (gemas, monedas). En este caso, el patrón fomenta el compromiso.

Si los temporizadores son demasiado largos, demasiado frecuentes o están relacionados con recursos que los jugadores perciben como de “bajo valor”, estos pueden sentirse frustrados o perder el interés. Los diseñadores de juegos deben lograr un equilibrio entre la anticipación y la molestia.

Perfilan a los jugadores según sus hábitos (duración de la sesión de juego, momento de juego, frecuencia de juego, preferencias de juego, historial de gastos, etc.) para optimizar todas estas características.”

Podríamos poner mil ejemplos ilustrativos con los bailecitos/emotes de Fornite, las muy discutibles skins de Warzone de convertir armas en ¿unicornios, motos, destructores imperiales de Hacendado, barcos piratas y +? (juzguen ustedes mismos vía enlace de ejemplo), pero vamos con Candy Crush. El juego que conocen niños y mayores para conseguir una facturación desmesurada vía microcosas (propiedad de la empresa que compró Microsoft por algún susto en competencia no hace tanto: Activison-Blizzard-King).

Aplicando todo lo comentado a la “drogaína” con forma de caramelo:

• Uso de incentivos visuales y sonoros, similares a los de las máquinas recreativas y tragaperras (clara influencia de la teoría del juego) para generar esa sensación comentada de cubrir la necesidad psicológica de dominio/mejora por haber realizar un nivel entero con un único movimiento que es más cosa del juego que tuya por pericia (si no contamos lo de destacarte la mejor jugada que puedes hacer). Por ejemplo, las explosiones en pantalla de colores o los mensajes narrados o “voz en off” por movimientos del jugador “destacados”: “sweet”, “delicious” o “tasty”.
• Introducción progresiva de potenciadores comprables con moneda del juego que otorgan ventajas al jugador en partida, de manera que cada vez que se avanza sea más difícil conseguirlos sin tener que convertir dinero real en moneda del juego.
• Recompensas por todo: en el sentido de los patrones de la captura anterior de jugar con cita, dotación, grinding (se suele decir más “grindeo”, “farming” o “chino farming”), recompensa periódica o pull to refresh: por darte moneda del juego si vuelves pasado un tiempo, varias recompensas diarias, mil tareas gratuitas para que sigas en el juego, tareas gratuitas que para cobrarlas necesita gastar dinero. Este punto de recompensas por todo también hace combo con el anterior, de manera que las recompensas van siendo menores (o te renten menos) conforme vas avanzando.
• Uso de sistemas de dificultad dinámica: el punto más fino y peligroso de todos. El algoritmo modifica la dificultad de cada nivel según si te vas frustrar tanto que no te vas a ir, o si con ese punto de frustración vas a verte “obligado” a comprar algún potenciador para superarlo. Nunca reconocerán hacerlo en carne propia, pero la vida se abre camino con un mínimo de representantes públicos que sepan ir al hueso. Como ya hay perfilado del jugador, la golosina la tiene al alcance para más cosas

Punto 104 del apartado 4 del documento “Immersive and addictive technologies” elaborado por el Parlamento Británico tras las comparecencias de especialistas en la materia y representantes de la industria: “Moreover, despite concerns around gaming disorder, some parts of the games industry use data collected about players to modify their experience and keep them playing for longer. Alex Dale told us that King does not use player data to change the experience for individual users—a practice known as ‘dynamic difficulty adjustment’—however, other companies do. For example, Electronic Arts has patented systems that mean “the difficulty level of the video game may be automatically adjusted” to “keep a user engaged for a longer period of time.”

De Algoritmos y el RGPD

Del RGPD

Nunca se empieza por los principios del artículo 5, pero es el núcleo de todo. Al igual que todos los caminos conducen a Roma, todos los artículos del RGPD conducen a los grandes principios rectores. Y con el cajón de sastre que es el artículo 25 de privacidad por diseño y por defecto, volviendo a recogerlos para matizar el punto de aplicación de medidas técnicas, organizativas que los garanticen.

El principio de transparencia va al rosco de la información cero que dan, pero ¿cumpliría con el principio de lealtad?. No siempre es fácil aterrizar a elementos concretos estos principios que todos utilizamos dando por sabido lo que significan, pero vamos a tirar del bolso mágico del EDPB (Directrices 4/2019 de privacy by design y default). El de lealtad es el principio específico que determina que un dato personal no debe ser tratado de manera “injustificadamente perjudicial, ilícitamente discriminatoria, inesperada o engañosa para el interesado”. Siniestro total, pero vamos a hacer el parte del perito con varios de los elementos que el EDPB determina para que exista lealtad:

• Expectativas razonables: 10 de 10. Típico tratamiento invisible del que sólo tienes idea si lo investigas o te encuentras con un artículo de este tipo ;).
• Sin discriminación: 100 de 10. Sin comentarios.
• Sin abusos: 1.000 de 10. Nadie está intentando hacer palanca en las necesidades o vulnerabilidades de los interesados.
• Sin engaños: 10.000 de 10. ¿uso de lenguaje o diseño engañoso o manipulador?. Nunca de los jamases del País de Nunca Jamás.
• Ética y verdad: 100.000 de 10. Existe la verdad y la “verdad” + la ética del código de los piratas de Libertalia.
• Intervención humana: poca, pero la línea genérica de derecho a la intervención humana siempre está en las políticas. Se meten todos los derechos, con independencia de que apliquen o no a los tratamientos informados.
• Lealtad en el funcionamiento de los algoritmos: ∞ de 10. Si el tratamiento es tan leal que ni te lo van a decir, pues es complicado que cuente con detalle sobre cómo funciona y qué hace para no discriminarte o perjudicarte. No ayuda que la única razón del ser del asunto sea perjudicarte la cartera.

De Algoritmos

Con todo lo dicho, creo que a nadie se le escapa que este tipo de acciones estarían un poco complicadas de justificar de base. Habemus un tratamiento totalmente automatizado con efectos significativamente similares a los jurídicos. ¿Por qué? Por lo de siempre de cumplir los requisitos del 22 del RGPD:

• Existencia de una decisión sobre el jugador: el hecho de que el algoritmo, previo perfilado del jugador sobre qué compra, qué no, cómo juega y otros elementos relevantes, va a determinar qué patrones adictivos mostrar o cómo mostrarlos para maximizar que el jugador acabe picando. El dar una recompensa especial si detecta un período largo de inactividad (puede que con notificaciones vía dispositivo que sea), el no apretar en dificultar en un nivel para no provocar frustración de la mala para ellos, el subirla para ver si pica el jugador…….
• Realizada por medios totalmente automatizados y sin intervención humana: con el punto del algoritmo ya llevamos puesto el que sea automatizado, pero también el que no haya intervención humana. En un tratamiento a escala completamente global y del nivel de intensidad en los videojuegos de gran público, pues va todo en automático y con decisión aplicada en tiempo real.
• Que provoca efectos significativamente similares a los jurídicos: el punto mucho más líquido que el claro de efecto jurídico, pero que aquí lo tenemos por el hecho de que va a producir una distorsión real y significativa en el comportamiento económico del jugador. Consumo irreflexivo en el momento.

Podríamos comentar la jodida situación de sólo tener el consentimiento explicito para levantar la prohibición del 22, la PIA que en necesidad y proporcionalidad tampoco te va a salir muy allá, los derechos concretos del 22, o el punto de Schufa y sus predicciones algorítmicas y el efecto real de la misma si la respeta/es dimanante para el responsable; pero es más interesante dejar caer el tema de la información.

Hablando de un algoritmo de caja negra como la copa de un pino (lo de operar de manera opaca y no comprensible para el usuario no hace bien), es buena oportunidad para recordar la complejidad de la información del 22. No es nada nuevo que no digan las famosas directrices de decisiones automatizadas del GT29 (una de las asumidas por el EDPB), pero vamos con novedades del TJUE en forma de resolución del TJUE del 2025: C-203/22 (CK contra Dun & Bradstreet Austria GmbH y Magistrat der Stadt Wien). Sí, la ahora de moda/referencia en el tema. Y justo una en la que las cuestiones prejudiciales que le hacen hablan de algoritmos de caja negra:

La resolución tiene la importancia de que es a nivel del TJUE, pero lo más novedoso que no saliera ya en las directrices del GT29 son dos perlitas del Abogado General. Dos concretas sobre que el 15.1.h es un derecho real a que te expliques + vete mandando todo a la autoridad de control o tribunal competente, y luego ya se verá el límite de secreto empresarial y derechos de terceros que existe:

• “Por ello, como ha señalado el Abogado General en el punto 67 de sus conclusiones, procede considerar que el artículo 15, apartado 1, letra h), del RGPD ofrece al interesado un genuino derecho a una explicación sobre el funcionamiento del mecanismo aplicado en la adopción de una decisión automatizada de la que ha sido objeto y sobre el resultado al que ha llevado dicha decisión.”

Me parecen más inspirados los puntos 64 y 2ª parte del 71 del Abogado General sobre la necesidad de dar contexto inteligible y real de lo técnico para que pueda ejercerse el derecho con el conocimiento de lo que pasa que exige: “El conocimiento de este contexto por parte del interesado debe permitirle comprender el resultado al que se ha llegado mediante la decisión automatizada, al conocer los elementos esenciales del método y de los criterios utilizados. En resumen, el proceso, de carácter técnico, que ha conducido a esta decisión debe hacerse inteligible. Solo de este modo podrá el interesado ejercer los derechos que le confiere el RGPD, incluido el derecho a expresar su punto de vista sobre una decisión automatizada y a impugnarla. (…..). “En segundo lugar, esta información debe ser suficientemente completa y estar suficientemente contextualizada para permitir al interesado verificar su exactitud y si existen una coherencia y una relación de causalidad objetivamente verificables entre, por una parte, el método y los criterios utilizados y, por otra, el resultado al que ha llegado la decisión automatizada.”

• “Como ha señalado el Abogado General en el punto 94 de sus conclusiones, esta jurisprudencia es plenamente extrapolable al supuesto en el que la información que debe facilitarse al interesado en virtud del derecho de acceso garantizado por el artículo 15, apartado 1, letra h), del RGPD pueda dar lugar a una vulneración de los derechos y libertades de otros, en particular por contener datos personales de terceros protegidos por el RGPD o bien un secreto comercial, en el sentido del artículo 2, punto 1, de la Directiva 2016/943. En este supuesto también, la referida información debe comunicarse a la autoridad de control o al órgano jurisdiccional competente, a los que corresponde ponderar los derechos e intereses en cuestión para determinar el alcance del derecho de acceso del interesado a los datos personales que le conciernen.”

El resto lo podemos ejemplificar mejor con lo que dice el GT29:

• A fin de que esta información sea significativa y comprensible, deben ofrecerse ejemplos reales y tangibles del tipo de efectos posibles.

• En lugar de ofrecer una compleja explicación matemática sobre cómo funcionan los algoritmos o el aprendizaje automático, el responsable del tratamiento debe considerar la utilización de formas claras y exhaustivas de ofrecer información al interesado, por ejemplo: las categorías de datos que se han utilizado o se utilizarán en la elaboración de perfiles o el proceso de toma de decisiones; por qué estas categorías se consideran pertinentes; • cómo se elaboran los perfiles utilizados en el proceso de decisiones automatizadas, incluidas las estadísticas utilizadas en el análisis; por qué este perfil es pertinente para el proceso de decisiones automatizadas; y cómo se utiliza para una decisión relativa al interesado.

¿Algo más de la Comisión in love with AI.?

Lo divertido para el caso está al inicio del artículo. Hubiera sido muy raro dejarlo en un apartado final cuando son definiciones básicas del tema a tratar.

Aún con todo, sí se puede hacer un gran finale. La Comisión Europea se fumó alguna sustancia nociva por uno de los ejemplos sobre videojuegos que incluyen . Es cierto que se va a ello, pero ni a medio plazo me creo que comercialmente vayamos a tener nada en el mercado de este estilo. Hay prototipos y ejemplos de gente que hace pinitos con sensores de encefalograma para disparar o moverse con la “mente”, pero la batalla a corto-medio plazo va a ser el eye tracking de los casos de realidad virtual, aumentada o mixta.

Fuera de carta, tendríamos el derecho a explicación de decisiones tomadas individualmente del artículo 86 RIA, y la futura resolución del TJUE ante la 1ª cuestión prejudicial que nos viene sobre interpretación decisión automatizada sobre RIA.

Y hasta aquí llegamos. Podría incluir unas conclusiones para cerrar el artículo, pero casi es final abierto hasta que pase algo. Hemos hecho un recorrido para intentar poner en papel este tema que está ahí, pero el final ya nos lo darán escrito cuando empiecen a venir las investigaciones de autoridades, las denuncias, los cambios en los modelos para evitarlo y las sanciones.

Bueno, sí existe una conclusión importante que podemos dejar apuntada ahora: no jueguen a Candy Crush ni a ninguno de sus primos que utilizan la psicología aplicada para generar una tragaperras con forma de videojuegos. Parecen videojuegos, pero en el fondo son drogaína pura de Walter White.

La entrada ¿Qué tienen que ver las finalidades prohibidas del RIA con los micropagos? se publicó primero en Citizen8.

Propuesto por la Comisión en mayo de 2022, representa el último hito del paquete legislativo que prometía traer consigo la Estrategia Europea de Datos (Reglamento de Datos y Reglamento de Gobernanza de Datos). Además, supone el lanzamiento oficial del que será ya el primero de los nueve espacios europeos de datos en sectores estratégicos y ámbitos de interés público.

Por si la frenética actividad legislativa y regulatoria europea hubiera podido pillar a alguien con el pie cambiado (algo que, para nada acontece en los últimos tiempos) os contamos a continuación cuáles son las cinco claves del REEDS y cómo y porqué puede revolucionar el sector de la asistencia sanitaria y la salud digital en toda la Unión Europea. Para que el pie cambiado no se convierta en traspiés.

Objetivos y estructura

El Reglamento tiene por objeto establecer un conjunto de reglas, normas e infraestructuras que, bajo un marco de gobernanza común para todos los intervinientes, facilite y promueva el uso primario y el uso secundario de los datos de salud electrónicos. Se compone de un total de 105 artículos, acompañado por sus nada desdeñables 115 considerandos y estructurado en tres ejes u objetivos esenciales:

1. Usos primarios: Mejorar el acceso por parte de las personas físicas a sus datos de salud electrónicos y el control de dichos datos en el contexto de la asistencia sanitaria (Cap. II, arts. 3 a 24).
2. Historias Clínicas Electrónicas (HCE): Establecer un marco jurídico y técnico uniformes en lo que respecta al desarrollo, comercialización y uso de sistemas de HCE y aplicaciones de bienestar (Cap. III, arts. 25 a 49).
3. Usos secundarios: Impulsar la reutilización de los datos de salud electrónicos para otros fines y usos que beneficien a la sociedad, tales como la investigación, la formulación de políticas, la preparación y respuesta ante amenazas para la salud o la medicina personalizada (Cap. IV, arts. 50 a 81). 

Como cabe apreciar, se trata de un instrumento sumamente complejo, ya no solo por la diversidad en el objeto perseguido, sino por las interacciones con otra multiplicidad de normas con las que deberá, sin duda, convivir. Por ejemplo, con el Reglamento General de Protección de Datos (ya se examinaba en otra parte algunas potenciales fricciones), el Reglamento de Gobernanza de Datos, el Reglamento de Inteligencia Artificial o el Reglamento sobre productos sanitarios para diagnósticos in vitro. Y del Reglamento de Inteligencia Artificial, tenemos otras cositas publicadas por Citizen: ¿Un arenero para jugar con la Inteligencia Artificial en España? y Opportunities and perils of the leaked AI text.

Vayan preparando, pues, los termos de café

Ámbito de aplicación

Desde el punto de vista material, el REEDS se aplica a los datos electrónicos de salud, lo que conlleva dos consecuencias. En primer lugar, quedan comprendidos tanto los datos personales como los no personales. En segundo lugar, se construye una nueva categoría amplísima («dato de salud electrónico») que no solo abarca los datos relativos a la salud y los datos genéticos según el RGPD que se traten en formato electrónico, sino que captura prácticamente cualquier tipología de datos relacionados con la salud incluyendo incluso los datos sobre factores determinantes de la salud (conductuales, medioambientales, factores sociales o educacionales, etc.).

En lo que respecta a los sujetos obligados, las previsiones del Reglamento afectan, de un modo u otro, a la práctica totalidad de los actores del sector sanitario, asistencial e investigador que, bajo la rúbrica de «tenedores de datos de salud», deberán facilitar y poner a disposición de los «usuarios de datos» sus datos de salud electrónicos. Obligación que se extiende, por lo general, a cualquier persona física o jurídica, pública, privada o entidades sin ánimo de lucro que presten servicios, desarrollen productos o servicios o realicen investigaciones en el sector sanitario o asistencial. Por ejemplo, prestadores de asistencia sanitaria públicos y privados; investigadores, centros, grupos y universidades; fabricantes, proveedores y comercializadores de sistemas de HCE y aplicaciones y dispositivos de bienestar; compañías farmacéuticas y de salud digital; registros, repositorios y biobancos. Quedan excluidos, en cambio, ciertas personas físicas (ej. investigadores individuales), las microempresas y los órganos jurisdiccionales.

Finalmente, desde el punto de vista temporal, el Reglamento entrará en vigor a los veinte días de su publicación en el Diario Oficial de la Unión Europea y será plenamente aplicable a los dos años. Es decir, el Reglamento será aplicable a partir del 26 de marzo de 2027. No obstante, debido a la complejidad (y la diversidad) de sus disposiciones y obligaciones, se prevé un período de adaptación escalonado.

Usos primarios

Los usos primarios de los datos de salud electrónicos son aquellos relacionados con la prestación de la asistencia sanitaria (evaluación, conservación o restablecimiento del estado de salud de la persona) incluyendo la receta, dispensación y provisión de medicamentos y productos sanitarios; así como los servicios sociales, administrativos y de reembolso.

El Capítulo II se abre con una enumeración exhaustiva de los derechos de las personas físicas en relación con los usos primarios, a saber:

• Derecho de acceso a las categorías mínimas de datos de salud electrónicos personales y a la obtención de una copia gratuita.
• Derecho a introducir información en su propia Historia Clínica Electrónica.
• Derecho a la portabilidad de los datos de salud electrónicos personales.
• Derecho a limitar el acceso de profesionales sanitarios y prestadores de asistencia sanitaria a la totalidad o parte de los datos de salud electrónicos personales.
• Derecho a la rectificación de los datos de salud electrónicos.
• Derecho a obtener información (quiénes, cuándo y a qué) sobre los accesos que se hayan producido a sus datos de salud electrónicos personales.
• Derecho de opt-out en relación con los usos primarios (autoexclusión de las infraestructuras y servicios de acceso electrónicos del Reglamento).

A los efectos de garantizar el acceso a los datos para usos primarios y el ejercicio efectivo de tales derechos en el conjunto de la Unión, el REEDS establece un conjunto de infraestructuras, actores y reglas comunes. Así, dispone, entre otras, la creación de un formato europeo de intercambio de historias clínicas electrónicas, la implementación de mecanismos de identificación y autenticación interoperables, el nombramiento de una o varias autoridades de salud digital en cada Estado miembro y la institución de una infraestructura y unos servicios transfronterizos (MiSalud@UE).

Historias Clínicas Electrónicas y aplicaciones de bienestar

El Capítulo III del Reglamento introduce todo un conjunto de requisitos y reglas uniformes en lo que respecta al desarrollo, la comercialización y el uso de Sistemas de HCE y aplicaciones de bienestar, incluyendo:

• Normas sobre la introducción en el mercado y puesta en servicio.
• Obligaciones de los fabricantes de Sistemas de HCE.
• Obligaciones de los importadores de Sistemas de HCE.
• Obligaciones de los distribuidores de Sistemas de HCE.
• Requisitos y especificaciones comunes para una declaración y marcado europeos de conformidad.
• Etiquetado de interoperabilidad de las aplicaciones de bienestar (wellbeing). 
• Disposiciones sobre la vigilancia del mercado y el establecimiento de un registro europeo para los sistemas de HCE y las aplicaciones de bienestar. 

Usos secundarios

Los usos secundarios de los datos de salud electrónicos son aquellos expresamente permitidos por el propio Reglamento y que son distintos de los fines iniciales para los que se recogieron o produjeron (es decir, del conjunto de fines relacionados con la prestación de la asistencia sanitaria incardinados en el uso primario). El Reglamento enumera un listado de usos secundarios permitidos (art. 53) y de usos secundarios prohibidos (art. 54).

Las personas y entidades comprendidas dentro del concepto de Tenedores de Datos de Salud quedan legalmente obligadas por el REEDS (se crea una obligación legal en el sentido del art. 6.1, letra c del RGPD) a poner a disposición ciertas categorías de datos de salud electrónicos (listadas por el art. 51) para su acceso y uso secundario por parte de los usuarios de datos que lo soliciten. Con ello, a fin de regular y gobernar esta obligación de puesta a disposición, los procedimientos de autorización y la infraestructura para el tratamiento y la concesión del acceso, el Reglamento dispone:

• La designación de uno o varios «organismos de acceso a datos de salud» por cada Estado miembro que serán responsables, entre otras funciones, de conceder el acceso a los datos de salud electrónicos para usos secundarios mediante la expedición de «permisos de datos».
• Un procedimiento administrativo (estándar / simplificado) para el acceso a datos incluyendo, entre otras, plazos de tramitación, un contenido mínimo para las solicitudes de acceso, modelos estandarizados, etc.
• Un régimen jurídico uniforme para los «permisos de datos», decisiones administrativas por las que un organismo de acceso autoriza el uso secundario y especifica las condiciones en las que se llevará a cabo, así como las garantías y salvaguardas aplicables.
• La creación de un «catálogo de conjuntos de datos» normalizado y accesible al público que contenga una descripción de los conjuntos de datos disponibles y sus características.
• La institución de una infraestructura transfronteriza para los usos secundarios (HealthData@EU) con puntos de contacto nacionales y con la posible integración como participantes autorizados de instituciones europeas, EDICs (European Digital Infrastructure Consortiums) e incluso de organismos o entes de terceros países u organizaciones internacionales.

Finalmente, al igual que ocurre con los usos primarios, se introduce un derecho de opt-out que permite a las personas físicas excluir, en cualquier momento y sin necesidad de motivación alguna, el tratamiento de sus datos de salud electrónicos personales para usos secundarios (sometido a ciertas excepciones y limitaciones).

Conclusiones

En definitiva, el Reglamento (UE) 2025/327, de 11 de febrero de 2025, relativo al Espacio Europeo de Datos de Salud  es un instrumento complejo, pero disruptivo para el sector de la salud, que anticipa transformaciones de calado en la práctica totalidad de las esferas y de los operadores jurídicos sanitarios, asistenciales, de investigación o de salud digital.

Primero, por reforzar los derechos de los pacientes y las facultades de autodeterminación informativa de las personas físicas; en lo que es un nuevo intento de situar el respeto a los valores fundacionales europeos en el núcleo del debate sobre los beneficios de la digitalización de la salud y la economía digital.

Segundo, por las obligaciones de puesta a disposición de datos para usos secundarios, el establecimiento de unos mecanismos de acceso uniformes y la creación de nuevos organismos y autoridades nacionales y transfronterizas. Ello con el afán de desplegar todo el potencial de la reutilización de los datos de salud electrónicos para el interés general bajo unas reglas de gobernanza justas que permitan salvaguardar un elevado nivel de protección de los derechos y libertades.

Por último, porque un eventual éxito del Reglamento demandará esfuerzos decisivos por parte de los Estados miembros y resto de los sujetos obligados, no solo en términos de cumplimiento normativo; también, en forma de inversiones en capacidades técnicas, operativas e infraestructura.

Mikel Recuero
Doctor en Derecho.
Abogado especializado en Protección de Datos y Derecho Digital.

La entrada Las 5 claves del nuevo Reglamento sobre el Espacio Europeo de Datos de Salud se publicó primero en Citizen8.

Antes de empezar, aprovechamos para dejar por aquí el adelanto de que en enero empezaremos una newsletter mensual muy Citizen8 mucho Citizen8. Nada de una newsletter normalita de selección de noticias, sino algo de valor añadido del tipo a lo que puedes haber leído en los post de la casa. Avisados quedáis :).

Vamos al turrón con sabor a huevo de pascua.

Tax Policy Associates invita a vino

Desde UK (Tax Policy Associates) invitan a vino si alguien se lee la política y puede demostrar ser el primero en hacerlo. Se entiende que ya no habrá vino ninguno, pero esperamos que fuera uno bueno (o, directamente, uno de Españita) para pasar el trago de ser una política escasa.

Amazon se espera un apocalipsis zombie

Los términos de Amazon Web Services (AWS) prevén que el mundo se pueda ir un poco al carajo zombie. Y en dicho caso, que podemos usar las herramientas de desarrollo y demás de Lumberyard (motor gráfico de Amazon) para hacer drones, cositas militares o control de aeronaves. Parece broma el tema motor gráfico de videojuegos para cosas militares, que la Playstation 2 tuvo restricción de venta a países tipo Libia, Irak, Irán o Corea del Norte.

Vender tu alma

La extinta Gamestation británica nos obsequiaba con la bromita de erigirse en Mefistófeles para reclamar nuestro alma inmortal si habíamos comprado el 1º del cuarto mes de 2010. Parece que era una broma del Día de los Inocentes, pero telita.

Marte, planeta libre

Elon, poniéndose el mismo sombrero que Naciones Unidas cuando se aprobó el Tratado sobre exploración y utilización del espacio ultraterrestre, nos declara en los términos de Starlink que Marte será un planeta libre no reclamable por ningún gobierno. ¿Estará pensando en la «República del Congreso de Marte (MCR)» que existía en la serie The Expanse?

Apple en contra de la energía «nucelar»

Sí, era una bromita de algo muy icónico que dice Homer. Pues eso, que Apple nos dice en sus términos que no quiere que usemos sus productos o servicios para crear armas nucleares, químicas o biológicas.

Hasta aquí. Felices fiestas, navidades y equivalencias varias para lo mismo. A turronear y salir y entrar de año lo mejor posible.

La entrada Easter Eggs: Términos y Condiciones se publicó primero en Citizen8.

Hace unos años, el Gobierno español decidió modificar las condiciones y requisitos establecidos para que las personas vulnerables recibieran un descuento en su factura de la luz. Esto llevó a la introducción de un nuevo software desarrollado por la administración pública, que las compañías eléctricas debían utilizar para determinar si un ciudadano tenía derecho a la reducción de la factura eléctrica. Este software, bautizado como BOSCO, se basaba en una norma que definía los requisitos específicos para obtener el descuento, que eran ligeramente diferentes de los que existían anteriormente. Estos cambios, unidos a la mayor complejidad que suponía el uso de BOSCO y a otros problemas burocráticos, provocaron que un gran número de personas no solicitaran la ayuda a la que tenían derecho. (Versión en inglés de este post – aquí).

Ante esta situación, Civio, una organización española dedicada a la fiscalización de organismos y administraciones públicas, en colaboración con la Comisión Nacional de los Mercados y la Competencia, creó y puso en marcha una app gratuita que permitía a las personas determinar si tenían derecho a la ayuda, además de asistirles en el proceso burocrático. Sin embargo, a través de esta aplicación, se descubrió que BOSCO estaba supuestamente evaluando incorrectamente la elegibilidad, ya que personas que cumplían los requisitos establecidos por la normativa y conforme a la aplicación Civio eran rechazadas por BOSCO.

El caso BOSCO

Para esclarecer el asunto, Civio solicitó al Ministerio, y posteriormente al Consejo de Transparencia, el acceso al código fuente de BOSCO. Sin embargo, tanto el Ministerio como el Consejo de Transparencia rechazaron su solicitud y se negaron a dar acceso al código, por lo que Civio interpuso una demanda contra esa resolución. Basándose en una serie de factores, la demanda fue desestimada y se denegó a Civio el acceso al código fuente de BOSCO. El juez esgrimió cuatro argumentos principales: en primer lugar, que BOSCO es una mera parte del procedimiento administrativo, por lo que su resultado no constituye una decisión administrativa. En segundo lugar, que la no divulgación del código hace que la aplicación sea más segura, y dado que el código no es reutilizable, por ser demasiado específico, no debe divulgarse para no poner en peligro la seguridad. En tercer lugar, que el algoritmo ya ha sido auditado y que el resultado puede cotejarse con la norma para verificar si alguien cumple los requisitos y tiene derecho a la ayuda. Y en cuarto lugar, que la seguridad pública puede verse amenazada por la divulgación del código.

Subsiguientemente, Civio impugnó esta sentencia. Entretanto, el Consejo de Transparencia se desdijo y se puso de parte de Civio, pero el Ministerio siguió oponiéndose a la demanda de respuesta de Civio. En mayo de 2024, la segunda demanda interpuesta por Civio también fue desestimada por motivos similares. 

cada vez que leo ‘BOSCO’, mi cerebro solo puede pensar en Wall-E

Lecciones de BOSCO y más allá

No sólo el Consejo de Transparencia se puso posteriormente del lado de Civio, sino que también lo hizo la Secretaría de Digitalización e Inteligencia Artificial al declararse muy insatisfecha con la gestión del caso BOSCO, acogiendo los principales argumentos defendidos por Civio. También la el Defensor del Pueblo ha pedido más garantías para todo el proceso, y el Gobierno está estudiando actualmente la forma de mejorarlo. 

Asimismo, cabe señalar que la posición general del Gobierno español y de otras administraciones sobre la gobernanza algorítmica es clara. En 2021, el Gobierno presentó la Carta de Derechos Digitales, que consagra una serie de derechos de los ciudadanos frente el uso de sistemas de inteligencia artificial. 

Además, iniciativas como un Registro Público de Algoritmos en Barcelona y en breve en Valencia demuestran que se están dando pasos hacia la transparencia y el buen gobierno. En el ámbito del sector privado, también se ha aprobado una norma que regula la transparencia algorítmica en el ámbito laboral. Esta norma otorga a los trabajadores el derecho a ser informados sobre los parámetros, reglas e instrucciones a través de los cuales los algoritmos o sistemas de IA impactan en sus condiciones laborales y determinan el acceso al empleo.

De ahí que el caso BOSCO parezca más bien un caso aislado de mal funcionamiento que otra cosa. Sin embargo, precisamente, el objetivo de las normas y la gobernanza es crear un marco para prevenir estos casos u ofrecer soluciones cuando se producen. Este artículo tratará de ilustrar por qué es importante una buena gobernanza algorítmica, centrándose especialmente en el sector público, cómo está regulado el tema actualmente y cómo podemos utilizar estas normas para conseguir soluciones cuando ocurre algo como lo que ha ocurrido en este caso, así como sus limitaciones y propuestas para abordarlas.

Un enfoque constitucional – ¿Qué hay en juego?

El Estado de Derecho está consagrado en el artículo 2 del Tratado de la Unión Europea como uno de los valores comunes a todos los Estados miembros. En el Estado de Derecho, todos los poderes públicos deben actuar dentro de los límites establecidos por la ley, de conformidad con los valores de la democracia y los derechos fundamentales. El World Justice Project establece una serie de principios que construyen un sistema de Estado de Derecho: rendición de cuentas (“accountability”), lo que significa que tanto el gobierno como los actores privados deben rendir cuentas ante la ley; ley justa, lo que significa que la ley debe ser clara, pública y estable y debe aplicarse de manera uniforme, y que debe garantizar los derechos humanos, así como los derechos de propiedad, contractuales y procesales; gobierno abierto, es decir, que los procesos mediante los cuales se adopta, administra, adjudica y aplica la ley sean accesibles, justos y eficaces; y justicia accesible e imparcial, es decir, que la justicia sea impartida oportunamente por representantes y neutrales competentes, éticos e independientes que sean accesibles, dispongan de recursos adecuados y reflejen la composición de las comunidades a las que sirven.

En este sentido, en España la Constitución consagra el derecho al acceso a la ley bajo la forma del principio de publicidad de las normas. Según este principio, las personas tienen derecho a conocer la existencia y el contenido de todas las normas que les rigen. Siguiendo este mismo razonamiento, otra columna vertebral del Estado de Derecho es el derecho de las personas a conocer la motivación de las decisiones jurídicas que les afectan, que también se aplica generalmente en Derecho administrativo como principio de motivación de los actos administrativos.

Estos dos principios pueden verse perjudicados fácilmente cuando el código se convierte en ley, si éste no se hace público. Cuando una ley es aplicada directamente por un sistema de IA, el propio sistema se convertirá en una ley autoaplicable. En este caso, el código fuente será lo que determine cómo funciona el sistema y cómo toma una decisión. Esto significa que el código fuente será básicamente el texto de la ley, que determinará cómo se aplica la propia ley. Por lo tanto, si permitimos que el código fuente se convierta en ley por la vía de la automatización de dicha ley, debería convertirse en ley en toda su extensión. Entre otras implicaciones, esto significará también que el código fuente, como ley, debería ser accesible a las personas afectadas por el mismo. 

Este concepto, acuñado como lex informatica por Joel Reidenberg, fue popularizado posteriormente como «el código es ley» (“code is law”) por Lawrence Lessig. La codificación (de “código) del Derecho plantea una serie de riesgos inherentes, siendo el más evidente su falta de capacidad para interpretar las normas o para adaptarse a cada caso concreto: el código se limita a ejecutar rígidamente lo que está escrito, sin margen para la interpretabilidad. 

Un segundo riesgo en estos casos, que no es inherente al código sino a la forma en que nos comportamos en torno a él, es la falta de transparencia. Hoy en día, como se ha visto en el caso de BOSCO y muchos otros, existe una reticencia a dar acceso al código fuente de un sistema. Esta falta de visibilidad del código, como se ha explicado, hace imposible auditar el sistema para saber si funciona como debería; es decir, hace imposible acceder al texto de una ley que se está aplicando a sí misma. 

Un sistema jurídico es más que la suma de todos los textos legales que lo componen. Las leyes incluyen exposiciones de motivos introductorias que ayudan a comprender por qué son necesarias y cómo deben interpretarse; incluyen principios que orientan sobre cómo deben aplicarse, e incluyen cláusulas y excepciones abiertas a la interpretabilidad. Posteriormente, las leyes son interpretadas por jueces, tribunales y órganos administrativos, caso por caso y teniendo en cuenta todo lo mencionado. Por tanto, y en conclusión: las leyes deben ser capaces de adaptarse a una realidad compleja. 

Un enfoque práctico – Legislación aplicable

Dada la naturaleza de los sistemas de inteligencia artificial, en este caso serán aplicables principalmente dos normativas: el Reglamento General de Protección de Datos (RGPD) y el Reglamento de Inteligencia Artificial (AIA por sus siglas en inglés). También se tendrán en cuenta otros actos legislativos relacionados con los derechos humanos y la IA. 

Legislación sobre protección de datos

BOSCO, como la gran mayoría de los sistemas de IA, trata datos personales, lo cual lo somete al Reglamento General de Protección de Datos. Esta norma consagra en su artículo 22 un derecho a no ser objeto de decisiones automatizadas (ADM por sus siglás en inglés), cuando tal decisión produzca efectos jurídicos (o similares) en alguien. Cuando se cumplen las excepciones y se produce la ADM, el RGPD también concede el derecho a obtener intervención humana, a expresar el punto de vista de la persona afectada y a impugnar la decisión.

Aunque este artículo prevé algunas excepciones a esta prohibición, en este caso no se puede aplicar ninguna de ellas. Una de ellas puede ser aplicada cuando la ley autoriza la ADM. Sin embargo, para poder aplicarla, la ley debería establecer medidas adecuadas para salvaguardar los derechos y libertades y los intereses legítimos del interesado; lo cual no ocurre en este caso, ya que no está específicamente autorizado por una ley estatal y no se han establecido las salvaguardias adecuadas, como ha quedaos claro. 

En los Países Bajos, el caso SyRI puede ayudarnos a entender algunas de las implicaciones de un caso así y arrojar algo de luz sobre la ADM en el sector público. El algoritmo System Risk Indication (SyRI) del Gobierno holandés era un sistema de IA para la detección del fraude dirigido a los barrios que acogían a grupos pobres o minoritarios del país. El sistema creaba perfiles de riesgo de las personas para detectar diversas formas de fraude, como el fraude en las prestaciones sociales, los subsidios y los impuestos.

Este caso fue investigado tanto por el Tribunal de Distrito de La Haya como por la Autoridad Holandesa de Protección de Datos (AP). Una conclusión relevante del Tribunal es que el sistema tuvo un efecto significativo en la vida privada de las personas afectadas, infringiendo el artículo 8 del Convenio Europeo de Derechos Humanos (derecho al respeto de la vida privada y familiar). Esto implica que casos como éste entrarían dentro del “efecto jurídico” del artículo 22 RGPD. 

Otra conclusión relevante de la AP neerlandesa es que ésta determinó que, independientemente de si se aplica el artículo 22 del RGPD, siempre deben respetarse los principios del artículo 5 del RGPD. Por lo que respecta a este caso, esto incluye los principios de transparencia y responsabilidad proactiva (“accountability”). 

Por otra parte, la prohibición de ADM exige que la decisión sea exclusivamente automatizada. Sin embargo, la jurisprudencia acepta cierto grado de intervención humana para que siga entrando en el ámbito de aplicación del artículo 22. Según la interpretación del Comité Europeo de Protección de Datos (CEPD), no todas las formas de participación humana en un proceso de toma de decisiones excluyen la aplicación del artículo 22, ya que los meros gestos simbólicos realizados por seres humanos no bastan para suprimir la prohibición de ADM. En el caso de BOSCO, aunque la sentencia declare que la decisión la toma formalmente un órgano administrativo y no el sistema (ya que jurídicamente un sistema de IA no puede tomar formalmente una decisión administrativa), de facto no existe una implicación humana en la decisión en sí misma. Por lo tanto, se considerará únicamente una toma de decisiones automatizada, y se aplicará el artículo 22. 

El RGPD también otorga derechos de transparencia a las personas afectadas por la ADM en su artículo 15. Estos derechos incluyen el derecho a conocer la existencia de tales decisiones y a obtener información significativa sobre la lógica implicada, así como sobre la importancia y las consecuencias previstas de dicho tratamiento para el interesado.

Legislación sobre inteligencia artificial

El Reglamento de Inteligencia Artificial (AIA) no era más que un borrador cuando se inició el caso BOSCO, y, de hecho, la mayor parte del mismo aún no ha entrado plenamente en vigor a día de hoy. Sin embargo, de cara al futuro, es útil comprender cómo podría esta normativa llegar a afectar a casos similares. 

El AIA regula el desarrollo, despliegue y uso de sistemas de inteligencia artificial en la Unión Europea. Utiliza un enfoque basado en el riesgo con cuatro niveles de riesgo: riesgo inaceptable, riesgo alto, riesgo limitado y riesgo mínimo. 

Los sistemas de IA de alto riesgo (HRAIS por sus siglas en inglés) incluyen, entre otros, los que se utilizan para evaluar (para una autoridad pública o como autoridad pública) si las prestaciones y servicios esenciales de asistencia pública están o siguen estando disponibles para una persona concreta. Por tanto, BOSCO, cuyo objetivo es a evaluar si los ciudadanos tienen derecho a una subvención en su factura eléctrica por motivos de vulnerabilidad, deberá considerarse un sistema de alto riesgo. 

Estos sistemas están sujetos a determinadas obligaciones, la mayoría de ellas relacionadas con la transparencia y la rendición de cuentas, pero también con la solidez, la precisión y la resistencia. Curiosamente, una estas obligaciones prevé que los HRAIS deban contar con una evaluación de conformidad realizada por un tercero, lo cual significa que el legislador pretende que estos sistemas de alto riesgo sean auditados de forma independiente.

Asimismo, el considerando 73 también exige que los sistemas de alto riesgo se diseñen de forma que «las personas físicas puedan supervisar su funcionamiento, garantizar que se utilizan según lo previsto y que sus impactos se abordan a lo largo del ciclo de vida del sistema». La frase «utilizados según lo previsto» es de gran importancia para este caso, ya que ésta es precisamente la clave de lo que le está ocurriendo al sistema: no se está utilizando según lo previsto porque no funciona adecuadamente. 

Además, el AIA contiene otra obligación que establece que las personas afectadas deberán ser informadas cuando se utilice un HRAIS para tomar decisiones que les conciernan, incluso si el sistema sólo se utiliza a modo de apoyo en lugar de tomar la decisión de forma completamente automatizada (lo que va más allá del artículo 22 del RGPD sobre ADM). En tal caso, el proveedor está obligado a explicar cuáles han sido los elementos clave de la decisión.

Sin embargo, a diferencia del RGPD, en el AIA no existe un derecho individual a presentar una reclamación ante una autoridad de control. Por lo tanto, los particulares y las organizaciones civiles carecen de mecanismos para recurrir directamente o que puedan utilizar para hacer valer sus derechos o para iniciar un procedimiento ante las autoridades de control cuando se produzca un incumplimiento. 

Es cierto que el artículo 67, por ejemplo, otorga a las autoridades supervisoras la facultad de adoptar las medidas oportunas para que los operadores cumplan la normativa cuando exista un riesgo para la salud o la seguridad, o se vean amenazados los derechos fundamentales o el interés público. Sin embargo, todo queda en manos de las autoridades responsables, que tendrán que vigilar todo el mercado por sí mismas. Esto significa que, idealmente, tendrían que tener la capacidad tanto para tener conocimiento de cada problema como para iniciar todas las acciones necesarias de oficio; lo que, en la práctica, es casi imposible, pues será extremadamente complicado para las autoridades tener la capacidad de vigilar plenamente todo el mercado para para poder abarcar cada caso potencial de incumplimiento, dado el tamaño actual del mercado y la escala de uso de la inteligencia artificial. 

Todo lo anterior dejará a las autoridades en una posición delicada con respecto a los actores del mercado, tanto privados como públicos, ya que las autoridades nunca dispondrán de recursos suficientes para poder supervisar todo el mercado. También dejará desprotegidos a los particulares, que no tendrán ninguna posibilidad de reparación directa, así como a la sociedad civil, que carecerá de recursos para abordar directamente las prácticas problemáticas de la IA. Esto generará un desequilibrio de poder que favorecerá a los proveedores y distribuidores de IA y dificultará su aplicación. 

Por otro lado, en lo que respecta a la coherencia interna de la normativa, tampoco tiene sentido que se concedan a las personas determinados derechos (como el derecho a la transparencia) mientras no se les otorga el poder para hacerlos cumplir. 

Además de la Unión Europea, otros países y jurisdicciones están creando también legislación sobre Inteligencia Artificial, centrándose parte de ella en gran medida en la transparencia y la rendición de cuentas. Por ejemplo, la propuesta de Ley de Gobernanza Automatizada Transparente o Ley de Rendición de Cuentas Algorítmica en EE.UU., o la Directiva sobre Toma de Decisiones Automatizada en Canadá. 

Siguiendo los mismos principios, la Unión Europea, EE.UU. y el Reino Unido han firmado el primer tratado jurídicamente vinculante sobre IA, cuyo objetivo es garantizar que el uso de la IA se ajuste a «los derechos humanos, la democracia y el Estado de Derecho». El tratado establece como principios fundamentales, entre otros, la transparencia y la supervisión, así como la rendición de cuentas y la responsabilidad. 

Este tratado también recoge la necesidad de recursos apropiados, derechos procesales y salvaguardas, que incluyen la obligatoriedad de documentación, prácticas de transparencia que permitan a las personas impugnar cualquier decisión tomada por el sistema, la posibilidad de presentar una reclamación ante las autoridades competentes, garantías procesales efectivas y ser informado cuando se esté interactuando con un sistema de IA. 

Carta de Derechos Digitales

En 2021, el Gobierno español presentó la Carta de Derechos Digitales, que consagra una serie de principios a observar cuando interviene una inteligencia artificial; entre ellos transparencia, auditabilidad, explicabilidad, trazabilidad y accesibilidad. Sin embargo, al igual que ocurre con el AIA, esta Carta no establece obligaciones directamente aplicables ni incluye mecanismos de recurso directo, aunque sí que obliga a que las personas que interactúen con sistemas de IA tengan derecho a solicitar intervención y supervisión humana, a impugnar decisiones automatizadas y a ser asistidas por un humano a petición del ciudadano. 

oh, la justicia

Aplicación de los principios expuestos

Como se desprende del análisis realizado de la legislación aplicable, hay una serie de principios que se repiten en la mayoría de las normas: transparencia; rendición de cuentas; intervención humana; y derechos y mecanismos de reparación y recurso. 

Transparencia

El principio de transparencia, en términos generales, pretende facilitar la tarea de exigir responsabilidades a los representantes del pueblo, a las instituciones y a otros actores. Sin embargo, este principio también es en sí mismo una columna vertebral del Estado de Derecho, ya que el proceso legislativo, el texto de las normas y las decisiones tomadas en interpretación de las mismas deben llevarse a cabo de forma transparente. La transparencia es un requisito sine qua non para el Estado de Derecho, así como una parte necesaria de la rendición de cuentas. 

Sin embargo, por muy importante que sea la transparencia, la transparencia aplicada de forma tradicional, por sí sola, ha demostrado no ser suficiente. La transparencia no puede ser la única solución en todos los casos, sino que es necesario complementarla con otras medidas. Por ejemplo, los derechos de transparencia consagrados por el RGPD y el AIA son claramente insuficientes en el caso de BOSCO. En este caso, ambos derechos se refieren a la lógica y el razonamiento que subyacen a las decisiones tomadas por el algoritmo. Sin embargo, la lógica y el razonamiento de BOSCO ya los conocemos, pero siguen sin ser suficientes. 

En el caso de BOSCO no hay complejidad alguna en la toma de decisiones del sistema: el software sólo tiene que comprobar si se cumplen o no unos requisitos muy sencillos. No hay ningún otro valor o razonamiento detrás de la decisión tomada por el sistema. 

Curiosamente, en las conclusiones del Abogado General del caso C-203/22, el Abogado General (AG) considera que, desde la perspectiva del RGPD, una «información significativa sobre la lógica implicada» debe permitir al interesado ejercer los derechos que tiene garantizados. Esto presupone que la información, además de ser concisa, fácilmente accesible y comprensible, debe ser lo suficientemente completa y contextualizada como para permitir a dicha persona verificar su exactitud y si existe una coherencia y una relación de causalidad objetivamente verificables entre, por una parte, el método y los criterios utilizados y, por otra, el resultado al que se llega mediante la decisión automatizada.

En el caso de BOSCO, esto significa que la información otorgada debe ser suficiente para determinar si el método y los criterios utilizados para llegar a la decisión tomada son coherentes.

Además, el AG tiene en cuenta la existencia de derechos de terceros (datos personales de terceros y secretos comerciales) cuando se trata de partes delicadas del software o del propio código fuente. Cuando estos derechos puedan verse afectados, el AG ofrece una solución: que la información necesaria se entregue a una autoridad o tribunal para su examen, en lugar de entregarla a la parte afectada. Esto, interpretado sensu contrario, nos lleva a una conclusión muy razonable: cuando no existen tales derechos de terceros (es decir, no existen secretos comerciales ni datos de terceros), no hay razón para no revelar la información necesaria para que la persona pueda verificar la exactitud de la decisión. En este caso, no hay razón para no revelar el código fuente de BOSCO. 

En este sentido, el AIA también otorga a las autoridades supervisoras el poder de solicitar el código fuente de los sistemas de IA de alto riesgo en determinados casos, lo cual significa que no existe razón para interpretar que el código fuente sea «sacrosanto».

Es cierto que el Tribunal esgrimió, en su sentencia contra Civio, razones de ciberseguridad contra la divulgación del código. Sin embargo, este razonamiento suena más a una excusa que a otra cosa. Éste es un argumento completamente obsoleto que ya no se sostiene; hace tiempo que se ha demostrado que la seguridad por oscuridad no es una forma adecuada de proteger el software de posibles vulnerabilidades. Hasta la Agencia de Seguridad Nacional estadounidense (NSA) tiene un proyecto de código abierto en el que proporciona acceso libre al código de muchos de sus programas y herramientas de desarrollo propio. Una preferiría creer que la NSA no facilitaría dicho código si existiera algún riesgo al hacerlo. 

Pero tenemos ejemplos más cercanos sin necesidad de cruzar el Atlántico: el Gobierno español ha liberado el código fuente de aplicaciones de desarrollo propio para su escrutinio y auditoría públicos. El código fuente de la aplicación de rastreo COVID se reveló por razones de transparencia, como también se hizo en muchos otros países europeos. Si esto supusiera una vulnerabilidad, la revelación del código fuente de dicha app podría suponer un riesgo de divulgación no autorizada de los datos sanitarios de millones de personas. Sin embargo, el Gobierno confirmó que la aplicación era perfectamente segura y respetuosa con la privacidad, al tiempo que afirmaba que la tecnología debía ponerse al servicio de los ciudadanos. ¿Por qué habría de ser diferente el razonamiento en el caso de BOSCO u otros sistemas de IA creados por o para el sector público?

Otro de los principales argumentos en contra de la transparencia algorítmica siempre han sido los derechos de propiedad intelectual y la razón de ser de dichos derechos, ya que la propiedad intelectual busca proteger, entre otros, la inversión y el esfuerzo empleados para una creación intelectual. Sin embargo, cuando dicha creación es pagada o realizada directamente por la administración pública, el razonamiento anterior carece de sentido, ya que la inversión se realiza originalmente en interés de la ciudadanía y no busca ningún beneficio económico, al contrario que la empresa privada.

En tal caso, la administración pública no debe tener otro interés que el interés del pueblo. Por lo tanto, impedir la reutilización del código fuente carece de sentido, ya que no hay ánimo de lucro, mientras que la divulgación del código puede ser un activo para futuros proyectos. Además, impedir que el código sea auditado sólo conduciría a obstaculizar posibles mejoras y detección de errores. «Dinero público, código público».

Rendición de cuentas

El principio de rendición de cuentas (o “accountability”) nos permite someter a escrutino a determinados actores (empresas y administraciones) para que puedan ser examinados y rindan cuentas por sus actos. En un ámbito tan complejo y en constante evolución como es el uso de la inteligencia artificial y el impacto que ésta puede tener en nuestras vidas y en la sociedad en general, la rendición de cuentas adquiere más importancia que nunca.

En este sentido, el AIA exige a los sistemas de IA de alto riesgo un elevado nivel de responsabilidad. Dado que el Reglamento utiliza un enfoque basado en el riesgo, lo que se impone es un esquema gradual de requisitos y obligaciones en función del nivel de riesgo que plantee el sistema de IA para la salud, la seguridad y los derechos fundamentales. En este sentido, se les atribuye a los actores la responsabilidad de su propia buena gobernanza, y se les obliga a generar una serie de documentación interna, así como a crear procesos seguros y a someterse a auditorías externas. 

La rendición de cuentas o responsabilidad proactiva (“accountability”), consagrada como principio en el apartado 2 de su artículo 5, es también uno de los principios fundamentales del Reglamento general de protección de datos. Estos principios son aplicables a cualquier sistema que trate datos personales, incluyendo a BOSCO, como se ha señalado anteriormente. Y, una vez más, la transparencia, siempre vinculada a la rendición de cuentas, es otro de los principios de protección de datos que deben ser aplicados, como tambien lo son la licitud y la lealtad.

La necesidad de una gobernanza justa en el sector público aumenta según aumenta la capacidad tienen los sistemas de IA de afectar a nuestros derechos fundamentales. Esto implica que, indudablemente, es imprescindible hacer especial hincapié tanto en la transparencia como en la rendición de cuentas. Y la rendición de cuentas requiere que tengamos la capacidad de fiscalizar a las administraciones y exigirles responsabilidades. Por tanto, la administración deberá poner a disposición de la ciudadanía cualquier medio para inspeccionar el uso de dichos sistemas. 

Para ello existen muchas maneras, siendo una de ellas la existencia de auditorías independientes y externas del código fuente de los sistemas públicos de IA, así como la puesta a disposición del público de la documentación pertinente, incluido el código fuente cuando sea posible, la creación de un inventario público de dichos sistemas y el establecimiento de procesos de supervisión sólidos. 

Sin embargo, la rendición de cuentas por sí soa, sin una adecuada supervisión, no tiene sentido. Si las administraciones saben que nunca tendrán que rendir cuentas, se pierde todo el sentido de la exigencia de responsabilidades.

El ser humano en el proceso

«Human in the loop» (“el ser humano en el proceso”, HITL por sus siglas en inglés) es una de las soluciones más recurrentes cuando se habla de salvaguardas para los sistemas de IA. El derecho a solicitar la intervención humana, el derecho a no estar sujeto a decisiones tomadas únicamente por una máquina o el derecho a impugnar una decisión tomada por un sistema de IA aparecen una y otra vez como formas de minimizar los riesgos que estos sistemas suponen para los derechos y libertades de las personas.

Sin embargo, como se ha demostrado, esta solución presenta algunas limitaciones. la principal es que el HITL es, en muchos casos, mayormente una salvaguarda a posteriori. Cuando se trata de tareas o sistemas de ADM o no complejos, normalmente no interviene ningún humano en el proceso; de lo contrario, si en dicho proceso un humano fuera necesario, se perdería todo el sentido de automatizar ciertas acciones. Que la intervención humana ocurra a posteriori significa que 1) la persona afectada ya se habrá visto impactada por el sistema de IA, pudiendo ver afectados sus derechos, y 2) que muchas personas afectadas pueden aceptar la decisión tomada por el sistema sin contemplar (o sin ser capaces de comprender) la posibilidad de que sea errónea, por lo que es posible que ni siquiera se den cuenta de que sus derechos se han visto afectados. 

Sin embargo, en el caso de BOSCO, el algoritmo es tan simple que implicar a un humano en el proceso no tendría sentido. Añadir la revisión humana por defecto significaría que no habría necesidad de utilizar BOSCO, ya que revisar los resultados de BOSCO o revisar un formulario con unas pocas opciones supondrían la misma cantidad de tiempo y esfuerzo para la persona encargada; por lo tanto, BOSCO sería inútil.  

Derechos individuales y reparación

Los mecanismos de reparación son indispensables cuando se conceden derechos; pues no hay mejor forma de garantizar que se respeten los derechos que dar a los ciudadanos una vía adecuada para hacerlos valer. 

Sin embargo, es igualmente importante no hacer recaer todo el peso de esta responsabilidad en los ciudadanos, ya que la mayoría de las personas no suelen tener los conocimientos ni la capacidad para emprender procedimientos legales. Por eso es igualmente importante la actuación de la sociedad y organizaciones civiles, y por eso en normativas como el RGPD se otorga también a las organizaciones civiles la capacidad de presentar reclamaciones en nombre de ciudadanos particulares. Varias de las acciones más importantes para hacer cumplir el RGPD proceden de organizaciones civiles. Una acción de La Quadrature du Net dio lugar a la mayor multa bajo del RGPD (una multa de 746 millones de euros contra Amazon), mientras que noyb consiguió que el Comité Europeo de Protección de Datos pusiera en marcha un grupo de trabajo para tratar varias reclamaciones relativas al uso de cookies, lo que ha llevado a una aplicación más armonizada de la normativa. También consiguieron que la Autoridad Irlandesa de Protección de Datos tomara una decisión clave sobre el modelo de negocio de Meta. A raíz de una acción del Consejo Irlandés para las Libertades Civiles (ICCL), la Comisión Europea empezará a comprobar periódicamente el progreso de todos los casos a gran escala relacionados con el RGPD en toda la UE.

Como se ha visto, el buen funcionamiento de los derechos procesales individuales y civiles ha demostrado ser de gran importancia; por esta razón, la Comisión Europea ha presentado un proyecto para adoptar nuevas normas que garanticen una aplicación más estricta del RGPD en los casos transfronterizos. Como se suele decir, «las leyes, si no se aplican, no son más que simples consejos». 

Conclusiones

Todos los principios mencionados anteriormente están inextricablemente ligados. Es la suma de todos ellos lo que garantizará la buena gobernanza de la inteligencia artificial y el respeto de los derechos humanos de las personas afectadas por la IA.

Como señala Virginia Eubanks, un algoritmo nunca debería servir para liberar a quienes toman las decisiones de las consecuencias humanas de las decisiones políticas. Y más aún cuando esas decisiones ni siquiera se llevan a cabo tal y como el algoritmo debería llevarlas a cabo, como Civio ha demostrado y explicado. El hecho de que no sea la norma la que ha dado lugar al mal funcionamiento, sino el propio software, revela la imperiosa necesidad de tener acceso al código fuente de BOSCO (o de cualquier otro algoritmo que afecte a derechos fundamentales). 

Es necesario que la sociedad tenga la capacidad de supervisar aquellos sistemas que toman decisiones o que determinan directamente el resultado de decisiones con efectos relevantes; de lo contrario, atacar el Estado de Derecho sería tan fácil como automatizar todas las decisiones importantes, ya que no habría forma de supervisarlas.

Los ciudadanos ya gozan de ciertos derechos en relación con el uso de sistemas de IA que les afectan. Sin embargo, se ha demostrado que dichos derechos no son suficientes o que, al menos, no se aplican de forma justa. El marco legislativo vigente establece varias obligaciones de transparencia y rendición de cuentas que se complementan entre sí, así como principios que deberían haber evitado, en teoría, que ocurriera lo que ha ocurrido. Sin embargo, tales principios no han impedido, en efecto, que el sistema («sistema» como «sistema de IA», como «sistema jurídico» y como «sistema de administración pública») funcione incorrectamente. En parte, porque todo el peso de una gobernanza buena y justa no puede recaer únicamente en los ciudadanos. Una gobernanza buena y justa debe nacer de dentro de la misma administración, y ésta debe poner a disposición de la ciudadanía y de los actores civiles todos los medios posibles para fiscalizarla y exigirle responsabilidades. 

el mundo si la gobernanza de los sistemas de IA funcionase a la perfección

La entrada Lecciones de BOSCO se publicó primero en Citizen8.

La Ley 2/2023, de 20 de febrero, reguladora de la protección de las personas que informen sobre infracciones normativas y de lucha contra la corrupción, establece en su artículo 38.1, como medida de protección frente a represalias, que las personas que informen o que hagan una revelación pública sobre acciones u omisiones recogidas en dicha Ley, no podrán considerarse como infractores responsables de ninguna restricción de confidencialidad o secreto “siempre que tuvieran motivos razonables para pensar que la comunicación o revelación pública de dicha información era necesaria para revelar una acción u omisión en virtud de esta Ley, sin perjuicio de la dispuesto en el artículo 2.3. Esta medida no afectará a las responsabilidades de carácter penal”.

Como no puede ser de otra manera, tal excepción hay que ponerla en relación con las obligaciones legales o contractuales de confidencialidad y/o secreto, a través de las que las empresas imponen a las personas que les prestan servicios (sea en régimen laboral o no) determinadas restricciones en la revelación de información a la que tienen acceso en virtud del ejercicio de las funciones que les son propias.

II.- Configuración legal y contractual de la obligación de confidencialidad.

Desde la óptica de la configuración legal de dichas obligaciones de confidencialidad, por un lado, tenemos el deber de confidencialidad de las personas que ejercen determinadas funciones dentro de una organización previsto en el art. 5.1 f) del RGPD y art. 5 de la LOPDyGDD. Asimismo, tenemos el deber general de confidencialidad respecto a los secretos empresariales, de conformidad con lo previsto en el artículo 3.2 de la Ley 1/20219 de Secretos Empresariales, que considera ilícita la revelación de dichos secretos por parte de quien haya incumplido un acuerdo de confidencialidad o cualquier otra obligación de no revelar el secreto empresarial, o quien haya incumplido una obligación contractual o de cualquier otra índole que limite la utilización del secreto, lo que deja claro que dicha obligación debe existir expresamente y estar vigente para poder incumplirse. Lo anterior, evidentemente, queda matizado por lo expuesto en el primer párrafo en relación con el art. 38.1 de la Ley 2/2023, esto es, siempre que dicho secreto empresarial esté relacionado con alguna de las materias objeto de comunicación que se prevén en la Ley 2/2023 se debe entender que no existe tal vulneración del secreto empresarial por parte de la persona informante. Lo mismo puede predicarse respecto de la obligación que dimana del artículo 5.1 f) RGPD.

A su vez, este deber de confidencialidad también lo podemos encontrar, aunque no expresamente pero sí jurisprudencialmente, en el artículo 5 a) del Estatuto de los Trabajadores como una de las obligaciones contractuales que pueden introducirse de manera lícita en un contrato de trabajo, existiendo incluso Sentencias que han declarado procedente el despido por la negativa del trabajador a firmar dichas cláusulas o acuerdos de confidencialidad. Así, el efecto de lo dispuesto en el artículo 38.1 de la Ley 2/2023 es, en su caso, eximir al trabajador de cualquier responsabilidad por incumplimiento de obligaciones contractuales por la comunicación o revelación de información confidencial dentro del ámbito material de aplicación de dicha Ley.

Asimismo, el régimen sancionador previsto en la Ley 2/2023 califica como “muy grave” cualquier actuación que limite los derechos y garantías previstos en dicha Ley mediante la introducción de cláusulas contractuales o acuerdos a nivel individual o colectivo, esto es, no es que no puedan introducirse cláusulas de confidencialidad en los contratos de trabajo o acuerdos colectivos, o en los acuerdos con profesionales o terceros, sino que lo que prohíbe es una aplicación de estas obligaciones contractuales de secreto, sigilo o confidencialidad que restrinja y pretenda sancionar las comunicaciones permitidas a través de la Ley 2/2023.

III.- Responsabilidad por la comunicación y juicio de necesidad.

Cobra vital importante, como no, el concepto de “necesidad”, pues recordemos que la cláusula de cierre del artículo 38.1 de la Ley 2/2023 establece que la exención de responsabilidad por la comunicación o revelación de información confidencial será aplicable siempre que las personas informantes “tuvieran motivos razonables para pensar que la comunicación o revelación pública de dicha información era necesaria para revelar una acción u omisión en virtud de esta Ley”. Sí, amigos, a vueltas con el juicio de necesidad.

Así pues, a los efectos de poder aplicar dicha exención de responsabilidad de la persona informante, tal y como ocurre en materia de protección de datos, pero también en otros ámbitos jurídicos, habrá que verificar si en cuanto a la comunicación o revelación se refiere, existen otras medidas menos gravosas, que causen un menor perjuicio al interés público o empresarial y a los derechos fundamentales de las personas afectadas. Es decir, la norma parece exigir un deber de diligencia previo de la persona informante, que deberá comprobar antes de realizar la comunicación o revelación si existen otras vías que causen un menor perjuicio para los derechos y libertades de terceros, en particular, de las personas afectadas por la comunicación, debiendo verificar si “existen motivos razonables” de que el uso de determinada vía de comunicación (canal interno, externo y, sobre todo, revelación pública) es la más adecuada para limitar, suprimir o minimizar los efectos de una infracción incluida en el ámbito materia de la Ley 2/2023. Por lo anterior, la protección de la persona informante quedaría sujeta a la valoración adicional de la necesidad de la comunicación o revelación pública, si bien es cierto que lo anterior no supone que se prive a la persona de toda protección ofrecida por la Ley, sino que, en su caso, no quedará exenta de responsabilidad por la comunicación o revelación de la información confidencial en cuestión si no se supera favorablemente el juicio de necesidad.

Así, superado el juicio de necesidad, parece que la Ley establece que el informante quedará exento de responsabilidad cualquier tipo y en cualquier ámbito por la revelación de la información confidencial en cuestión, no obstante, acto seguido, el mismo precepto (art. 38.1) establece que “Esta medida no afectará a las responsabilidades de carácter penal”. Suponemos que este último inciso se refiere a las responsabilidades penales en relación con el acceso ilícito a la información que se indican, como se dirá, en el apartado 2 del mismo artículo 38, por un posible delito de revelación de secretos.

Como no, también existen límites a la exención de responsabilidad y ellos se encuentran en los apartados 2 y 3 del artículo 38 de la Ley 2/2023. El primer límite es que el acceso a la información se haya producido mediante la comisión de un hecho delictivo. La segunda excepción vuelve de nuevo a referirse al principio de necesidad, al establecer que cualquier otra responsabilidad de los informantes derivada de acciones u omisiones no relacionadas con la comunicación o revelación que no sean “necesarios” para comunicar una información será exigible conforme a la normativa aplicable.

A tenor de lo anterior, lo informantes, antes de realizar la comunicación o revelación pública, deberán tomar las cautelas necesarias y evaluar si la revelación de determinado secreto o información confidencial es necesaria para el buen cauce de la investigación evaluando la afectación a los derechos de terceros. En caso contrario, podrían estar sujetos a responsabilidad de cualquier tipo.

Gerard Espuga
Abogado
DPO

La entrada Whistleblowers, confidencialidad y juicio de «necesidad» se publicó primero en Citizen8.

Some years ago, the Spanish Government decided to change the conditions and requirements set for vulnerable people to receive a discount in their electricity bill. This subsequently led to the introduction of a newly developed software – created by the public administration – that electricity companies would need to use to determine whether a citizen is entitled to the bill reduction. This software, called BOSCO, was based on a regulation that defined the specific prerequisites to obtain the discount – prerequisites that were slightly different to the previously existing ones. These changes, along with the new complexity brought by the use of BOSCO and other bureaucracy issues, resulted in a huge number of people that ended up not requesting the grant they were entitled to. (Spanish version of this post, here).

Upon this happening, Civio, a Spanish organisation with the purpose of monitoring public bodies and powers, in collaboration with the National Markets and Competition Commission, created and launched a free application that would allow people to assess whether they were eligible for the grant, as well as help them with the bureaucratic process. However, through this app, they ended up discovering that BOSCO was apparently missassesing eligibility, since people that were entitled to the grant according to the requisites established by the regulation and according to Civio’s app were rejected by BOSCO.

The BOSCO case

In order to enlighten the issue, Civio requested the Ministry, and later the Council of Transparency, access to BOSCO’s source code. However, the Ministry, as well as the Council of Transparency, rejected their request and refused to give access to the code, so Civio filed a lawsuit against that decision. Based on a number of factors, the lawsuit was dismissed and Civio was rejected access to the source code of BOSCO. The judge upheld four main arguments: firstly, that BOSCO is a mere part of the administrative proceedings, so its outcome does not constitute an administrative decision. Secondly, that the non-disclosure of the code makes the application more secure, and since the code is not reusable, as it too specific, it should not be disclosed to avoid endangering security. Thirdly, that the algorithm has already been audited and that the outcome can be cross-checked with the norm to verify whether someone fulfils the requirements and is entitled to the grant. And fourthly, that public security may be threatened by disclosing the code. 

Subsequently, Civio challenged this judgement. In the meantime, the Council of Transparency undid itself and sided with Civio, but the Ministry still opposed to Civio’s responding lawsuit. On May 2024, this last lawsuit was also dismissed on similar grounds. 

every time I read ‘BOSCO’, mi brain can only picture Wall-E

Lessons from BOSCO – And further

Not only the Council of Transparency sided later with Civio, but also the Secretary of Digitalization and Artificial Intelligence did by declaring to be very unsatisfied with the BOSCO case, upholding the main arguments defended by Civio. The Ombudsman Office has called for further safeguards on the whole process, and the Government is currently studying a way to improve it. 

Also, it is to be noted that the general position of the Spanish Government and other administrations on algorithmic governance is clear in this regard. In 2021, the Spanish Government presented the Charter of Digital Rights, that enshrines a series of rights when citizens face the use of artificial intelligence systems. 

Additionally, initiatives like a Public Algorithms Register in Barcelona and shortly in Valencia show that steps are being taken towards transparency and good governance. For the private sector, the Parliament passed a law that regulates algorithmic transparency in the employment field. This norm gives workers the right to be informed about the parameters, rules and instructions via which algorithms or AI systems impact their working conditions and determine access to employment.

Hence, the BOSCO case looks more like an isolated case of malfunctioning rather than anything else. However, it is the whole point of norms and governance to create a framework to prevent such cases, or to offer solutions when they happen. This article will try to illustrate why good algorithmic governance is important, especially focusing on the public sector, how it is currently regulated, and how we can use these norms to obtain redress when something like this happens, as well as their limitations and proposals to address them.

A constitutional approach – What’s at stake?

The rule of law is enshrined in Article 2 of the Treaty on European Union as one of the common values for all Member States. Under the rule of law, all public powers shall act within the constraints set out by law, in accordance with the values of democracy and fundamental rights. The World Justice Project lays down a series of principles that build a rule of law system: accountability, meaning that the government as well as private actors are accountable under the law; just law, meaning that the law must be clear, publicised, and stable and must be applied evenly, and that it must ensure human rights as well as property, contract, and procedural rights; open government, meaning that the processes by which the law is adopted, administered, adjudicated, and enforced are accessible, fair, and efficient; and accessible and impartial justice, meaning that justice is delivered timely by competent, ethical, and independent representatives and neutrals who are accessible, have adequate resources, and reflect the makeup of the communities they serve.

In this sense, in Spain the Constitution enshrines the right of access to the law in the form of the principle of publicity of the norms. According to this principle, the people have the right to know of the existence and content of every norm that governs them. Following the same reasoning, another backbone of the rule of law is the right of people to know the reasoning of legal decisions that affect them, which is also generally applied in administrative law as the principle of motivation of administrative acts.

The two above mentioned principles can easily get impaired when code becomes law, if code is not disclosed. When a law is directly applied by an AI system, the system itself will become a self-enforceable law. In this case, the source code will be what will determine how the system works and how it reaches a decision. This means that the source code will basically be the text of the law, that determines how the law is applied. Hence, if we allow source code to become law by the way of automating such law, it should become law to a full extent. Among other implications, this shall also mean that the source code, as law, must be accessible to the people affected by it. 

This concept, coined as lex informatica by Joel Reidenberg, was subsequently popularised as “code is law” by Lawrence Lessig. The code-ification of the law poses a series of inherent risks, the most obvious one being its lack of capacity to interpret any norm or to adapt to a case-by-case basis: the code just rigidly executes what is written, with no room to interpretability. 

A second relevant risk, that is not inherent to code but to the way we behave around code, is the lack of transparency. Nowadays, as seen in the case of BOSCO and many others, there is a reluctance to give access to the source code of a system. This lack of visibility into the code, as explained, makes it impossible to audit the system in order to know whether it functions as it should, i.e., it makes it impossible to get access to the text of a law that is enforcing itself. 

A legal system is more than the sum of every legal text that composes it. Laws include introductory statements that help understand why they are necessary and how they need to be interpreted; they include principles to guide how they need to be applied, and include clauses and exceptions open to interpretability. Laws are later interpreted by judges, courts, and administrative bodies, on a case-by-case basis and taking all the latter into account. In conclusion: laws need to be able to adapt to a complex reality. 

A practical approach – Applicable legislation

Given the nature of AI systems, two main regulations are applicable to this case: the General Data Protection Regulation (GDPR), and the Artificial Intelligence Act (AIA). Other pieces of legislation relating to human rights and AI will also be taken into account. 

Data protection legislation

BOSCO, as most AI systems, processes personal data. This subjects it to the General Data Protection Regulation. This norm enshrines in Article 22 a general right not to be subject to automated decision making (ADM), when such a decision legally (or similarly) affects someone. When exceptions are met and ADM happens, it also grants the right to obtain human intervention, to express their point of view, and to contest the decision.

Although this Article provides for some exceptions to this prohibition, none of them apply. One of the exceptions can be applied when ADM is authorised by the law. However, in order to be able to apply it, suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests shall be laid down in the law. This is something that does not happen in this case, since it is not specifically authorised by a state law and appropriate safeguards have not been established, as reasoned. 

In the Netherlands, the SyRI case can help us understand certain implications and shed some light on ADM in the public sector in similar cases. The Dutch Government’s System Risk Indication (SyRI) algorithm was an AI system for fraud detection targeted at neighbourhoods hosting poor or minority groups in the country. The system built risk profiles of individuals to detect various forms of fraud, including social benefits, allowances, and taxes fraud.

This case was investigated both by the District Court of The Hague and the Dutch Data Protection Authority (Dutch DPA). One relevant finding from the Court is that the system had a significant effect on the private life of the affected persons, breaching Article 8 of the European Convention on Human Rights (right to respect for private and family life). This implies that cases like this one shall fall under Article 22’s “legal effect”. 

Another relevant finding by the Dutch DPA determined that, irrespectively of whether Article 22 GDPR is applied, principles from Article 5 GDPR must be respected nonetheless. For what is relevant to this case, this includes the transparency and accountability principles. 

On another note, the ADM prohibition requires for the decision to be solely automated. However, case law accepts some degree of human involvement for it to continue to fall under Article 22. According to guidance from the European Data Protection Board (EDPB), not all forms of human involvement in a decision-making process rule out the application of Article 22, as mere token gestures taken by humans are not enough to set aside the ADM prohibition. In the case of BOSCO, even if the judgement declares that the decision is formally made by an administrative body and not by the system (since legally speaking an AI system cannot officially make an administrative decision), human involvement in the decision itself is de facto nowhere to be found. Hence, it shall be considered solely automated decision making, and Article 22 shall apply. 

The GDPR also grants transparency rights to people affected by ADM in its Article 15. Those rights include the right to know about the existence of such decisions, and to obtain meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.

Artificial intelligence legislation

The Artificial Intelligence Act was only a draft when the BOSCO case started, and most of it has not yet fully entered into force to this day. However, looking to the future, it is helpful to understand how this regulation may affect similar cases one day. 

The AI Act regulates the development, deployment and use of artificial intelligence systems in the European Union. It uses a risk-based approach with four levels of risk: unacceptable risk, high risk, limited risk, and minimal risk. 

High risk AI systems (HRAIS) include, among others, those that are used for evaluating (for or as a public authority) whether essential public assistance benefits and services are or continue to be available to a particular person. Therefore, BOSCO, aimed at evaluating whether citizens are entitled to an electricity grant due to vulnerability reasons, must be considered a HRAIS. 

These systems are subject to several obligations, most of them related to transparency and accountability, but also to robustness, accuracy and resiliency. Interestingly, one of them is that the AIA envisages that HRAIS shall have a conformity assessment carried out by an appropriate third party, what means that the legislator intends for these high-risk systems to be independently audited.Similarly, Recital 73 also requires high-risk systems to be designed so that «natural persons can oversee their functioning, ensure that they are used as intended and that their impacts are addressed over the system’s lifecycle.». The sentence “used as intended” is of great importance to this case, since this is precisely the key of what is happening to the system: it is not being used as intended because it is malfunctioning. 

Additionally, the AIA lays down another obligation that establishes that affected persons shall be informed when an HRAIS is used for decisions concerning them, even if the system is only used in a supporting capacity rather than making the full decision automatedly (which goes further than Article 22 GDPR on ADM). In such a case, the provider is obliged to explain what the key elements of the decision were.

However, contrary to the GDPR, there is no individual right to lodge a complaint with a supervisory authority in the AI Act. Hence, individuals and civil organisations lack any direct redress mechanisms that can be used to enforce their rights or to start a procedure with the supervisory authorities when non compliance happens. 

It is true that Article 67, for example, grants supervisory authorities the power to take any appropriate measures to bring operators into compliance where there is a risk to health or safety, or fundamental rights or public interest are threatened. However, everything is left to the authorities in charge, that will need to surveil the whole market by themselves. This means that, ideally, they would need to be able to be fully aware of every problem and to initiate every necessary actions own volition, which is, in practice, hardly impossible, since it will be extremely difficult to have the capacity to continuously monitor the whole market in order to notice every potential non-compliance case, given the size of the market and the current scale of AI use. 

All this will leave authorities in a delicate position with respect to market actors, both private and public, as authorities will never have enough resources to monitor the whole market, and it will also leave individuals unprotected, not having any possibility for direct redress, as well as civil society, that will lack any resources to directly face problematic AI uses. Hence, this will create an imbalance of power that will favour AI deployers and providers and will difficult enforcement. 

On the other hand, regarding internal coherence of the regulation, it equally makes no sense that individuals are given certain rights (like transparency rights) while they are not given the power to enforce them. 

Apart from the European Union, other countries and jurisdictions are creating legislation on Artificial Intelligence and a great part of it is focusing heavily in transparency and accountability, as the proposed Transparent Automated Governance Act or Algorithmic Accountability Act in the US, or the Directive on Automated Decision-Making in Canada. 

Following the same principles, the European Union, the US, and the UK have signed the first “legally binding” treaty on AI, which aims at ensuring that AI use aligns with “human rights, democracy and the rule of law”. The treaty lays down as fundamental principles, among others, transparency and oversight as well as accountability and responsibility. 

This treaty also establishes the need for appropriate remedies, procedural rights and safeguards, that include the need for documentation, transparency practices that allow people to challenge any decisions made by the system, the possibility of lodging a complain with the competent authorities, effective procedural guarantees, and notice when one is interacting with an AI system. 

Charter of Digital Rights

In 2021, the Spanish Government presented the Charter of Digital Rights, that enshrines a series of principles to be observed when dealing with artificial intelligence, including transparency, auditability, explicability, traceability, and accessibility. However, as happens in the AI Act, this Chart does not lay down any obligations that are directly enforceable nor includes any direct redress mechanisms, although it demands that people interacting with AI systems have the right to request human intervention and supervision, the right to challenge automated decisions, and the right to be assisted by a human at the citizen’s request. 

oh, justice

Applying our principles

As seen through our analysis of applicable legislation, there are a series of principles that are repeated throughout most of the norms: transparency; accountability; human in the loop; and rights and redress mechanisms. 

Transparency

The transparency principle, generally speaking, aims at facilitating the task of holding the representatives of the people, and institutions and other actors accountable. Yet it is in itself a backbone of the rule of law, as the legislative process, the text of the norms, and the decisions made in interpretation of the norms need to be carried out in a transparent manner. Transparency is a prerequisite to the rule of law as well as necessary for accountability. 

However important transparency might be, traditional transparency on its own has proven not to be enough. Transparency cannot be the only solution in all cases but also needs for other measures to complement it. For instance, the transparency rights enshrined by the GDPR and the AIA are clearly not enough in the case of BOSCO. Here, both rights relate to the logic involved and the reasoning behind the decisions made by the algorithm. Yet the logic and the reasoning of BOSCO are already known to us, but they have still not been enough. 

With BOSCO, there is no complexity whatsoever in the system’s decision making: the software only needs to check whether very simple requirements are met or not. There is no other value or reasoning behind the decision. 

Interestingly, in AG Opinion C-203/22, the Advocate General considers that, from a GDPR perspective, ‘meaningful information about the logic involved’ must enable the data subject to exercise the rights guaranteed to them. That presupposes that the information, apart from being concise, easily accessible and easy to understand, must be sufficiently complete and contextualised to enable that person to verify its accuracy and whether there is an objectively verifiable consistency and causal link between, on the one hand, the method and criteria used and, on the other, the result arrived at by the automated decision.

In the case of BOSCO, this means that the information should be enough to determine whether the method and criteria used to arrive to the decision are consistent.

Additionally, the AG takes into account the existence of rights of other parties (third-party personal data and trades secrets) when dealing with delicate parts of the software or the source code itself. Where these rights may be affected, the AG offers a solution: that the necessary information is given to an authority or court to be examined, instead of giving it to the affected party. This, interpreted sensu contrario, leads to a reasonable conclusion: when such third party rights do not exist (i.e. there are no trade secrets involved nor third-party data), there is no reason not to disclose any information necessary to enable the person to verify the accuracy of the decision. In this case, there is no reason not to disclose BOSCO’s source code. 

In this sense, the AI Act also grants supervisory authorities the power to request the source code of high-risk AI systems in certain cases, meaning that the source code is not meant to be “sacrosanct”.

It is true that the Court offered, in its judgement against Civio, cybersecurity reasons against the disclosure of the code. Yet this reasoning sounds like a made-up excuse rather than anything else. It is a completely outdated argument that does not hold itself; security through obscurity has long been proven to be an inadequate way of protecting software from vulnerability. Even the American National Security Agency (NSA) has an open-source project where it provides free access to the code of many of their own-developed software and tools. One would rather believe that the NSA would not provide such code if there was any risk. 

But we do have closer examples without needing to cross the Atlantic: the Spanish Government has released the source code of own-developed apps for public scrutiny and auditing. The COVID tracing app’s source code was revealed due to transparency reasons, as was also done in many other European countries. If this meant a vulnerability, the disclosure of the source code of such app could risk unauthorised disclosure of health data of millions of people. However, the Government confirmed the app to be perfectly secure and privacy-friendly, while stating that technology should be put at the service of the people. Why would be the reasoning any different in the case of BOSCO or other AI systems created by or for the public sector?

Another of the main arguments against algorithmic transparency have always been intellectual property rights and the rationale behind the existence of such rights, since intellectual property seeks to protect, among others, the investment and effort used for an intellectual creation. However, when such creation is paid for or directly made by the public administration, the reasoning above makes no sense, as the investment is originally made in the interest of the citizenry and seeks no economic profit, quite the opposite to the private company.

In such a case, the public administration shall have no other interest than the people’s interest. Therefore, preventing the reuse of the source code lacks any sense, since there is no profit motivation, while the disclosure of the code may be an asset for future projects. Also, preventing the code from being audited would only lead to hindering potential improvement and error detection. “Public money, public code”.

Accountability

The principle of accountability means to be a way that allows for actors to be scrutinised and held accountable for their actions. In the realm of the highly complex and constantly evolving landscape of artificial intelligence and the impact in our lives and in society in general, accountability acquires more importance than ever.

In this sense, the AI Act requires from high-risk AI systems an elevated level of accountability. Given the Act’s risk-based approach to AI regulation, it imposes a gradual scheme of requirements and obligations depending on the level of risk posed by the system to health, safety and fundamental rights. Hence, actors are given the main responsibility for good governance and are obliged to produce an array of relevant internal knowledge and documentation, as well as to create safe processes, and to be externally audited. 

Accountability, as anointed by Article 5(2) GDPR, is also one of the GDPR core principles; principles that shall be applicable to any system that processes personal data, including BOSCO, as remarked above. And once again, transparency, always linked to accountability, is another of the data protection principles to be applied, as well as lawfulness, and fairness.

The need for fair governance in the public sector becomes more and more important the more AI systems become able to affect our fundamental rights. This implies that putting special emphasis in transparency and accountability is needed. And accountability requires that we are able to scrutinise them and hold them accountable. When talking about AI systems, the administration shall make available any means for the citizenry to inspect the use of such systems. 

This can be done in several ways, one of them being the necessity for independent and external auditing of the source code of public AI systems, as well as making documentation publicly available, including the source code where possible, creating a public inventory of such systems, and establishing solid supervision processes. 

However, relying on accountability without supervision makes no sense. If actors know they will never be held accountable, the whole point of demanding accountability gets lost.

Human in the loop

“Human in the loop” (HITL) is one of the most recurring solutions when talking about safeguards for AI systems. The right to request human intervention, the right not to be subject to decisions made solely by a machine, or the right to challenge a decision made by an AI system appear again and again as ways of minimising the risks that these systems pose to people’s rights and liberties.

However, as seen, this solution presents some limitations. Mainly, that HITL is, in many cases, mostly an a posteriori safeguard. When talking about ADM or non-complex tasks or systems, no human will normally be involved in the process; otherwise, if a human was needed, the whole point of automatising certain actions would be missed. Happening a posteriori means that 1) the affected person will be already impacted by the AI system, possibly having their rights affected, and 2) that many affected persons may accept the decision made by the system without contemplating (or without being able to understand) the possibility of wrongness, so they may not even notice that their rights have been affected. 

However, in the case of BOSCO, the algorithm is so simple that having a human in the loop would make no sense. Adding human review by default would mean that there would not be a need for using BOSCO, since reviewing BOSCO’s output or reviewing a form with a few ticks would mean the same amount of time and effort to the person in charge; hence rendering BOSCO useless.  

Rights and redress

Redress mechanisms are indispensable where rights are granted; as coherent as it is, there is no better way to ensure that rights are respected than giving individuals an appropriate way to enforce them. 

However, it is equally important not to place the whole weight of enforcement on individuals, since most persons usually don’t have the knowledge nor the capacity to engage in legal procedures. This is why the action of civil society is equally important, and that’s why in regulations such as the GDPR, civil organisations are also given the capacity to file complaints of behalf of individuals. Several of the most important GDPR enforcement actions come from civil organisations. An action by La Quadrature du Net resulted in the biggest fine under the GDPR (a 746M € fine against Amazon), while noyb managed to get the European Data Protection Board to initiate a taskforce to deal with several complaints regarding to the use of cookies, which led to a more harmonised application of the law. They also led the Irish Data Protection Authority to a key decision on Meta’s business model. Following an action by the Irish Council for Civil Liberties (ICCL), the European Commission will start regularly checking the progress of all “large-scale” GDPR cases across the EU.

As seen, the good functioning of individual and civil procedural rights has been proven of great importance; for this reason, the European Commission has a project to adopt new rules to ensure stronger enforcement of the GDPR in cross-border cases. As the saying goes, “laws without enforcement are just good advice”. 

Conclusions

All the principles referred to above are inextricably linked together. It is the sum of them what will ensure the good governance of artificial intelligence and the respect for the human rights of those impacted by AI.

As remarked by Virginia Eubanks, an algorithm can never be a way of releasing regulators and decision-makers from human consequences of political decisions. Particularly, when those decisions are not even carried out as intended by the algorithm, as proven and explained by Civio. The fact that it is not the norm that has shaped the malfunctioning, but the software itself, reveals the compelling need of having access to the source code of BOSCO or any other algorithm impacting fundamental rights. 

It is necessary for the civil society to have the capacity to examine machines that are making decisions or directly determining the outcome of a decision with a relevant effect; otherwise, hindering the rule of law would be as easy as automating every significant decision, so there would not be means to scrutinise them.

Citizens are already given certain rights with regard to the use of AI systems that affect them. However, such rights have been proven not to be enough, or that they are not being fairly applied, at least. The existing framework lays down several transparency and accountability obligations that complement each other, as well as principles that should have prevented, in theory, what has happened from happening. Yet such principles have indeed not prevented the system (as in “AI system”, in “legal system”, and in “public administration system”) from malfunctioning. Partly, because the whole weight of a good and fair governance cannot be placed solely on the citizens. Good and fair governance must come from within the administration, and the administration shall make available to the citizenry and civil actors every way possible to scrutinise them and hold them accountable. 

the world if AI systems governance was perfect

La entrada Lessons from BOSCO se publicó primero en Citizen8.

Do you want to object to Meta’s AI training in two clicks? We got you covered!

Meta has informed Facebook and Instagram users that, starting June 26, it will use their (your) personal data to train its artificial intelligence models.

Meta has established a deliberately cumbersome, long, and costly procedure for you to object to these processings.

In reality, you can object by sending an email to any of their contact addresses. The interpretation of the Brussels authorities supports this.

That’s why we have drafted a sample objection email, which you can send in two clicks.

It will literally take you five seconds to do it.

We are Citizen8

We are Citizen8: a group of specialists interested in empowering you, the citizen, in the defense of your rights, starting with your privacy.

Until now, through this website, we have published informational texts.

Today, we offer you what Meta should have offered you: a very simple and free way to exercise your right to object to their processings based on legitimate interest.

How does it work?

We do not access any of your personal data: everything happens on your device.

a) If you are on your computer

When you click any of the links below, your email program (Outlook, Thunderbird, Gmail, whatever) will open with a pre-drafted email ready to send.

The email contains the text we consider legally sufficient to exercise your right to object.

b) If you view this website from your mobile

Depending on the type and configuration of your mobile, the process may vary, but normally when you click the link, it will offer you several webmail services to choose from, and you will need to select and log in with your username and password for yours.

If you want it easier than that, simply open a new email on your mobile in the way you prefer and copy and paste into it (i) the text of the email we have prepared – it’s here – and (ii) the email addresses of Facebook or Instagram and that of eGarante if you want to obtain certification of the email, and send it.

Voilà !!

You need to click one of the following links. Select yours:

YO! Make sure the email is sent from the email address you are registered with on Facebook or Instagram

Generate Email to Facebook

Generate Email to Instagram

Comments:

Make sure the email is sent from the email address you are registered with on Facebook or Instagram. If your program generates the email from another address, you may need to copy and paste the recipients and text where necessary to ensure the email is sent from your correct address.

The email addresses for Facebook and Instagram are inserted by default.

Read the email and, if you agree with it, just click «send.»

What you can edit:

We have included the email address of eGarante (a certification and authentication services provider), which will send you another email minutes after sending yours, containing a copy (a PDF) of it, certifying the sending of your objection email, along with its date and time. eGarante will then delete your data: they are lovely.

Keep that PDF safe: it certifies that you have sent your objection in a timely manner. It can be useful for reporting or claiming damages against Meta if they do not respond or satisfy your objection.

Terms of the free eGarante service here.

If you do not want eGarante to provide this service, simply delete their email address from the «cc» or «Carbon Copy» field.

If you do not feel some of the listed reasons as yours, or do not understand them, delete them. In fact, to object, it is enough to leave the first two paragraphs (the ones starting with «When I decided to share my content…» and «It is obvious…»).

The email is generated within your device by interaction between your browser and your email client: we do not have access to your personal data.

eGarante will have access to your email address (to send you the certification of the sending) but you can avoid this by deleting their email address in the carbon copy (cc) field.

Do it yourself

Recipient

Email address for Facebook: support@fb.com

Email address for Instagram: support@instagram.com

CC (it is important that it is in the visible copy field – not hidden – otherwise, the eGarante service will not work). mailsigned@egarante.com

Subject: Exercise of the right to object under Article 21 GDPR

Email body

«Dear Meta Sirs:

It has been communicated to me that, if I do not exercise my right to object, Meta will process my personal data for the training of its artificial intelligence models. The data processed would be «the information you shared on Meta’s products and services. For example, posts or photos with their descriptions.» The purpose of the processing is to «train our AI models» and «develop and improve Meta’s AI.»

Therefore, in accordance with Article 21 of the General Data Protection Regulation, I hereby formally notify you of the exercise of my right to object to such processing of my personal data, for reasons related to my particular situation.

These reasons are as follows:

When I decided to share my content and information (which includes personal data of myself and third parties and may include both content subject to my intellectual property rights, as well as content related to children) in no way could I imagine that they would end up being used to train artificial intelligence models.

It is obvious, then, that such processing exceeds my reasonable expectations regarding the processing of my data and that, consequently, such processing, if accepted by me (which I am refusing), could only cover my future data and in no case my content dated prior to this communication.

The AIs that Meta trains can have multiple purposes, both positive and negative.

The information provided by Meta does not allow me to be certain that the AI models thus trained will not be used for purposes incompatible with my ethical and moral principles and values, nor if they will have any negative impact on me. Nor have I been informed of the final applications or functionalities – commercial or otherwise – of the models that Meta will train.

Consequently, I do not have enough information to decide if the processing and its purpose are acceptable to me. It seems appropriate to assume the contrary, considering the numerous occasions on which Meta has failed to meet its legal obligations in the past.

It is unacceptable to think that my personal data may contribute to the next scandal involving Meta.

This platform has a direct contractual relationship with me: nothing prevents, and in fact, it would be most appropriate – both from a legal standpoint and for the quality of the service – that my consent be directly requested for this processing of my data.

In summary, this initiative, as it is proposed, appears to be a new attempt to abuse my rights by this platform.

In light of the above, I hereby notify you of the exercise of my right to your support email address (since you do not even offer a dedicated email address for privacy issues, only a complicated objection procedure on your website, full of friction elements).

I do so under the provisions of the EDPB in its Guidelines 1/2022 (paragraph 53 and the corresponding footnote 28). I ask you to make your best efforts to ensure that this notification reaches the appropriate department at Meta so that my right is promptly satisfied.

I remind you that the regulations require you to notify me in writing within one month from the date of this notification either (i) the confirmation that my personal data has been removed from the training datasets of your AIs or (ii) the confirmation that it has not been done (and in this case, with a fulfilled justification).

Kind regards.»

<<<End of mail>>>

Now paste all that in your favourite email client and press «Send».

You´re done.

And you are welcome.

Jorge García Herrero

DPO. GDPR Evangelist

La entrada How to object to Meta’s AI training in two clicks se publicó primero en Citizen8.