Data Act: cuando “compartir datos” también es RGPD (y LOPDGDD)

Desde el 12 de septiembre de 2025, el Data Act impulsa en la UE un cambio práctico: facilitar el acceso, uso y compartición de datos generados por productos conectados (IoT) y servicios asociados. La idea es clara: que el usuario no quede “atrapado” y pueda aprovechar esos datos, incluso a través de terceros.

Pero hay un matiz decisivo: muchos de esos datos, aunque nazcan como “datos de producto” o “telemetría”, pueden ser datos personales o permitir la identificación de personas. Y en ese caso, el Data Act no sustituye a la privacidad: se activa el RGPD y, en España, también la LOPDGDD.

Este artículo explica qué datos entran en juego, los roles y contratos habituales, cómo separar dato personal vs no personal y qué obligaciones (y riesgos) aparecen cuando “compartir” también significa “tratar datos personales”.

1) Qué datos cubre: productos conectados y servicios relacionados

En la práctica, hablamos de datos que se generan por el uso de:

• Productos conectados: vehículos conectados, maquinaria industrial, smart home, wearables, impresoras inteligentes, dispositivos médicos conectados, etc.
• Servicios relacionados: apps, plataformas de mantenimiento, paneles de control, servicios de analítica o soporte que dependen del producto.

Tipos de datos habituales

• Datos de uso y rendimiento: eventos, logs, fallos, métricas de funcionamiento, consumo.
• Datos de entorno: ubicación, temperatura, hábitos de uso, horarios.
• Datos derivados: perfiles, inferencias, indicadores, segmentaciones.
• Metadatos y registros: identificadores, tokens, direcciones IP, timestamps.

El punto crítico: no todo es “no personal” por venir de una máquina. Si el dato se vincula directa o indirectamente con una persona (titular, usuario, conductor, empleado, visitante), puede ser dato personal en sentido RGPD.

2) Roles del Data Act y cómo se traducen al RGPD

El Data Act utiliza roles funcionales. Los más relevantes:

• Data holder: quien controla técnicamente el acceso a los datos (fabricante, proveedor del servicio, plataforma).
• User (usuario): quien utiliza el producto o recibe el servicio (puede ser consumidor o empresa).
• Third party (tercero): entidad a la que el usuario pide que se le compartan los datos (un taller, aseguradora, empresa de eficiencia energética, proveedor de analítica, etc.).

Atención: roles Data Act ≠ roles RGPD

En RGPD, lo determinante es quién decide finalidades y medios del tratamiento:

• El data holder puede ser responsable (controller) para sus fines propios (mejora del producto, soporte, seguridad, facturación).
• El third party puede ser responsable independiente si usa los datos para sus propios fines; o encargado si actúa por cuenta del usuario-empresa (por ejemplo, un proveedor que procesa datos siguiendo instrucciones).
• El user puede ser interesado (persona física) o responsable (empresa empleadora, por ejemplo).

Conclusión: antes de compartir, hay que “traducir” el esquema del Data Act a un mapa RGPD: responsables, encargados, corresponsables, y flujos.

3) Cómo separar datos personales vs no personales (y qué pasa con los “mixtos”)

Regla práctica

• Dato no personal: no identifica ni hace identificable a una persona (por ejemplo, datos agregados de funcionamiento sin vínculos a un usuario).
• Dato personal: identifica o puede identificar (directa o indirectamente) a una persona: identificadores, ubicación, hábitos, patrones de comportamiento, voz, imágenes, IDs persistentes del dispositivo vinculados a un titular, etc.

Ojo con los datos mixtos

En IoT es común tener conjuntos mixtos (parte personal, parte no personal). En la operativa real, esto obliga a:

• Clasificación previa de campos y eventos (catálogo de datos).
• Separación lógica o física: particionar datasets, vistas por perfil, “data products” con distintas capas.
• Minimización: compartir solo lo necesario para el fin solicitado.
• Seudonimización cuando no sea posible excluir lo personal, sin confundirla con anonimización.
• Anonimización solo si es robusta (si existe riesgo razonable de reidentificación, seguirá siendo RGPD).

4) Contratos y gobernanza: qué debe quedar por escrito

Aunque el Data Act impulsa el acceso/compartición, el aterrizaje seguro exige contratos y controles claros:

Documentos típicos

• Cláusulas de acceso/compartición en términos del producto/servicio.
• Acuerdo de compartición de datos con el tercero: alcance, formato, periodicidad, retención, prohibiciones de reuso.
• Si el tercero actúa como encargado: contrato de encargo (art. 28 RGPD) con instrucciones, confidencialidad, subencargados, medidas de seguridad, asistencia en derechos, etc.
• Anexos de seguridad: cifrado, autenticación fuerte, segregación, trazabilidad, pruebas y notificación de incidentes.

Controles operativos imprescindibles

• Verificación de identidad y legitimación del solicitante.
• Registro de solicitudes y auditoría de accesos (accountability).
• Revisión de terceros (due diligence) y evaluación de su postura de seguridad.

5) Beneficios y riesgos: privacidad, vulnerabilidad y “superficie de ataque”

Beneficios esperables

• Más control para el usuario y portabilidad real.
• Nuevos servicios basados en datos (mantenimiento predictivo, optimización energética, comparadores).
• Reducción del “lock-in” y mejora de competencia.

Riesgos principales

• Privacidad: perfilado, vigilancia indirecta, usos secundarios no esperados.
• Reidentificación: incluso datos “técnicos” pueden identificar por combinación.
• Vulnerabilidad: al abrir APIs y flujos de intercambio, aumenta la superficie de ataque (tokens, integraciones, errores de configuración, exfiltración).
• Afectación a terceros: familiares, empleados o visitantes cuyos datos aparecen sin haber solicitado nada.

6) RGPD y LOPDGDD: requisitos, bases legales y proporcionalidad

Cuando haya datos personales, aplican los principios y obligaciones del RGPD (y la LOPDGDD como normativa española complementaria). En la práctica:

Base de legitimación (art. 6 RGPD)

No existe una “base automática” por el hecho de que el Data Act permita compartir. Hay que encajar el tratamiento, por ejemplo:

• Ejecución de un contrato: si el acceso/compartición es necesario para prestar el servicio solicitado por el interesado.
• Consentimiento: útil cuando el tercero va a tratar datos para finalidades propias y se necesita una manifestación clara (con posibilidad real de retirada).
• Interés legítimo: posible en ciertos supuestos, pero exige ponderación y salvaguardas (especialmente con telemetría y perfiles).
• Obligación legal: en casos concretos donde una norma obligue (no “por defecto” en toda compartición).

Transparencia y derechos

• Información clara (art. 13/14 RGPD): qué datos, finalidades, destinatarios, plazos, derechos.
• Gestión de derechos: acceso, supresión, oposición, limitación, portabilidad (cuando aplique) y atención a escenarios multi-actor (data holder/tercero).

¿EIPD/DPIA obligatoria?

El RGPD no obliga siempre a una Evaluación de Impacto, pero sí cuando sea probable un alto riesgo (art. 35). En compartición IoT puede ser especialmente relevante si hay:

• geolocalización sistemática,
• perfiles o inferencias sobre hábitos,
• grandes volúmenes o monitorización continua,
• datos de salud o categorías especiales,
• colectivos vulnerables o contexto laboral.

En España, además, conviene alinear el análisis con criterios y prácticas habituales de cumplimiento bajo la LOPDGDD (responsabilidad proactiva, medidas organizativas, papel del DPD cuando proceda).

Medidas de proporcionalidad (lo que “salva” proyectos)

• Minimización por diseño: “solo lo necesario”.
• Limitación de finalidad y prohibición de reutilización no autorizada.
• Plazos de conservación y borrado verificable.
• Seguridad técnica y organizativa (art. 32 RGPD): cifrado, control de accesos, segmentación, logging, gestión de vulnerabilidades, pruebas, respuesta a incidentes.
• Privacidad desde el diseño y por defecto: interfaces que permitan elegir qué se comparte y con quién, de forma comprensible.

7) Checklist rápido para implantar compartición por Data Act sin chocar con RGPD

1. Inventario: ¿qué datos genera el producto y cuáles son personales/mixtos?
2. Roles RGPD: ¿quién es responsable/encargado/corresponsable en cada flujo?
3. Base legal: ¿contrato, consentimiento, interés legítimo…? ¿hay terceros afectados?
4. Contratos: art. 28 si hay encargo; límites de uso si el tercero es responsable.
5. Seguridad: APIs, autenticación, cifrado, trazabilidad y control de tokens.
6. EIPD/DPIA: valorar alto riesgo; documentar decisiones y salvaguardas.

Límites de esta información

Este contenido es informativo y general. La base jurídica exacta, el rol RGPD de cada actor y si procede EIPD/DPIA dependen del caso (tipo de dispositivo, finalidad del tercero, categorías de datos, afectados, contexto laboral/consumo, diseño técnico). Para decisiones concretas y documentación formal, es recomendable un análisis jurídico-técnico específico.